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

[Michael Niedermayer]

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.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200109/6886cc08/attachment.sig>