Hi Marton,
> I still think ffmpeg.c should be fixed instead. There is even some logic in
> ffmpeg.c to wait for a frame from all streams before writing the header, so
> it seems doable.
I don’t disagree with this in principle, but we have to be a bit careful.
There are stream types that gener
On Wed, 21 Mar 2018, Devin Heitmueller wrote:
Hi James,
No, this is done after that, while processing a packet.
It is also making changes to the output codecpar after write_header()
was called, which is wrong.
libavformat used to delay writing the header until you feed it the first
packet,
Hi James,
> No, this is done after that, while processing a packet.
> It is also making changes to the output codecpar after write_header()
> was called, which is wrong.
>
> libavformat used to delay writing the header until you feed it the first
> packet, an internal functionality this code here
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
On 3/21/2018 4:18 PM, Marton Balint wrote:
>
>
> On Wed, 21 Mar 2018, Devin Heitmueller wrote:
>
>> 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 atten
On Wed, 21 Mar 2018, Devin Heitmueller wrote:
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/FF
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
