[FFmpeg-devel] Field order during libavformat write_header

[Devin Heitmueller]

Hi Marton,

> As far as I remember ffmpeg.c has code for this around line 1220:
> 
>  if (in_picture->interlaced_frame) {
>     if (enc->codec->id == AV_CODEC_ID_MJPEG)
>        mux_par->field_order = in_picture->top_field_first ? AV_FIELD_TT:AV_FIELD_BB;
>     else
>        mux_par->field_order = in_picture->top_field_first ? AV_FIELD_TB:AV_FIELD_BT;
>  } else
>     mux_par->field_order = AV_FIELD_PROGRESSIVE;
> 
> Isn't this supposed to set the muxer field order prior to calling write_header? Why doesn't this work for decklink?

I saw this code and thought that as well, until I added a printf() inside the decklink module and realized that the code path never got hit until after write_header() was already called.

> 
>> Hence I would need to defer setting the output format and enabling the output until we have received the first frame of real video (relying on the AVFrame’s interlaced property), moving the functionality from the write_header() callback to write_packet().  Alternatively I could let write_header() enable the output, and then be prepared to reconfigure the output if I receive a frame where the interlaced property differs.
>> 
>> Thoughts?
> 
> As I said, ffmpeg.c should handle this properly. Delayed initialization of the video device might be an option, but generally I'd avoid it unless we have a very good reason for it.

Agreed.  I don’t want to do it unless it’s necessary, and then it becomes a question of whether we don’t enable it at all until we get the first packet, or we go through the.existing sequence where it gets enabled at the call to write_header() and then we reconfigure the output if something changes after that.

Devin