[FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options

Marton Balint cus at passwd.hu
Thu Jan 9 00:49:55 EET 2020



On Wed, 1 Jan 2020, Marton Balint wrote:

>
> On Tue, 31 Dec 2019, Michael Niedermayer wrote:
>
>> On Tue, Dec 31, 2019 at 12:37:02PM +0100, Nicolas George wrote:
>>> Marton Balint (12019-12-28):
>>>> v2: simplified example
>>>>
>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>> ---
>>>>  doc/muxers.texi       | 11 +++++++++++
>>>>  libavformat/img2enc.c | 13 ++++++++++++-
>>>>  2 files changed, 23 insertions(+), 1 deletion(-)
>>>
>>> image2 is not the only demuxer that opens new streams. I think a generic
>>> solution would be preferable.
>>
>> i also had a slightly ungood feeling about the patch but didnt
>> had time to think more about it. a more generic solution like with
>> child AVClasses or something would be interresting but as said i didnt
>> had time to think about this ...
>
> It looks like a big can of worms.
>
> In the AVFMT_NOFILE case there is no IO context, so options can only be 
> passed using avformat_write_header/avformat_init_output.
>
> There is no way to determine which options the protocols will use 
> without actually opening an IO context (protocol options are passed to the 
> url_open method of each protocol), so we have to store all remaining 
> options passed to avformat_write_header/avformat_init_output for possible 
> nested IO use.
>
> In the normal case (non AVFMT_NOFILE) muxers can use nested contexts too, 
> so avio_open should also store the original options, all of them, because 
> the nested contexts might use different protocols. This alone is 
> problematic, because avio_open should return the unrecognized options...
>
> Also it might make sense to specify different IO options for nested 
> contexts than main contexts (or different options for some of the nested 
> contexts)
>
> IMHO being able to specify the nested options separately is a 
> clean solution, admittedly less user friendly, but I don't see how this 
> can work automagically without some major redesign.

Ping for this.

Thanks,
Marton


More information about the ffmpeg-devel mailing list