Also make error style consistent and drop redundant information.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

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>

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>

Set output_picture_number in H.264 parser.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

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 31ac0ac2)

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.

This reverts commit 87eebb34.

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.

It's used in lavf.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

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>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Mans Rullgard <mans@mansr.com>

None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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>

erroneous message for last frame.

Originally committed as revision 24450 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 23364 to svn://svn.ffmpeg.org/ffmpeg/trunk

Fixes many "non-existing PPS referenced" error messages

Originally committed as revision 23363 to svn://svn.ffmpeg.org/ffmpeg/trunk

Add an AVSTREAM_PARSE_FULL_ONCE parsing mode to parse headers and combine packets once and only once.

Originally committed as revision 23332 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

Patch by Rafaël Carré, rafael D carre A gmail

Originally committed as revision 21517 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