[FFmpeg-devel] [PATCH] vc1: signal interlaced and tff flag to the consumer

Michael Niedermayer michaelni at gmx.at
Thu Jun 21 18:43:43 CEST 2012

On Thu, Jun 21, 2012 at 10:17:21PM +0600, Mashiat Sarker Shakkhar wrote:
> On 6/21/2012 10:03 PM, Michael Niedermayer wrote:
> [...]
> >iam not 100% sure its correct, ive checked the spec and its not really
> >clear. There are 2 things normally,
> >1. if the video content is interlaced
> "if the video content may include interlaced pictures": stored in
> v->interlace
> >2. how it is compressed/stored
> "how a particular picture is compressed / stored": stored in v->fcm
> (frame coding mode)

> >The spec doesnt clearly seperate these ...
> It does.

Interlacing vs. progressive is about the time at which the even and
odd lines of a frame have been sampled.
if the times match its progressive if not its interlace content
this is what the AVFrame.interlaced flag stores.

The only reference in the spec toward the temporal structure ive found
5.1 Introduction
There are two fundamental picture sampling structures: progressive and interlaced. The progressive sampling structure
assumes that all sample rows of the frame are sequential. The interlaced sampling structure assumes that top fields are
acquired within one time interval and the bottom fields are acquired within a different time interval.

The 2 options are then described in:

5.2 Progressive Coding Mode ...
5.3 Interlace Coding Mode ...

This is where the problem starts, "coding" is about storage not

So when the spec later refers to "frame coding mode" does this refer
to as you suggest the coding mode or does it refer to the coding mode
as described in 5.2/5.3 which is actually the sampling structure.

or is coding mode == sampling structure always?

To me it isnt clear how this should be interpreted ...

> >so the code might need finetuuning later if our interpretation of the
> >spec is found to not match actual files ...
> I don't think there's anything left to interpretation.
> As you can see, Hendrik is using v->fcm, not v->interlace - so it
> looks correct to me.

iam happy to apply the patch (which i will do shortly) but at the
least to me the spec is ambigous

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120621/d4878d56/attachment.asc>

More information about the ffmpeg-devel mailing list