Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/14/18 4:52 PM, Jeyapal, Karthick wrote: On 11/14/18 1:41 PM, Andrey Semashev wrote: On 11/12/18 3:55 PM, Andrey Semashev wrote: Suppose you want to create a DASH stream consisting of VP8, H264, Vorbis and Opus substreams to cover the best compatibility with clients (which are mostly web browsers, but not necessarilly all of them). AFAIK, you cannot put all these codecs neither in mp4 nor webm. An "auto" option would put Opus in webm container, leaving clients not supporting webm not able to play audio. With explicit container selection one could put Opus content in mp4 or both webm and mp4 (in which case the substream would be duplicated). An example of a client that is picky about container format is Safari on OS X High Sierra. I don't have one to test, but reportedly it supports Opus only in caf format, and I've read someone hacked it to play Opus in mp4 if disguised as AAC. I know lavf/dashenc doesn't support caf (yet) but it may support it in the future, so the container format selection would become even more relevant then. So, what do we decide about this patch? I understand your point. But all your examples are still theoretical(say caf is not supported in dashenc. And opus example doesn't mention any sample clients for that use-case). My view is that, if we can find one practical example where this advanced patch will be of immediate use(which cannot be done by auto option), then let us review and push this patch. If we can't find any immediate practical use-case, which could be tested and verified in popular clients then let's go for auto option. Ok, thanks for your comments. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/14/18 1:41 PM, Andrey Semashev wrote: > On 11/12/18 3:55 PM, Andrey Semashev wrote: > > On 11/12/18 3:12 PM, Jeyapal, Karthick wrote: > >> > >> On 11/12/18 5:20 PM, Andrey Semashev wrote: > >>> On 11/12/18 8:20 AM, Jeyapal, Karthick wrote: > > On 11/8/18 10:27 PM, Andrey Semashev wrote: > > This commit restores the ability to create DASH streams with codecs > > that require different containers that was lost after commit > > 2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the > > dash_segment_type > > option syntax to allow to specify segment container types for > > individual > > streams, in addition to the default container type that is applied to > > all streams. The extended syntax is backward compatible with the > > previous > > syntax. > Thanks for sending the patch. I understand your requirement completely. > But I feel that this option for mapping streams with container > format is little confusing. Also, the relevant code is relatively > big, and thus difficult to maintain in future. > I have a middle ground suggestion. If your goal is to achieve the > earlier behavior broken commits, then I propose the following. > Option "dash_segment_type" could take one more option "auto" > (instead of mp4 or webm). > When "auto" is chosen, the muxer could choose webm format for VP8, > VP9, vorbis, opus streams and mp4 format for all other streams. > In this method the previous behavior of dashenc muxer could be > restored with little addition to the overall code. Also it's usage > will be simpler and easier to understand. > >>> > >>> This solution might be ok for just restoring the previous capability, > >>> but I think the ability for selecting the container format by the > >>> user is still more useful. For example, Opus can be muxed in both mp4 > >>> (although, with experimental flag) and webm, and it may make sense to > >>> some users to select mp4. (In my case, though, I wanted webm, hence > >>> the patch.) > >> In that case they could select "dash_segment_type" as "mp4", in which > >> case all streams including opus will be muxed in mp4 format. I don't > >> see a use-case where somebody wants opus in mp4 and would want other > >> streams in webm format. > > > > Suppose you want to create a DASH stream consisting of VP8, H264, Vorbis > > and Opus substreams to cover the best compatibility with clients (which > > are mostly web browsers, but not necessarilly all of them). AFAIK, you > > cannot put all these codecs neither in mp4 nor webm. An "auto" option > > would put Opus in webm container, leaving clients not supporting webm > > not able to play audio. With explicit container selection one could put > > Opus content in mp4 or both webm and mp4 (in which case the substream > > would be duplicated). > > > > An example of a client that is picky about container format is Safari on > > OS X High Sierra. I don't have one to test, but reportedly it supports > > Opus only in caf format, and I've read someone hacked it to play Opus in > > mp4 if disguised as AAC. I know lavf/dashenc doesn't support caf (yet) > > but it may support it in the future, so the container format selection > > would become even more relevant then. > > So, what do we decide about this patch? I understand your point. But all your examples are still theoretical(say caf is not supported in dashenc. And opus example doesn't mention any sample clients for that use-case). My view is that, if we can find one practical example where this advanced patch will be of immediate use(which cannot be done by auto option), then let us review and push this patch. If we can't find any immediate practical use-case, which could be tested and verified in popular clients then let's go for auto option. > > >>> Besides the parser, it doesn't add much code, and if I can improve > >>> the patch, please let me know how. If you absolutely don't want this > >>> functionality, that's ok, I'll keep this patch for my local builds > >>> and submit an "auto" option patch instead. > >> I am not absolutely against this patch. But I am just trying to find > >> if there is a use-case for such an advanced option. If there is a > >> practical requirement for such a use-case, then I agree that we should > >> review and push this patch for sure. > >> But if the requirement is just theoretical at this point, then I would > >> prefer the "auto" option patch. Maybe we could revisit this advanced > >> options patch when a real requirement comes up. > >>> > > --- > >doc/muxers.texi | 8 ++- > >libavformat/dashenc.c | 161 > > +++--- > >2 files changed, 140 insertions(+), 29 deletions(-) > > > > diff --git a/doc/muxers.texi b/doc/muxers.texi > > index 62f4091e31..4418b38c76 100644 > > --- a/doc/muxers.texi > > +++
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/12/18 3:55 PM, Andrey Semashev wrote:
On 11/12/18 3:12 PM, Jeyapal, Karthick wrote:
On 11/12/18 5:20 PM, Andrey Semashev wrote:
On 11/12/18 8:20 AM, Jeyapal, Karthick wrote:
On 11/8/18 10:27 PM, Andrey Semashev wrote:
This commit restores the ability to create DASH streams with codecs
that require different containers that was lost after commit
2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the
dash_segment_type
option syntax to allow to specify segment container types for
individual
streams, in addition to the default container type that is applied to
all streams. The extended syntax is backward compatible with the
previous
syntax.
Thanks for sending the patch. I understand your requirement completely.
But I feel that this option for mapping streams with container
format is little confusing. Also, the relevant code is relatively
big, and thus difficult to maintain in future.
I have a middle ground suggestion. If your goal is to achieve the
earlier behavior broken commits, then I propose the following.
Option "dash_segment_type" could take one more option "auto"
(instead of mp4 or webm).
When "auto" is chosen, the muxer could choose webm format for VP8,
VP9, vorbis, opus streams and mp4 format for all other streams.
In this method the previous behavior of dashenc muxer could be
restored with little addition to the overall code. Also it's usage
will be simpler and easier to understand.
This solution might be ok for just restoring the previous capability,
but I think the ability for selecting the container format by the
user is still more useful. For example, Opus can be muxed in both mp4
(although, with experimental flag) and webm, and it may make sense to
some users to select mp4. (In my case, though, I wanted webm, hence
the patch.)
In that case they could select "dash_segment_type" as "mp4", in which
case all streams including opus will be muxed in mp4 format. I don't
see a use-case where somebody wants opus in mp4 and would want other
streams in webm format.
Suppose you want to create a DASH stream consisting of VP8, H264, Vorbis
and Opus substreams to cover the best compatibility with clients (which
are mostly web browsers, but not necessarilly all of them). AFAIK, you
cannot put all these codecs neither in mp4 nor webm. An "auto" option
would put Opus in webm container, leaving clients not supporting webm
not able to play audio. With explicit container selection one could put
Opus content in mp4 or both webm and mp4 (in which case the substream
would be duplicated).
An example of a client that is picky about container format is Safari on
OS X High Sierra. I don't have one to test, but reportedly it supports
Opus only in caf format, and I've read someone hacked it to play Opus in
mp4 if disguised as AAC. I know lavf/dashenc doesn't support caf (yet)
but it may support it in the future, so the container format selection
would become even more relevant then.
So, what do we decide about this patch?
Besides the parser, it doesn't add much code, and if I can improve
the patch, please let me know how. If you absolutely don't want this
functionality, that's ok, I'll keep this patch for my local builds
and submit an "auto" option patch instead.
I am not absolutely against this patch. But I am just trying to find
if there is a use-case for such an advanced option. If there is a
practical requirement for such a use-case, then I agree that we should
review and push this patch for sure.
But if the requirement is just theoretical at this point, then I would
prefer the "auto" option patch. Maybe we could revisit this advanced
options patch when a real requirement comes up.
---
doc/muxers.texi | 8 ++-
libavformat/dashenc.c | 161
+++---
2 files changed, 140 insertions(+), 29 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 62f4091e31..4418b38c76 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -289,8 +289,12 @@ Set container format (mp4/webm) options using
a @code{:} separated list of
key=value parameters. Values containing @code{:} special
characters must be
escaped.
-@item dash_segment_type @var{dash_segment_type}
-Possible values:
+@item -dash_segment_type @var{dash_segment_type}
+Sets the container type for dash segment files. Syntax is "
:a,b,c :d,e" where is
+the container type and a, b, c, d and e are the indices of the
mapped streams. When no indices are specified,
+the container type is set for all streams.
+
+Possible container type values:
@item mp4
If this flag is set, the dash segment files will be in in
ISOBMFF format. This is the default format.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f8b3d106d5..626dc76413 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -84,6 +84,8 @@ typedef struct OutputStream {
int64_t first_pts, start_pts, max_pts;
int64_t last_dts, last_pts;
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/12/18 3:12 PM, Jeyapal, Karthick wrote:
On 11/12/18 5:20 PM, Andrey Semashev wrote:
On 11/12/18 8:20 AM, Jeyapal, Karthick wrote:
On 11/8/18 10:27 PM, Andrey Semashev wrote:
This commit restores the ability to create DASH streams with codecs
that require different containers that was lost after commit
2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the dash_segment_type
option syntax to allow to specify segment container types for individual
streams, in addition to the default container type that is applied to
all streams. The extended syntax is backward compatible with the previous
syntax.
Thanks for sending the patch. I understand your requirement completely.
But I feel that this option for mapping streams with container format is little
confusing. Also, the relevant code is relatively big, and thus difficult to
maintain in future.
I have a middle ground suggestion. If your goal is to achieve the earlier
behavior broken commits, then I propose the following.
Option "dash_segment_type" could take one more option "auto" (instead of mp4 or
webm).
When "auto" is chosen, the muxer could choose webm format for VP8, VP9, vorbis,
opus streams and mp4 format for all other streams.
In this method the previous behavior of dashenc muxer could be restored with
little addition to the overall code. Also it's usage will be simpler and easier
to understand.
This solution might be ok for just restoring the previous capability, but I
think the ability for selecting the container format by the user is still more
useful. For example, Opus can be muxed in both mp4 (although, with experimental
flag) and webm, and it may make sense to some users to select mp4. (In my case,
though, I wanted webm, hence the patch.)
In that case they could select "dash_segment_type" as "mp4", in which case all
streams including opus will be muxed in mp4 format. I don't see a use-case where somebody wants
opus in mp4 and would want other streams in webm format.
Suppose you want to create a DASH stream consisting of VP8, H264, Vorbis
and Opus substreams to cover the best compatibility with clients (which
are mostly web browsers, but not necessarilly all of them). AFAIK, you
cannot put all these codecs neither in mp4 nor webm. An "auto" option
would put Opus in webm container, leaving clients not supporting webm
not able to play audio. With explicit container selection one could put
Opus content in mp4 or both webm and mp4 (in which case the substream
would be duplicated).
An example of a client that is picky about container format is Safari on
OS X High Sierra. I don't have one to test, but reportedly it supports
Opus only in caf format, and I've read someone hacked it to play Opus in
mp4 if disguised as AAC. I know lavf/dashenc doesn't support caf (yet)
but it may support it in the future, so the container format selection
would become even more relevant then.
Besides the parser, it doesn't add much code, and if I can improve the patch, please let
me know how. If you absolutely don't want this functionality, that's ok, I'll keep this
patch for my local builds and submit an "auto" option patch instead.
I am not absolutely against this patch. But I am just trying to find if there
is a use-case for such an advanced option. If there is a practical requirement
for such a use-case, then I agree that we should review and push this patch for
sure.
But if the requirement is just theoretical at this point, then I would prefer the
"auto" option patch. Maybe we could revisit this advanced options patch when a
real requirement comes up.
---
doc/muxers.texi | 8 ++-
libavformat/dashenc.c | 161 +++---
2 files changed, 140 insertions(+), 29 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 62f4091e31..4418b38c76 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -289,8 +289,12 @@ Set container format (mp4/webm) options using a @code{:}
separated list of
key=value parameters. Values containing @code{:} special characters must be
escaped.
-@item dash_segment_type @var{dash_segment_type}
-Possible values:
+@item -dash_segment_type @var{dash_segment_type}
+Sets the container type for dash segment files. Syntax is " :a,b,c
:d,e" where is
+the container type and a, b, c, d and e are the indices of the mapped streams.
When no indices are specified,
+the container type is set for all streams.
+
+Possible container type values:
@item mp4
If this flag is set, the dash segment files will be in in ISOBMFF format.
This is the default format.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f8b3d106d5..626dc76413 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -84,6 +84,8 @@ typedef struct OutputStream {
int64_t first_pts, start_pts, max_pts;
int64_t last_dts, last_pts;
int bit_rate;
+SegmentType segment_type;
+const char *format_name;
char
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/12/18 5:20 PM, Andrey Semashev wrote:
> On 11/12/18 8:20 AM, Jeyapal, Karthick wrote:
>>
>> On 11/8/18 10:27 PM, Andrey Semashev wrote:
>>> This commit restores the ability to create DASH streams with codecs
>>> that require different containers that was lost after commit
>>> 2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the dash_segment_type
>>> option syntax to allow to specify segment container types for individual
>>> streams, in addition to the default container type that is applied to
>>> all streams. The extended syntax is backward compatible with the previous
>>> syntax.
>> Thanks for sending the patch. I understand your requirement completely.
>> But I feel that this option for mapping streams with container format is
>> little confusing. Also, the relevant code is relatively big, and thus
>> difficult to maintain in future.
>> I have a middle ground suggestion. If your goal is to achieve the earlier
>> behavior broken commits, then I propose the following.
>> Option "dash_segment_type" could take one more option "auto" (instead of mp4
>> or webm).
>> When "auto" is chosen, the muxer could choose webm format for VP8, VP9,
>> vorbis, opus streams and mp4 format for all other streams.
>> In this method the previous behavior of dashenc muxer could be restored with
>> little addition to the overall code. Also it's usage will be simpler and
>> easier to understand.
>
> This solution might be ok for just restoring the previous capability, but I
> think the ability for selecting the container format by the user is still
> more useful. For example, Opus can be muxed in both mp4 (although, with
> experimental flag) and webm, and it may make sense to some users to select
> mp4. (In my case, though, I wanted webm, hence the patch.)
In that case they could select "dash_segment_type" as "mp4", in which case all
streams including opus will be muxed in mp4 format. I don't see a use-case
where somebody wants opus in mp4 and would want other streams in webm format.
>
> Besides the parser, it doesn't add much code, and if I can improve the patch,
> please let me know how. If you absolutely don't want this functionality,
> that's ok, I'll keep this patch for my local builds and submit an "auto"
> option patch instead.
I am not absolutely against this patch. But I am just trying to find if there
is a use-case for such an advanced option. If there is a practical requirement
for such a use-case, then I agree that we should review and push this patch for
sure.
But if the requirement is just theoretical at this point, then I would prefer
the "auto" option patch. Maybe we could revisit this advanced options patch
when a real requirement comes up.
>
>>> ---
>>> doc/muxers.texi | 8 ++-
>>> libavformat/dashenc.c | 161 +++---
>>> 2 files changed, 140 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index 62f4091e31..4418b38c76 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -289,8 +289,12 @@ Set container format (mp4/webm) options using a
>>> @code{:} separated list of
>>> key=value parameters. Values containing @code{:} special characters must
>>> be
>>> escaped.
>>> -@item dash_segment_type @var{dash_segment_type}
>>> -Possible values:
>>> +@item -dash_segment_type @var{dash_segment_type}
>>> +Sets the container type for dash segment files. Syntax is "
>>> :a,b,c :d,e" where is
>>> +the container type and a, b, c, d and e are the indices of the mapped
>>> streams. When no indices are specified,
>>> +the container type is set for all streams.
>>> +
>>> +Possible container type values:
>>> @item mp4
>>> If this flag is set, the dash segment files will be in in ISOBMFF format.
>>> This is the default format.
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index f8b3d106d5..626dc76413 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -84,6 +84,8 @@ typedef struct OutputStream {
>>> int64_t first_pts, start_pts, max_pts;
>>> int64_t last_dts, last_pts;
>>> int bit_rate;
>>> +SegmentType segment_type;
>>> +const char *format_name;
>>> char codec_str[100];
>>> int written_len;
>>> @@ -131,8 +133,7 @@ typedef struct DASHContext {
>>> int64_t timeout;
>>> int index_correction;
>>> char *format_options_str;
>>> -SegmentType segment_type;
>>> -const char *format_name;
>>> +const char *segment_types_str;
>>> } DASHContext;
>>> static struct codec_string {
>>> @@ -188,14 +189,6 @@ static void dashenc_io_close(AVFormatContext *s,
>>> AVIOContext **pb, char *filenam
>>> }
>>> }
>>> -static const char *get_format_str(SegmentType segment_type) {
>>> -int i;
>>> -for (i = 0; i < SEGMENT_TYPE_NB; i++)
>>> -if (formats[i].segment_type == segment_type)
>>> -return formats[i].str;
>>> -return NULL;
>>> -}
>>> -
>>>
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/12/18 8:20 AM, Jeyapal, Karthick wrote:
On 11/8/18 10:27 PM, Andrey Semashev wrote:
This commit restores the ability to create DASH streams with codecs
that require different containers that was lost after commit
2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the dash_segment_type
option syntax to allow to specify segment container types for individual
streams, in addition to the default container type that is applied to
all streams. The extended syntax is backward compatible with the previous
syntax.
Thanks for sending the patch. I understand your requirement completely.
But I feel that this option for mapping streams with container format is little
confusing. Also, the relevant code is relatively big, and thus difficult to
maintain in future.
I have a middle ground suggestion. If your goal is to achieve the earlier
behavior broken commits, then I propose the following.
Option "dash_segment_type" could take one more option "auto" (instead of mp4 or
webm).
When "auto" is chosen, the muxer could choose webm format for VP8, VP9, vorbis,
opus streams and mp4 format for all other streams.
In this method the previous behavior of dashenc muxer could be restored with
little addition to the overall code. Also it's usage will be simpler and easier
to understand.
This solution might be ok for just restoring the previous capability,
but I think the ability for selecting the container format by the user
is still more useful. For example, Opus can be muxed in both mp4
(although, with experimental flag) and webm, and it may make sense to
some users to select mp4. (In my case, though, I wanted webm, hence the
patch.)
Besides the parser, it doesn't add much code, and if I can improve the
patch, please let me know how. If you absolutely don't want this
functionality, that's ok, I'll keep this patch for my local builds and
submit an "auto" option patch instead.
---
doc/muxers.texi | 8 ++-
libavformat/dashenc.c | 161 +++---
2 files changed, 140 insertions(+), 29 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 62f4091e31..4418b38c76 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -289,8 +289,12 @@ Set container format (mp4/webm) options using a @code{:}
separated list of
key=value parameters. Values containing @code{:} special characters must be
escaped.
-@item dash_segment_type @var{dash_segment_type}
-Possible values:
+@item -dash_segment_type @var{dash_segment_type}
+Sets the container type for dash segment files. Syntax is " :a,b,c
:d,e" where is
+the container type and a, b, c, d and e are the indices of the mapped streams.
When no indices are specified,
+the container type is set for all streams.
+
+Possible container type values:
@item mp4
If this flag is set, the dash segment files will be in in ISOBMFF format.
This is the default format.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f8b3d106d5..626dc76413 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -84,6 +84,8 @@ typedef struct OutputStream {
int64_t first_pts, start_pts, max_pts;
int64_t last_dts, last_pts;
int bit_rate;
+SegmentType segment_type;
+const char *format_name;
char codec_str[100];
int written_len;
@@ -131,8 +133,7 @@ typedef struct DASHContext {
int64_t timeout;
int index_correction;
char *format_options_str;
-SegmentType segment_type;
-const char *format_name;
+const char *segment_types_str;
} DASHContext;
static struct codec_string {
@@ -188,14 +189,6 @@ static void dashenc_io_close(AVFormatContext *s,
AVIOContext **pb, char *filenam
}
}
-static const char *get_format_str(SegmentType segment_type) {
-int i;
-for (i = 0; i < SEGMENT_TYPE_NB; i++)
-if (formats[i].segment_type == segment_type)
-return formats[i].str;
-return NULL;
-}
-
static int check_file_extension(const char *filename, const char *extension) {
char *dot;
if (!filename || !extension)
@@ -375,6 +368,8 @@ static void dash_free(AVFormatContext *s)
c->nb_as = 0;
}
+av_freep(>segment_types_str);
+
if (!c->streams)
return;
for (i = 0; i < s->nb_streams; i++) {
@@ -621,13 +616,13 @@ static int write_adaptation_set(AVFormatContext *s,
AVIOContext *out, int as_ind
if (as->media_type == AVMEDIA_TYPE_VIDEO) {
AVStream *st = s->streams[i];
avio_printf(out, "\t\t\tformat_name, os->codec_str, bandwidth_str,
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
+i, os->format_name, os->codec_str, bandwidth_str,
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
if (st->avg_frame_rate.num)
avio_printf(out, " frameRate=\"%d/%d\"", st->avg_frame_rate.num,
st->avg_frame_rate.den);
avio_printf(out, ">\n");
}
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Add support for per-stream container type selection.
On 11/8/18 10:27 PM, Andrey Semashev wrote:
> This commit restores the ability to create DASH streams with codecs
> that require different containers that was lost after commit
> 2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the dash_segment_type
> option syntax to allow to specify segment container types for individual
> streams, in addition to the default container type that is applied to
> all streams. The extended syntax is backward compatible with the previous
> syntax.
Thanks for sending the patch. I understand your requirement completely.
But I feel that this option for mapping streams with container format is little
confusing. Also, the relevant code is relatively big, and thus difficult to
maintain in future.
I have a middle ground suggestion. If your goal is to achieve the earlier
behavior broken commits, then I propose the following.
Option "dash_segment_type" could take one more option "auto" (instead of mp4 or
webm).
When "auto" is chosen, the muxer could choose webm format for VP8, VP9, vorbis,
opus streams and mp4 format for all other streams.
In this method the previous behavior of dashenc muxer could be restored with
little addition to the overall code. Also it's usage will be simpler and easier
to understand.
> ---
> doc/muxers.texi | 8 ++-
> libavformat/dashenc.c | 161 +++---
> 2 files changed, 140 insertions(+), 29 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 62f4091e31..4418b38c76 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -289,8 +289,12 @@ Set container format (mp4/webm) options using a @code{:}
> separated list of
> key=value parameters. Values containing @code{:} special characters must be
> escaped.
>
> -@item dash_segment_type @var{dash_segment_type}
> -Possible values:
> +@item -dash_segment_type @var{dash_segment_type}
> +Sets the container type for dash segment files. Syntax is "
> :a,b,c :d,e" where is
> +the container type and a, b, c, d and e are the indices of the mapped
> streams. When no indices are specified,
> +the container type is set for all streams.
> +
> +Possible container type values:
> @item mp4
> If this flag is set, the dash segment files will be in in ISOBMFF format.
> This is the default format.
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f8b3d106d5..626dc76413 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -84,6 +84,8 @@ typedef struct OutputStream {
> int64_t first_pts, start_pts, max_pts;
> int64_t last_dts, last_pts;
> int bit_rate;
> +SegmentType segment_type;
> +const char *format_name;
>
> char codec_str[100];
> int written_len;
> @@ -131,8 +133,7 @@ typedef struct DASHContext {
> int64_t timeout;
> int index_correction;
> char *format_options_str;
> -SegmentType segment_type;
> -const char *format_name;
> +const char *segment_types_str;
> } DASHContext;
>
> static struct codec_string {
> @@ -188,14 +189,6 @@ static void dashenc_io_close(AVFormatContext *s,
> AVIOContext **pb, char *filenam
> }
> }
>
> -static const char *get_format_str(SegmentType segment_type) {
> -int i;
> -for (i = 0; i < SEGMENT_TYPE_NB; i++)
> -if (formats[i].segment_type == segment_type)
> -return formats[i].str;
> -return NULL;
> -}
> -
> static int check_file_extension(const char *filename, const char *extension)
> {
> char *dot;
> if (!filename || !extension)
> @@ -375,6 +368,8 @@ static void dash_free(AVFormatContext *s)
> c->nb_as = 0;
> }
>
> +av_freep(>segment_types_str);
> +
> if (!c->streams)
> return;
> for (i = 0; i < s->nb_streams; i++) {
> @@ -621,13 +616,13 @@ static int write_adaptation_set(AVFormatContext *s,
> AVIOContext *out, int as_ind
> if (as->media_type == AVMEDIA_TYPE_VIDEO) {
> AVStream *st = s->streams[i];
> avio_printf(out, "\t\t\t mimeType=\"video/%s\" codecs=\"%s\"%s width=\"%d\" height=\"%d\"",
> -i, c->format_name, os->codec_str, bandwidth_str,
> s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
> +i, os->format_name, os->codec_str, bandwidth_str,
> s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
> if (st->avg_frame_rate.num)
> avio_printf(out, " frameRate=\"%d/%d\"",
> st->avg_frame_rate.num, st->avg_frame_rate.den);
> avio_printf(out, ">\n");
> } else {
> avio_printf(out, "\t\t\t mimeType=\"audio/%s\" codecs=\"%s\"%s audioSamplingRate=\"%d\">\n",
> -i, c->format_name, os->codec_str, bandwidth_str,
> s->streams[i]->codecpar->sample_rate);
> +i, os->format_name, os->codec_str, bandwidth_str,
> s->streams[i]->codecpar->sample_rate);
> avio_printf(out, "\t\t\t\t
