[PATCH] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Support for mlpa muxing was added back in 2019: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a10... 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)); -- 2.37.1 (Apple Git-137.1)
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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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=808a6717e0c584738c60a10... 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/8da6d4a8fc095a88349fbd...
_______________________________________________ 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=808a6717e0c584738c60a10...
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/8da6d4a8fc095a88349fbd...
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".
participants (5)
-
Carl Eugen Hoyos -
Gijs Peskens -
James Almer -
Jan Ekström -
Nomis101