Re: Frame/Field problem

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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.

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel