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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
