[NUT-devel] Frame/Field problem

[Rich Felker]

On Wed, Feb 20, 2008 at 05:00:29PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 19, 2008 at 11:51:40PM -0500, Rich Felker wrote:
> > On Wed, Feb 20, 2008 at 05:23:14AM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > When we designed the pts->dts reorder algorithm we considered arbitrary
> > > frame reorderings, but there was something we missed, that are mixes of
> > > frame and field pictures, like:
> > > 
> > >     i1 p2 P3 p4 P5 p7 P8   (lower case is a field, upper is a frame)
> > > PTS 2  3  4  6  7  9  10
> > > DTS 0  1  2  4  5  7  8
> > > 
> > > As you can see no reordering of PTS can result in the DTS values.
> > 
> > I'm confused by this example. As there are no B frames, dts==pts is
> > just fine.
> 
> Fine in what respect? Certainly not fine in the respect of being a valid
> decoding timestamp for an mpeg2 decoder.

DTS in NUT was never designed to be able to meet odd additional
requirements beyond serving as a key for interleaving order. It
_works_ to use the dts as an actual time for decoding, but that
doesn't necessarily mean that doing so will meet more stringent
requirements on DTS from a particular codec like mpeg2.

> Anyway after some sleep it seems the example above is invalid as mpeg2 says:
> "If field pictures are used then they shall occur in  pairs"

This greatly reduces their usefulness for efficient coding of
hard-telecined content, I think... Of course a smart encoder would
just use RFF flag anyway.

> This also gives us an easy solution, just put both fields in a single nut
> frame.

I'm not sure whether this is a good idea or not. But it should be
discussed and considered.

> I also should likely try that in ffmpeg the code i commited yesterday
> to interpolate field picture timestamps is ugly, though it should work with
> any possible mixture ...

:-)

Rich