[FFmpeg-devel] [PATCH]Write fiel atom independent of other Video Sample Description Extensions

Tim Nicholson nichot20 at yahoo.com
Mon Feb 4 13:15:10 CET 2013


On 04/02/13 10:59, Carl Eugen Hoyos wrote:
> On Monday 04 February 2013 11:04:30 am Tim Nicholson wrote:
>> On 02/02/13 10:35, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> I may miss something but I don't see why asp or h264 video cannot contain
>>> field handling information.
>>>
>>> As a side-effect, this fixes ticket #2202.
> 
>> I'm not sure about asp or h264, but writing this atom for all codecs if
>> interlace information is set will add it to things like DNX, which does
>> not have it set in "genuine" files.
> 
> I finally found an apple.com encoded h264 mov file with a fiel atom;-)

Good, that pins that one down then.

> 
> Regarding the AVID-based codecs: We currently write the pasp atom for 
> them which is wrong I guess, does the additional atom break playback?

Some of the dnx formats (DnxHD 100 for example) support the "thin
raster" 1440x1080/960x720 in which case the pasp atom is mandated by the
qt spec, so writing it for all DNX cases is probably not a problem.

As to the 'fiel' atom. I don't know if it will break anything without
testing it in a variety of use cases with different hardware/software,
which will take some time to do thoroughly. I am very aware of subtle
little changes that have a habit of becoming showstoppers in a slightly
different use case, for example the -nitris_compat issue which only
reared its head with one specific set of hardware (Although that was a
codec rather than a wrapper issue).

> 
>> A lower impact approach that would still fix #2202 would be to simply
>> bump it to the end of the "else if" set.
> 
> (I wish I hadn't mentioned 2202 which is only partly related.)
> 
> That wouldn't fix the original intend which was to support interlace 
> information with huffyuv and ffvhuff in mov.
> 

Ahh. I thought the idea suggested in the discussion you alluded to
earlier was to put that information in the 'glbl' atom for those codecs.

> Carl Eugen
> [..]


-- 
Tim


More information about the ffmpeg-devel mailing list