[FFmpeg-trac] #3393(undetermined:closed): Interlaced H.264 packets are split causing MP4 STTS

[FFmpeg]

#3393: Interlaced H.264 packets are split causing MP4 STTS
-------------------------------------+-------------------------------------
             Reporter:  wim_arbor    |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  h264 mov     |               Resolution:  invalid
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  1
-------------------------------------+-------------------------------------

Comment (by wim_arbor):

 Replying to [comment:9 cehoyos]:
 > Replying to [comment:7 wim_arbor]:
 > > What I understand from the discussion on the mailing list is that
 merging the fields into field pairs violates the ISO specification.
 > >
 > > > AVC sample: An AVC sample is an access unit as defined in ISO/IEC
 14496‐10
 > >
 > > > access unit: A set of NAL units that are consecutive in decoding
 order and contain exactly one primary coded picture. (...) The decoding of
 an access unit always results in a decoded picture.
 > >
 > > Each (PAFF) field is encoded as a separate picture, so a sample in a
 MP4 file may only contain a single field.
 >
 > I don't know much about H.264 but I would have expected that it needs
 two PAFF fields to get a decoded picture.

 You should not read the english word "picture" here, but picture as
 defined in the same spec;

     '''picture''': A collective term for a ''field'' or a ''frame''.

 And related definitions:

     '''decoded picture''': A ''decoded picture'' is derived by decoding a
 ''coded picture''. A ''decoded picture'' is either a decoded ''frame'', or
 a decoded ''field''. A decoded ''field'' is either a decoded ''top field''
 or a decoded ''bottom field''.

     '''coded picture''': A ''coded representation'' of a ''picture''. A
 coded picture may be either a ''coded field'' or a ''coded frame''. Coded
 picture is a collective term referring to a ''primary coded picture'' or a
 ''redundant coded picture'', but not to both together.

 > > So software which uses the sample count in the MP4 file to determine
 the frame rate is simply wrong. This includes mediainfo, vlc, quicktime
 and gspot. The same applies to other encoders which generate such files.
 >
 > > I tested sorenson squeeze with the intel and mainconcept encoder. Both
 merged fields.
 >
 > This sounds to me as if we should do the same, particularly if there is
 no playback application that fails for such output files.

 AFAIK there is no application which fails with the current output either.
 Just some software reports a wrong framerate for such files. The reaction
 on the mailing list is very clear that this violates the spec. And I agree
 now after reading it.

 I will report a bug at mainconcept after I have checked their newest codec
 version. If they don't agree, I will report back here. But that will take
 some time, I did not want to keep this ticket open in the mean time.

 But of course feel free if you want to implement this, currently I have to
 merge the patches myself to get a custom version.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3393#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker