[NUT-devel] Frame/Field problem

[Michael Niedermayer]

On Wed, Feb 20, 2008 at 11:43:35AM -0500, Rich Felker wrote:
> 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.

the definition of dts in nut.txt is
----
dts
    The time when a frame is input into a synchronous 1-in-1-out decoder.
----
[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080221/17223789/attachment.pgp>