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

[Marton Balint]

On Wed, 15 Jan 2020, Marton Balint wrote:

>
>
> On Thu, 9 Jan 2020, Michael Niedermayer wrote:
>
>> On Wed, Jan 01, 2020 at 08:10:06PM +0100, 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.
>>
>> ok, yes i agree it would need a too major redesign.
>
> Ok, I will apply in a few days if I receive no further comments.

Applied.

Thanks,
Marton