[FFmpeg-devel] [RFC] interlace flagging and detecting.

Michael Niedermayer michaelni at gmx.at
Wed Oct 10 18:35:23 CEST 2012


On Wed, Oct 10, 2012 at 05:21:10PM +0100, Tim Nicholson wrote:
> On 09/10/12 22:26, Michael Niedermayer wrote:
> > On Tue, Oct 09, 2012 at 03:52:50PM +0100, Tim Nicholson wrote:
> >> I am trying to tie up some loose ends in the interlace flagging within
> >> ffmpeg brought to light by attempting to sort out the missing, but
> >> mandatory 'fiel' atom in uncompressed quicktimes.
> >>
> >> I could do with some confirmation from those more familiar that I am on
> >> the right track.
> >>
> >> From what I have gleaned by poring over the code, ffmpeg and libraries
> >> principally use the AVFrame struct 'interlaced_frame' and
> >> 'top_field_first' flags, although there is also AVCodecContext's
> >> field_order enum which seems to exist in order to cover the flag
> >> permutations required by the qt fiel atom. AFAIK currently these two are
> >> completely independent. I can find no code to link them or use one if
> >> the other is blank.
> >>
> > 
> >> For example, a sample uncompressed 2vuy .mov when inspected by 'ffprobe
> >> -show_frames' has interlaced_frame and top_field_first = 0 whilst the
> >> 'fiel' atom indicates interlaced/bottom field first.
> > 
> > thats a bug, the decoder should read the field_order from the context
> > and fill it in the AVFrames it returns
> > 
> 
> As this field_order is mov specific, shouldn't the mov demuxer inject
> this into the usual place so the decoders only need to check one place
> irrespective of format?

The demuxer places it in AVCodecContext.field_order the decoder moves
it into the AVFrames. The demuxer has no access to one, none or
multiple decoders in seperate threads generating AVFrames.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20121010/50a5a2aa/attachment.asc>


More information about the ffmpeg-devel mailing list