[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