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>
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.
Start code emulation prevention is only required in Annex B bytestream
packed NAL units. For other coding formats the size is already known.
Looking for a start code prefix can result in false positives like in
http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4
which has a false positive in the SPS.
Due to it in contrast to the decoder not setting up 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.
estimate_timings_from_pts would cause the parser to be reopened
on the same stream.
This fixes trac issue #360.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Currently, the parser is buggy and only processes the stream extradata
when the flag is set. This fixes it to actually inspect the frames.
Whitespce will be fixed in a separate change.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently, the parser is buggy and only processes the stream extradata
when the flag is set. This fixes it to actually inspect the frames.
Whitespce will be fixed in a separate change.
Signed-off-by: Philip Langdale <philipl@overt.org>
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 d36beb3f69)
The header is empty after making the function static, so delete it and
drop its usage.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
(cherry picked from commit 13eb6b9097)
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
This allows freeing the parser memory in the thread_context freeing loop.
Patch by Rafaël Carré gmailify(rafael, carre)
Originally committed as revision 21508 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fix:
==22063== Conditional jump or move depends on uninitialised value(s)
==22063== at 0x811A4B7: ff_find_start_code (mpegvideo.c:99)
==22063== by 0x82F5B74: parse_nal_units (h264_parser.c:132)
==22063== by 0x82F5A68: h264_parse (h264_parser.c:261)
[...]
==22063== Uninitialised value was created by a stack allocation
==22063== at 0x82F5AF5: parse_nal_units (h264_parser.c:112)
Originally committed as revision 18479 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the parser will no longer leak memory for all SPS/PPS it encounters.
Originally committed as revision 18406 to svn://svn.ffmpeg.org/ffmpeg/trunk
Anton Khirnov
Michael Niedermayer
Reinhard Tartler
Reimar Döffinger
Janne Grunau
Carl Eugen Hoyos
Diego Biurrun
Philip Langdale
Stefano Sabatini
Mans Rullgard
Janne Grunau
Diego Elio Pettenò
Baptiste Coudurier
Howard Chu
Alex Converse
Rafaël Carré
John Cox
Carl Eugen Hoyos
Ivan Schreter