diff mbox series

[FFmpeg-devel] avformat/mov: Fix endian-dependent parsing

Message ID AM7PR03MB6660D256CE0D1451F3801FDC8F5B9@AM7PR03MB6660.eurprd03.prod.outlook.com
State Accepted
Commit c8b11b28d1eb8dfa34c727c5da9b266124196799
Headers show
Series [FFmpeg-devel] avformat/mov: Fix endian-dependent parsing | expand

Checks

Context Check Description
andriy/make_x86 success Make finished
andriy/make_fate_x86 success Make fate finished
andriy/make_ppc success Make finished
andriy/make_fate_ppc success Make fate finished
andriy/make_aarch64_jetson success Make finished
andriy/make_fate_aarch64_jetson success Make fate finished

Commit Message

Andreas Rheinhardt Jan. 21, 2022, 10:08 a.m. UTC
MOVAtom.type is always read as a little-endian number
(despite MOV/ISOBMFF being big-endian).
Fixes the matroska-dovi-write-config8 FATE-test on big-endian
arches (which runs into the "index out of range" warning message).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
---
A few days ago I sent a patch using the dv84.mov sample
that also failed on the PPC BE endian FATE box, yet this test
reencoded the audio and so I blamed this (despite encoder and
decoder being fixed-point); see [1]. Seems like I was wrong
and the fixed-point codecs are indeed bitexact.

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-January/291792.html

 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Martin Storsjö Jan. 21, 2022, 10:52 a.m. UTC | #1
On Fri, 21 Jan 2022, Andreas Rheinhardt wrote:

> MOVAtom.type is always read as a little-endian number
> (despite MOV/ISOBMFF being big-endian).
> Fixes the matroska-dovi-write-config8 FATE-test on big-endian
> arches (which runs into the "index out of range" warning message).
>
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> ---
> A few days ago I sent a patch using the dv84.mov sample
> that also failed on the PPC BE endian FATE box, yet this test
> reencoded the audio and so I blamed this (despite encoder and
> decoder being fixed-point); see [1]. Seems like I was wrong
> and the fixed-point codecs are indeed bitexact.
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-January/291792.html
>
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index e401cd39b5..1437d160f8 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -407,7 +407,7 @@ retry:
>             atom.size -= 16;
>
>             if (!key && c->found_hdlr_mdta && c->meta_keys) {
> -                uint32_t index = AV_RB32(&atom.type);
> +                uint32_t index = av_bswap32(atom.type); // BE number has been read as LE

LGTM.

// Martin
diff mbox series

Patch

diff --git a/libavformat/mov.c b/libavformat/mov.c
index e401cd39b5..1437d160f8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -407,7 +407,7 @@  retry:
             atom.size -= 16;
 
             if (!key && c->found_hdlr_mdta && c->meta_keys) {
-                uint32_t index = AV_RB32(&atom.type);
+                uint32_t index = av_bswap32(atom.type); // BE number has been read as LE
                 if (index < c->meta_keys_count && index > 0) {
                     key = c->meta_keys[index];
                 } else if (atom.type != MKTAG('c', 'o', 'v', 'r')) {