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>
* qatar/master:
h264_parser: use enum values in h264_find_frame_end()
Conflicts:
libavcodec/h264_parser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '73e8fab31dc19c4371499e612856accbc00b2820':
h264: print values in case of error
Conflicts:
libavcodec/h264.c
libavcodec/h264_ps.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4baba6c813b7a1f27370e20fb1a87b05fcb39208':
h264_parser: Fix POC parsing for the case where MMCO_RESET is present.
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b81dbd6cb7522bea96d78a52f8a4c25a47b820c9':
h264_parser: Fix POC parsing for the case where MMCO_RESET is absent.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The prev_ values were not set after parsing POC.
Increase length of the buffer decoded to parse enough safely.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '218d6844b37d339ffbf2044ad07d8be7767e2734':
h264dsp: Factorize code into a new function, h264_find_start_code_candidate
Conflicts:
libavcodec/h264_parser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7a82022ee2f9b1fad991ace0936901e7419444be':
h264_parser: Initialize the h264dsp context in the parser as well
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This performs the start code search which was previously part of
h264_find_frame_end() - the most CPU intensive part of the function.
By itself, this results in a performance regression:
Before After
Mean StdDev Mean StdDev Change
Overall time 2925.6 26.2 3068.5 31.7 -4.7%
but this can more than be made up for by platform-optimised
implementations of the function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Each AVStream struct for an H.264 elementary stream actually has two
copies of the H264DSPContext struct (and in fact all the other members
of H264Context as well):
((H264Context *) ((AVStream *)st)->codec->priv_data)->h264dsp
((H264Context *) ((AVStream *)st)->parser->priv_data)->h264dsp
but only the first of these was actually being initialised. This
prevented the addition of platform-specific implementations of
parser-related functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches the matroska defintion of stereo_mode, with
no metadata written if no info exist in sei
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '088f38a4f9f54bb923405c67c9e72d96d90aa284':
avcodec: Drop unnecessary ff_ name prefixes from static functions
Conflicts:
libavcodec/ass.c
libavcodec/h264_parser.c
libavcodec/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Because in contrast to the decoder, the parser does not setup low_delay.
The code in parse_nal_units would always end up setting has_b_frames
to "1", except when stream is explicitly marked as low delay.
Since the parser itself would create 'extradata', simply reopening
the parser would cause this.
This happens for instance in estimate_timings_from_pts(), which causes the
parser to be reopened on the same stream.
This fixes Libav #22 and FFmpeg (trac) #360
CC: libav-stable@libav.org
Based on a patch by Reimar Döffinger <Reimar.Doeffinger@gmx.de>
(commit 31ac0ac29b)
Comments and description adapted by Reinhard Tartler.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
* qatar/master:
flicvideo: fix invalid reads
vorbis: Avoid some out-of-bounds reads
vqf: add more known extensions
cabac: remove unused function renorm_cabac_decoder
h264: Only use symbols from the SVQ3 decoder under proper conditionals.
add bytestream2_tell() and bytestream2_seek() functions
parsers: initialize MpegEncContext.slice_context_count to 1
spdifenc: use special alignment for DTS-HD length_code
Conflicts:
libavcodec/flicvideo.c
libavcodec/h264.c
libavcodec/mpeg4video_parser.c
libavcodec/vorbis.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
