- 15 Oct, 2014 1 commit
-
-
Michael Niedermayer authored
They are not just inverses of each other. This should restore behavior to before the introduction of framerate Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 27 Aug, 2014 1 commit
-
-
Luca Barbato authored
Leftover of a4d3c200.
-
- 26 Aug, 2014 1 commit
-
-
Luca Barbato authored
As written in the comment above, skip must be added only if a start code is found.
-
- 04 Aug, 2014 1 commit
-
-
Ben Avison authored
The previous implementation of the parser made four passes over each input buffer (reduced to two if the container format already guaranteed the input buffer corresponded to frames, such as with MKV). But these buffers are often 200K in size, certainly enough to flush the data out of L1 cache, and for many CPUs, all the way out to main memory. The passes were: 1) locate frame boundaries (not needed for MKV etc) 2) copy the data into a contiguous block (not needed for MKV etc) 3) locate the start codes within each frame 4) unescape the data between start codes After this, the unescaped data was parsed to extract certain header fields, but because the unescape operation was so large, this was usually also effectively operating on uncached memory. Most of the unescaped data was simply thrown away and never processed further. Only step 2 - because it used memcpy - was using prefetch, making things even worse. This patch reorganises these steps so that, aside from the copying, the operations are performed in parallel, maximising cache utilisation. No more than the worst-case number of bytes needed for header parsing is unescaped. Most of the data is, in practice, only read in order to search for a start code, for which optimised implementations already existed in the H264 codec (notably the ARM version uses prefetch, so we end up doing both remaining passes at maximum speed). For MKV files, we know when we've found the last start code of interest in a given frame, so we are able to avoid doing even that one remaining pass for most of the buffer. In some use-cases (such as the Raspberry Pi) video decode is handled by the GPU, but the entire elementary stream is still fed through the parser to pick out certain elements of the header which are necessary to manage the decode process. As you might expect, in these cases, the performance of the parser is significant. To measure parser performance, I used the same VC-1 elementary stream in either an MPEG-2 transport stream or a MKV file, and fed it through avconv with -c:v copy -c:a copy -f null. These are the gperftools counts for those streams, both filtered to only include vc1_parse() and its callees, and unfiltered (to include the whole binary). Lower numbers are better: Before After File Filtered Mean StdDev Mean StdDev Confidence Change M2TS No 861.7 8.2 650.5 8.1 100.0% +32.5% MKV No 868.9 7.4 731.7 9.0 100.0% +18.8% M2TS Yes 250.0 11.2 27.2 3.4 100.0% +817.9% MKV Yes 149.0 12.8 1.7 0.8 100.0% +8526.3% Yes, that last case shows vc1_parse() running 86 times faster! The M2TS case does show a larger absolute improvement though, since it was worse to begin with. This patch has been tested with the FATE suite (albeit on x86 for speed). Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
- 29 Apr, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 25 Apr, 2014 1 commit
-
-
Ben Avison authored
The previous implementation of the parser made four passes over each input buffer (reduced to two if the container format already guaranteed the input buffer corresponded to frames, such as with MKV). But these buffers are often 200K in size, certainly enough to flush the data out of L1 cache, and for many CPUs, all the way out to main memory. The passes were: 1) locate frame boundaries (not needed for MKV etc) 2) copy the data into a contiguous block (not needed for MKV etc) 3) locate the start codes within each frame 4) unescape the data between start codes After this, the unescaped data was parsed to extract certain header fields, but because the unescape operation was so large, this was usually also effectively operating on uncached memory. Most of the unescaped data was simply thrown away and never processed further. Only step 2 - because it used memcpy - was using prefetch, making things even worse. This patch reorganises these steps so that, aside from the copying, the operations are performed in parallel, maximising cache utilisation. No more than the worst-case number of bytes needed for header parsing is unescaped. Most of the data is, in practice, only read in order to search for a start code, for which optimised implementations already existed in the H264 codec (notably the ARM version uses prefetch, so we end up doing both remaining passes at maximum speed). For MKV files, we know when we've found the last start code of interest in a given frame, so we are able to avoid doing even that one remaining pass for most of the buffer. In some use-cases (such as the Raspberry Pi) video decode is handled by the GPU, but the entire elementary stream is still fed through the parser to pick out certain elements of the header which are necessary to manage the decode process. As you might expect, in these cases, the performance of the parser is significant. To measure parser performance, I used the same VC-1 elementary stream in either an MPEG-2 transport stream or a MKV file, and fed it through ffmpeg with -c:v copy -c:a copy -f null. These are the gperftools counts for those streams, both filtered to only include vc1_parse() and its callees, and unfiltered (to include the whole binary). Lower numbers are better: Before After File Filtered Mean StdDev Mean StdDev Confidence Change M2TS No 861.7 8.2 650.5 8.1 100.0% +32.5% MKV No 868.9 7.4 731.7 9.0 100.0% +18.8% M2TS Yes 250.0 11.2 27.2 3.4 100.0% +817.9% MKV Yes 149.0 12.8 1.7 0.8 100.0% +8526.3% Yes, that last case shows vc1_parse() running 86 times faster! The M2TS case does show a larger absolute improvement though, since it was worse to begin with. This patch has been tested with the FATE suite (albeit on x86 for speed). Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 27 Oct, 2013 1 commit
-
-
Michael Niedermayer authored
Fixed CID739860 Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 14 Jun, 2013 1 commit
-
-
Hendrik Leppkes authored
first_pic_header_flag needs to be set to allow the parsing code to change some stream parameters, and not error out. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 04 May, 2013 1 commit
-
-
Diego Biurrun authored
-
- 03 May, 2013 1 commit
-
-
Masaki Tanaka authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
- 07 Aug, 2012 1 commit
-
-
Anton Khirnov authored
-
- 18 Feb, 2012 1 commit
-
-
Ronald S. Bultje authored
The parser uses VLC tables initialized in vc1_common_init(), therefore we should call this function on parser init also. Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
- 15 Feb, 2012 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 10 Feb, 2012 1 commit
-
-
Rafaël Carré authored
It works as long as ParseContext is the first member of the private struct Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
- 06 Jan, 2012 1 commit
-
-
Janne Grunau authored
The mpeg4 video, H264 and VC-1 parser hold (directly or indirectly) a MpegEncContext in their private context. Since they do not call the common mpegvideo init function slice_context_count has explicitly set to 1. Prevents a null pointer dereference in the h264 parser and fixes bug 193.
-
- 12 Dec, 2011 1 commit
-
-
Diego Biurrun authored
-
- 02 Nov, 2011 1 commit
-
-
Anton Khirnov authored
-
- 25 Aug, 2011 1 commit
-
-
John Stebbins authored
Pulldown flags are being set incorrectly and AVFrame->repeat_pict is not being set. Also, skipped frames exit header parsing too early and do not set pulldown flags appropriately. Ticks_per_frame needs to be set and time_base adjusted so player can extend frame duration by a field time. This fixes problems encountered when attempting to transcode HD-DVD EVOB files with HandBrake. Also makes these files play smoothly in avplay. Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- 02 May, 2011 2 commits
-
-
Stefano Sabatini authored
-
Stefano Sabatini authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
- 19 Mar, 2011 1 commit
-
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 28 Jan, 2011 1 commit
-
-
Diego Elio Pettenò authored
None of these symbols should be accessed directly, so declare them as hidden. Signed-off-by:
Mans Rullgard <mans@mansr.com> (cherry picked from commit d36beb3f)
-
- 26 Jan, 2011 1 commit
-
-
Diego Elio Pettenò authored
None of these symbols should be accessed directly, so declare them as hidden. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 20 Apr, 2010 1 commit
-
-
Diego Biurrun authored
Passing an explicit filename to this command is only necessary if the documentation in the @file block refers to a file different from the one the block resides in. Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 30 May, 2009 1 commit
-
-
Baptiste Coudurier authored
Originally committed as revision 18987 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 22 Feb, 2009 1 commit
-
-
Michael Niedermayer authored
Fixes Subtitle-sample.evo, issue52. Originally committed as revision 17533 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 01 Feb, 2009 1 commit
-
-
Diego Biurrun authored
Otherwise doxygen complains about ambiguous filenames when files exist under the same name in different subdirectories. Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 07 May, 2007 1 commit
-
-
Aurelien Jacobs authored
Originally committed as revision 8921 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 06 May, 2007 1 commit
-
-
Kostya Shishkov authored
Originally committed as revision 8914 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 05 May, 2007 1 commit
-
-
Diego Biurrun authored
Originally committed as revision 8905 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 04 May, 2007 2 commits
-
-
Kostya Shishkov authored
Originally committed as revision 8886 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Diego Biurrun authored
Originally committed as revision 8882 to svn://svn.ffmpeg.org/ffmpeg/trunk
-