Summary of interlaced content types

5 views
Skip to first unread message

Philip Langdale

unread,
Jan 9, 2011, 4:23:11 PM1/9/11
to crystalhd-...@googlegroups.com
I hope I'm not just talking to myself here :-)

I've now seen four different types of interlaced content, and I can't
see a way for me to handle all of them
with the same code. Some of this is a recap of previous messages but
it's good to have a consolidated
summary:

1) MBAFF
* A single input packet contains a field pair.
* A single output frame contains a field pair.
* Firmware tags frame as 0x70 (Interlaced, Top Frame, 'UNKNOWN_SRC')

I'd expect to be tagged as 0x28 (INTERLACED | FIELDPAIR)

2) Interlaced MPEG2
* A single input packet contains a field pair.
* A single output frame is really a single field.
* Firmware tags fields as 0x30/0x38 or 0xB0/0xB8

This is what I'd expect.

3) PAFF
* A single input packet contains a single field.
* A single output frame is really a single field.
* Firmware tags fields as 0x70/0x78 or 0xF0/0xF8

I'd expect tagging to be the same as MPEG2.

The obvious problem is that an MBAFF field pair looks exactly the same
as a PAFF top field.
Whoops. I tried peeking the picture number but if the second field
hasn't been sufficiently
decoded, the peeked number is 0 and tells me nothing. So I have no way
to tell them apart.

4) No idea what this really is (a form of MBAFF?)
* A single input packet contains a single field.
* A single output frame contains a field pair.
* Firmware tags frames as 0x70

I found a sample here: http://samples.mplayerhq.hu/V-codecs/h264/PAFF/Grey.ts

It's identified as a PAFF sample but who knows - not I.

I haven't written code to handle it yet, but I would need to
artificially not return a frame
after each field pair to keep the pipeline stable (ie: the opposite
behaviour of how 3) is
handled).

Wishlist
-----------

I'd really like to see all four cases properly identified with flags,
and if any of them can
be collapsed by the firmware, that would be a bonus. But as it stands
I can't tell the three
H.264 cases apart. :-(

--phil

Scott D. Davilla

unread,
Jan 9, 2011, 5:32:13 PM1/9/11
to crystalhd-...@googlegroups.com
>I hope I'm not just talking to myself here :-)

Don't worry, you are not having a senior moment.

Reply all
Reply to author
Forward
0 new messages