[FFmpeg-devel] [PATCH 1 of 1] movenc: enable writing of interlace information back to the 'fiel' atom. (3rd Version)

Tim Nicholson nichot20 at yahoo.com
Fri Nov 2 14:15:11 CET 2012

On 01/11/12 22:01, Michael Niedermayer wrote:
> On Thu, Nov 01, 2012 at 03:31:42PM +0000, Tim Nicholson wrote:
>> On 01/11/12 14:53, Michael Niedermayer wrote:
>>> [..]
>>> This does not look safe.
>>> the encoder (that can run in a seperate thread) can free or change the
>>> coded_frame. Even if it zeros the pointer before freeing above is
>>> not atomic, the pointer is checked to be not NULL then loaded into
>>> a register and then top_field_first read based on this pointer.
>>> if the data is freed between these it can crash or produce undefined
>>> behavior.
>> From what I could see the data is only freed within the *close function
>> of the encoder, but not during the *encode2 function. As the close
>> function(s) are called after the the output file(s) are flushed and
>> closed in the main ffmpeg transcode() function, I thought this would be
>> safe.
> does it work with applications other than ffmpeg itself ?
> also consider some application might use libavformat without a
> libavcodec based encoder. And muxers should have this information
> at their disposal if they need it before the first frame is submited
> to the encoder so it can be put in a header that is sent as early as
> possible.
>> If this is not the case then afaik the *only* safe thing is to set
>> the flag in the encoder encode function, but this will happen every
>> frame which feels OTT! (but would keep the code self contained) I am
>> happy to do it this way if it is acceptable.
> Would it be possible for the user application to set this information
> correctly before writing the file header ?
> That is that the muxer would then just read it out of AVCodecContext
> ?
> [...]

Attached a new version that works  within ffmpeg when it is setting up
the other interlace flags the muxer then works as described above..

I have followed the current logic that in the absence of user
intervention use the input settings, so that the value of
enc->field_order is in sync with big_picture.interlaced_frame &
big_picture.top_field_first. It could be argued that in the absence of
specific user setting of interlaced flags (ildct etc) the output should
be flagged as progressive, but in that case both sets of flags should be
forced to progressive to keep them in sync.

As there have been reports of FCP assuming material is interlaced unless
the fiel atom says otherwise, I have made sure that the flag is set one
way or the other and not left undefined.

Updated fate checksums included.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ffmpeg-add-setting-of-field_order-flag.patch
Type: text/x-patch
Size: 8030 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121102/6b99d1a5/attachment.bin>

More information about the ffmpeg-devel mailing list