Frame/Field problem

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

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

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

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.

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

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

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

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

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

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