Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 --- 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 --- 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. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 > >>>--- > >>> 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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 --- 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 --- 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
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 > > --- > > 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 ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
Marton Balint (12019-12-28): > v2: simplified example > > Signed-off-by: Marton Balint > --- > 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. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
