Hello, I’m doing some debugging of format selection for the decklink device, and in particular trying to get it to properly support interlaced formats. One thing that came to my attention was the following commit:
https://github.com/FFmpeg/FFmpeg/commit/48f8ad329010a93c323569cad695090a5930277b <https://github.com/FFmpeg/FFmpeg/commit/48f8ad329010a93c323569cad695090a5930277b> This patch in principle sets the output format based on the AVCodecParameters field_order member when the write_header() callback is invoked. However, I’ve been doing testing with various transport streams containing MPEG-2 and H.264, and in all cases it seems that the field_order member is always AV_FIELD_UNKNOWN at that point (regardless of whether the content is progressive or interlaced). Marton, when you wrote this patch, what type of content were you testing with? I’m just trying to understand whether this works with some content but not others (in which case I can compare the behavior and make a fix), or if the functionality has *never* actually worked. It seems like at the write_header() phase, we’re never going to actually know what the field order is because we haven’t actually processed any frames and thus don’t know what impact filters might have. 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? Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
