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.
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.
A smart encoder would generate only progressive video. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.