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. The reason why this fails is (if my brain still works at 5:30am) that frame pictures contain 2 fields and thus would have to be counted like 2 besides that they would really need 2 pts. I suspect some solution based on dummy 0byte packets with the missing pts after each frame might solve this, but i must think more about this ... -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
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.
The reason why this fails is (if my brain still works at 5:30am) that frame pictures contain 2 fields and thus would have to be counted like 2 besides that they would really need 2 pts.
Presumably interlaced video is always fixed-fieldrate, and the device presenting it knows the time interval between fields. This is why I never saw storing an explicit timestamp for the second field as important..
I suspect some solution based on dummy 0byte packets with the missing pts after each frame might solve this, but i must think more about this ...
Sounds ugly. I'd like to see a lot more motivation of a need before anything like this is considered.. Rich
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. 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 also gives us an easy solution, just put both fields in a single nut frame. 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 ... also here are a few examples with b frames: i p P B B B B 0 1 10 2 4 6 8 - - 0 2 4 6 8 i P p B B B B (invalid in mpeg2 i dunno about h.264) 0 1 11 2 4 6 8 - - 1 2 4 6 8 I p p B B B B 0 10 11 2 4 6 8 - 0 1 2 4 6 8 i p p p B B B B 0 1 10 11 2 4 6 8 - - 0 1 2 4 6 8 I P b b b b b b b b 0 10 2 3 4 5 6 7 8 9 - 0 2 3 4 5 6 7 8 9 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
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
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.
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
On Wed, 20 Feb 2008, Michael Niedermayer wrote:
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"
H.264 allows non-paired field pictures. And even if they are paired, a pair need not be consecutive in display order. --Loren Merritt
On Fri, Feb 22, 2008 at 05:09:53PM -0700, Loren Merritt wrote:
On Wed, 20 Feb 2008, Michael Niedermayer wrote:
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"
H.264 allows non-paired field pictures. And even if they are paired, a pair need not be consecutive in display order.
I feared that already, as i didnt remember a rule disallowing it nor did i find one when i searched ... I wonder if the 2 fields of a frame need to be consecutive in display order? IIRC the syntax would allow them to be non consecutive. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
participants (3)
-
Loren Merritt -
Michael Niedermayer -
Rich Felker