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

[Marton Balint]

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.

Regards,
Marton