[FFmpeg-cvslog] r13643 - in trunk: libavcodec/mpegvideo_parser.c tests/seek.regression.ref
Wed Jun 4 16:01:08 CEST 2008
Michael Niedermayer wrote:
> On Wed, Jun 04, 2008 at 08:52:58AM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > On Tue, Jun 03, 2008 at 05:33:59AM +0100, M?ns Rullg?rd wrote:
>> >> michael <subversion at mplayerhq.hu> writes:
>> >> > Author: michael
>> >> > Date: Tue Jun 3 04:43:17 2008
>> >> > New Revision: 13643
>> >> >
>> >> > Log:
>> >> > In mpeg1/2 timestamps (against all logic) are associated with
>> >> > picture start codes and not with access units.
>> >> The change may be valid, but this description doesn't make sense.
>> >> This is what the spec says:
>> >> For ITU-T Rec. H.262 | ISO/IEC 13818-2 video, if a PTS is present in
>> >> a PES packet header, it shall refer to the access unit containing
>> >> the first picture start code that commences in this PES packet. A
>> >> picture start code commences in a PES packet if the first byte of
>> >> the picture start code is present in the PES packet.
>> >> In other words, the access unit is defined as containing the picture
>> >> start code, and I can't think of any other sane way of defining it.
>> > H.264 in H.222 defines it as the first access unit that commences in the
>> > PES packet. (which is IMHO more sane)
>> MPEG2 defines a video access unit like this:
>> In the case of video, an access unit includes all the coded data for
>> a picture, and any stuffing that follows it, up to but not including
>> the start of the next access unit. If a picture is not preceded by a
>> group_start_code or a sequence_header_code, the access unit begins
>> with the picture start code. If a picture is preceded by a
>> group_start_code and/or a sequence_header_code, the access unit
>> begins with the first byte of the first of these start codes. If it
>> is the last picture preceding a sequence_end_code in the bitstream,
>> all bytes between the last byte of the coded picture and the
>> sequence_end_code (including the sequence_end_code) belong to the
>> access unit.
>> H.264 defines an access unit like this:
>> A set of NAL units always containing exactly one primary coded
>> picture. In addition to the primary coded picture, an access unit
>> may also contain one or more redundant coded pictures or other NAL
>> units not containing slices or slice data partitions of a coded
>> picture. The decoding of an access unit always results in a decoded
>> For H.264 video, PTS is defined as:
>> For ITU-T Rec. H.264 | ISO/IEC 14496-10 video, if a PTS is present
>> in the PES packet header, it shall refer to the first AVC access
>> unit that commences in this PES packet. An AVC access unit commences
>> in a PES packet if the first byte of the AVC access unit is present
>> in the PES packet.
>> The difference is how non-picture data, e.g. GOP headers and SPS, PPS,
>> SEI etc., are treated, and I really don't see how one or the other
>> would be significantly better.
> Thats because you did not spend 2 days fixing the parser to handle the
> mpeg2 case correctly. ;)
That's because you insist on using a parser in the first place, and
accidentally wrote it wrong. MPEG2 was intended to be decoded as a
stream, without being split into access units first.
mans at mansr.com
More information about the ffmpeg-cvslog