| Message ID | 12a9e165-5675-2f88-dc59-45061cd250ab@web.de |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa) | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/configure_loongarch64 | warning | Failed to apply patch |
| andriy/configure_x86 | warning | Failed to apply patch |
Am 05.11.22 um 21:31 schrieb Nomis101: > Support for mlpa muxing was added back in 2019: > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 > But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no > support from other applications. > > In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 > For VLC: videolan/vlc@9c49f40 > Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 > And mpv does support this as well. > So, there is no need anymore to hide this behind FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the > user's responsibility to choose this only if the user's software/hardware supports it. > Therefore, this patch removes the experimental status of TrueHD-in-MP4 muxing. > > Signed-off-by: Nomis101 <Nomis101@web.de> > --- > libavformat/movenc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > index 754f95912a..50f1831860 100644 > --- a/libavformat/movenc.c > +++ b/libavformat/movenc.c > @@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s) > } > } > if (track->par->codec_id == AV_CODEC_ID_FLAC || > - track->par->codec_id == AV_CODEC_ID_TRUEHD || > track->par->codec_id == AV_CODEC_ID_OPUS) { > if (track->mode != MODE_MP4) { > av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n", > avcodec_get_name(track->par->codec_id)); Hi all. Patchwork does say something about "Failed to apply patch". Is this somehing I should worry about? And if yes, how to fix it? It has been properly generated using git format-patch.
On 11/6/2022 6:40 PM, Nomis101 wrote: > Am 05.11.22 um 21:31 schrieb Nomis101: >> Support for mlpa muxing was added back in 2019: >> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 >> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because >> it was new and there was no support from other applications. >> >> In the meantime there is support in MediaInfo: >> MediaArea/MediaInfoLib#1258 >> For VLC: videolan/vlc@9c49f40 >> Since version 7.3.4 for Infuse: >> https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 >> And mpv does support this as well. >> So, there is no need anymore to hide this behind >> FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the user's >> responsibility to choose this only if the user's software/hardware >> supports it. >> Therefore, this patch removes the experimental status of TrueHD-in-MP4 >> muxing. >> >> Signed-off-by: Nomis101 <Nomis101@web.de> >> --- >> libavformat/movenc.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c >> index 754f95912a..50f1831860 100644 >> --- a/libavformat/movenc.c >> +++ b/libavformat/movenc.c >> @@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s) >> } >> } >> if (track->par->codec_id == AV_CODEC_ID_FLAC || >> - track->par->codec_id == AV_CODEC_ID_TRUEHD || >> track->par->codec_id == AV_CODEC_ID_OPUS) { >> if (track->mode != MODE_MP4) { >> av_log(s, AV_LOG_ERROR, "%s only supported in >> MP4.\n", avcodec_get_name(track->par->codec_id)); > > > Hi all. Patchwork does say something about "Failed to apply patch". Is > this somehing I should worry about? And if yes, how to fix it? It has > been properly generated using git format-patch. Did you make the patch on top of latest git head (master branch)? It definitely doesn't apply as is.
On 11/5/2022 6:31 PM, Nomis101 wrote: > Support for mlpa muxing was added back in 2019: > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 > But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because > it was new and there was no support from other applications. > > In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 > For VLC: videolan/vlc@9c49f40 > Since version 7.3.4 for Infuse: > https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 > And mpv does support this as well. > So, there is no need anymore to hide this behind > FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the user's responsibility > to choose this only if the user's software/hardware supports it. > Therefore, this patch removes the experimental status of TrueHD-in-MP4 > muxing. > > Signed-off-by: Nomis101 <Nomis101@web.de> > --- > libavformat/movenc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > index 754f95912a..50f1831860 100644 > --- a/libavformat/movenc.c > +++ b/libavformat/movenc.c > @@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s) > } > } > if (track->par->codec_id == AV_CODEC_ID_FLAC || > - track->par->codec_id == AV_CODEC_ID_TRUEHD || > track->par->codec_id == AV_CODEC_ID_OPUS) { > if (track->mode != MODE_MP4) { > av_log(s, AV_LOG_ERROR, "%s only supported in > MP4.\n", avcodec_get_name(track->par->codec_id)); This is wrong. You want to remove the check for experimental flag when using truehd that's after this. This patch as is is preventing other checks from being done (like ensuring truehd is only muxed on mp4 output).
Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: > > Support for mlpa muxing was added back in 2019: > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 > But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no > support from other applications. > > In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 > For VLC: videolan/vlc@9c49f40 > Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 > And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. Carl Eugen
Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: > Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: >> >> Support for mlpa muxing was added back in 2019: >> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 >> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no >> support from other applications. >> >> In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 >> For VLC: videolan/vlc@9c49f40 >> Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 >> And mpv does support this as well. > > If there was ever a good reason to make this feature experimental, > I don't think these applications change the situation. The reason to make this experimental was, because there was no implementation from others at this time. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html Now, there is implementation from others. How many implementation from others will be needed to change the situation? > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Wed, Nov 9, 2022 at 9:15 PM Nomis101 <Nomis101@web.de> wrote: > > Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: > > Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: > >> > >> Support for mlpa muxing was added back in 2019: > >> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 > >> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no > >> support from other applications. > >> > >> In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 > >> For VLC: videolan/vlc@9c49f40 > >> Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 > >> And mpv does support this as well. > > > > If there was ever a good reason to make this feature experimental, > > I don't think these applications change the situation. > > > The reason to make this experimental was, because there was no implementation from others at this time. > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html > Now, there is implementation from others. How many implementation from others will be needed to > change the situation? > I think the main thing was to have the feature verified by non-FFmpeg things. Basically, if you wrote out a TrueHD file and actual 3rd party implementations that didn't just utilize FFmpeg for reading would happily read it, then the flag should be removed. If the VLC commit did not specifically say "we did it like this to enable support for files that FFmpeg generated" but rather that they followed the spec, then that's one alternative implementation indeed. And if MediaInfo or that Infuse thing also added support for the exact same mapping and that neither specifically utilized FFmpeg internally, then those also apply. Finally, I think the D company has a git repo for "dlb_mp4base", you could check if that supports this mapping. Best regards, Jan
Am 11.11.22 um 14:05 schrieb Jan Ekström: > On Wed, Nov 9, 2022 at 9:15 PM Nomis101 <Nomis101@web.de> wrote: >> >> Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: >>> Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: >>>> >>>> Support for mlpa muxing was added back in 2019: >>>> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 >>>> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no >>>> support from other applications. >>>> >>>> In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 >>>> For VLC: videolan/vlc@9c49f40 >>>> Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 >>>> And mpv does support this as well. >>> >>> If there was ever a good reason to make this feature experimental, >>> I don't think these applications change the situation. >> >> >> The reason to make this experimental was, because there was no implementation from others at this time. >> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html >> Now, there is implementation from others. How many implementation from others will be needed to >> change the situation? >> > > I think the main thing was to have the feature verified by non-FFmpeg > things. Basically, if you wrote out a TrueHD file and actual 3rd party > implementations that didn't just utilize FFmpeg for reading would > happily read it, then the flag should be removed. > > If the VLC commit did not specifically say "we did it like this to > enable support for files that FFmpeg generated" but rather that they > followed the spec, then that's one alternative implementation indeed. > And if MediaInfo or that Infuse thing also added support for the exact > same mapping and that neither specifically utilized FFmpeg internally, > then those also apply. > > Finally, I think the D company has a git repo for "dlb_mp4base", you > could check if that supports this mapping. > > Best regards, > Jan OK, thanks Jan for the detailed explanation. I will check D company. Infuse has implemented it independently of FFmpeg. VLC and Mediainfo I do not know. The specs were mentioned in the bug, but also FFmpeg. But both would not implement anything if there was no specification for it. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Am 11.11.22 um 14:48 schrieb Nomis101: > Am 11.11.22 um 14:05 schrieb Jan Ekström: >> On Wed, Nov 9, 2022 at 9:15 PM Nomis101 <Nomis101@web.de> wrote: >>> >>> Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: >>>> Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: >>>>> >>>>> Support for mlpa muxing was added back in 2019: >>>>> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 >>>>> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no >>>>> support from other applications. >>>>> >>>>> In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 >>>>> For VLC: videolan/vlc@9c49f40 >>>>> Since version 7.3.4 for Infuse: >>>>> https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 >>>>> And mpv does support this as well. >>>> >>>> If there was ever a good reason to make this feature experimental, >>>> I don't think these applications change the situation. >>> >>> >>> The reason to make this experimental was, because there was no implementation from others at this >>> time. >>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html >>> Now, there is implementation from others. How many implementation from others will be needed to >>> change the situation? >>> >> >> I think the main thing was to have the feature verified by non-FFmpeg >> things. Basically, if you wrote out a TrueHD file and actual 3rd party >> implementations that didn't just utilize FFmpeg for reading would >> happily read it, then the flag should be removed. >> >> If the VLC commit did not specifically say "we did it like this to >> enable support for files that FFmpeg generated" but rather that they >> followed the spec, then that's one alternative implementation indeed. >> And if MediaInfo or that Infuse thing also added support for the exact >> same mapping and that neither specifically utilized FFmpeg internally, >> then those also apply. >> >> Finally, I think the D company has a git repo for "dlb_mp4base", you >> could check if that supports this mapping. >> >> Best regards, >> Jan > > OK, thanks Jan for the detailed explanation. I will check D company. Infuse has implemented it > independently of FFmpeg. VLC and Mediainfo I do not know. The specs were mentioned in the bug, but > also FFmpeg. But both would not implement anything if there was no specification for it. There is also support in "dlb_mp4base": https://github.com/DolbyLaboratories/dlb_mp4base/blob/8da6d4a8fc095a88349fbdac33e7e68fb3b93649/src/mp4_muxer.c#L149 > > >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 11-11-2022 16:05, Nomis101 wrote: > Am 11.11.22 um 14:48 schrieb Nomis101: >> Am 11.11.22 um 14:05 schrieb Jan Ekström: >>> On Wed, Nov 9, 2022 at 9:15 PM Nomis101 <Nomis101@web.de> wrote: >>>> >>>> Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos: >>>>> Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 <Nomis101@web.de>: >>>>>> >>>>>> Support for mlpa muxing was added back in 2019: >>>>>> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 >>>>>> >>>>>> But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, >>>>>> because it was new and there was no >>>>>> support from other applications. >>>>>> >>>>>> In the meantime there is support in MediaInfo: >>>>>> MediaArea/MediaInfoLib#1258 >>>>>> For VLC: videolan/vlc@9c49f40 >>>>>> Since version 7.3.4 for Infuse: >>>>>> https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 >>>>>> >>>>>> And mpv does support this as well. >>>>> >>>>> If there was ever a good reason to make this feature experimental, >>>>> I don't think these applications change the situation. >>>> >>>> >>>> The reason to make this experimental was, because there was no >>>> implementation from others at this time. >>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248435.html >>>> Now, there is implementation from others. How many implementation >>>> from others will be needed to >>>> change the situation? >>>> >>> >>> I think the main thing was to have the feature verified by non-FFmpeg >>> things. Basically, if you wrote out a TrueHD file and actual 3rd party >>> implementations that didn't just utilize FFmpeg for reading would >>> happily read it, then the flag should be removed. >>> >>> If the VLC commit did not specifically say "we did it like this to >>> enable support for files that FFmpeg generated" but rather that they >>> followed the spec, then that's one alternative implementation indeed. >>> And if MediaInfo or that Infuse thing also added support for the exact >>> same mapping and that neither specifically utilized FFmpeg internally, >>> then those also apply. >>> >>> Finally, I think the D company has a git repo for "dlb_mp4base", you >>> could check if that supports this mapping. >>> >>> Best regards, >>> Jan >> >> OK, thanks Jan for the detailed explanation. I will check D company. >> Infuse has implemented it independently of FFmpeg. VLC and Mediainfo >> I do not know. The specs were mentioned in the bug, but also FFmpeg. >> But both would not implement anything if there was no specification >> for it. > > > There is also support in "dlb_mp4base": > https://github.com/DolbyLaboratories/dlb_mp4base/blob/8da6d4a8fc095a88349fbdac33e7e68fb3b93649/src/mp4_muxer.c#L149 > > But does it correctly demux a variety of files generated by FFMPEG? >> >> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 754f95912a..50f1831860 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -7157,7 +7157,6 @@ static int mov_init(AVFormatContext *s) } } if (track->par->codec_id == AV_CODEC_ID_FLAC || - track->par->codec_id == AV_CODEC_ID_TRUEHD || track->par->codec_id == AV_CODEC_ID_OPUS) { if (track->mode != MODE_MP4) { av_log(s, AV_LOG_ERROR, "%s only supported in MP4.\n",
Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was new and there was no support from other applications. In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 For VLC: videolan/vlc@9c49f40 Since version 7.3.4 for Infuse: https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 And mpv does support this as well. So, there is no need anymore to hide this behind FF_COMPLIANCE_EXPERIMENTAL. Also, it should be the user's responsibility to choose this only if the user's software/hardware supports it. Therefore, this patch removes the experimental status of TrueHD-in-MP4 muxing. Signed-off-by: Nomis101 <Nomis101@web.de> --- libavformat/movenc.c | 1 - 1 file changed, 1 deletion(-) avcodec_get_name(track->par->codec_id)); -- 2.37.1 (Apple Git-137.1)