#use-audio-data bug

14 messages · Page 1 of 1 (latest)

plush river
#

we are facing error in calling use-audio-data that we weren't facing on our older versions
the error is happening on version 286 and 287 but it is ok on 265
audio_data url: https://cdn.flowjin.com/Fsqf8HkGxMR489NvHWiHjZ.m4a
audio codec : aac
i will add the log in the

#

./node_modules/.bin/remotion lambda render --function-name=remotion-render-4-0-287-mem8192mb-disk8192mb-900sec --region=eu-central-1 --props=remotion-render/test.json --frame_per_lambda=48 --scale=0.65 site-name root-composition
Bucket: bucket-name
Function: remotion-render-4-0-287-mem8192mb-disk8192mb-900sec
Render ID: 76eaps0rr5
progress.json: https://eu-central-1.console.aws.amazon.com/s3/object/bucket-name?region=eu-central-1&bucketType=general&prefix=renders/76eaps0rr5/progress.json
Codec: h264 (default)
16% • 106 λ • $0.187 • Timeout 885s
Got composition ━━━━━━━━━━━━━━━━━━ 8390ms
Invoking lambdas ━━━━━━━━━━━╺━━━━━━ 66/105
Rendering frames ━━━━━━━━━━━━━━━━━━ 0/7200
Encoding frames ━━━━━━━━━━━━━━━━━━ 0/7200
Combining chunks ━━━━━━━━━━━━━━━━━━ 0%

An error occurred on chunk 0:
DOMException EncodingError: Unable to decode audio data
at cancelRender (https://bucket-name.s3.eu-central-1.amazonaws.com/sites/site-name/bundle.js:78224:21)

at node_modules/remotion/dist/esm/index.mjs:1471
1469 │ error = err;
1470 │ if (!error.stack) {
1471 │ error.stack = new Error(error.message).stack;
1472 │ }
1473 │ } else if (typeof err === "string") {
1474 │ error = Error(err);

at (node_modules/@remotion/media-utils/dist/use-audio-data.js:33)
An error occurred:
Error EncodingError: Unable to decode audio data
at cancelRender (https://bucket-name.s3.eu-central-1.amazonaws.com/sites/site-name/bundle.js:78224:21)
at https://bucket-name.s3.eu-central-1.amazonaws.com/sites/site-name/bundle.js:13342:41

at node_modules/remotion/dist/esm/index.mjs:1471
1469 │ error = err;
1470 │ if (!error.stack) {
1471 │ error.stack = new Error(error.message).stack;
1472 │ }
1473 │ } else if (typeof err === "string") {
1474 │ error = Error(err);

at (node_modules/@remotion/media-utils/dist/use-audio-data.js:33)

plush river
#

279 had the same problem
I am binary searching the versions to see which version changes caused the problem
273 was ok
278 had the problem
I couldn't deploy 277 276 275 274 versions (function size was to big for lambda )

narrow fable
#

Hello,

Convert AAC audio files (.m4a) to MP3 using ffmpeg, then use those MP3s in your Remotion project.
This should fix the "Unable to decode audio data" error that occurs in the latest versions.

Thanks

plush river
#

Yes it can but all our medias are in m4a and we can't convert them to wav or mp3

narrow fable
#

I see,

For a quick fix, keep your Remotion version locked to v273 (the latest working version) until the M4A decoding issue is fixed in the latest version.

 This way, you won't have to convert all your audio files.```
spare spruce
#

sorry, this is indeed a result of https://www.remotion.dev/docs/lambda/troubleshooting/chrome-133-situation

we are still working with the vendor to upgrade asap, they are rebuilding the chrome binaries and as soon as it is working, we'll fix remotion https://www.remotion.dev/docs/lambda/troubleshooting/chrome-133-situation

Chrome 133 situation | Remotion | Make videos programmatically

From Remotion version v4.0.274, there has been an inadvertent change that breaks some workflows on Lambda that expect Chrome to have been compiled proprietary video codecs

narrow fable
#

Thanks for sharing the information. This issue appears to be directly related to the Chrome 133 issue that Remotion has logged. The issue started with Remotion version v4.0.274, which is consistent with Remotion's findings (v273 works, but v274 and later don't).
The core issue is that Chrome 133 does not support a proprietary video codec, which affects AAC audio decoding of M4A files. According to the documentation, Remotion is working with the vendor to rebuild the Chrome binary to support the appropriate codec.
So it seems best to stay on Remotion v4.0.273 until Remotion releases a fix. This confirms our earlier conclusion: it was not just a regression issue with Remotion, but an issue with the Chrome binary that they use for rendering.
When Remotion releases an update with the fixed Chrome binary, you will be able to upgrade and maintain your existing M4A workflow without any conversion work.

I wish good luck in business,
Thanks

plush river
#

Yeah I guessed it's probably on the chrome
unrelated but my chrome 135.0.7049.85 x86 on windows had problem with loading some videos in remotion web and I just got and update on my chrome that fixed it
and it was ok on the same version on mac
so maybe chrome is doing some stuff

narrow fable
#

Yea, you're absolutely right — the issue is tied to the Chrome 133 update used in Remotion Lambdas. Starting from v4.0.274, the Chrome binaries no longer support proprietary codecs like AAC (used in .m4a), which is why decoding fails.
Since your workflow depends on .m4a and converting isn't an option, the best move for now is to stay on v4.0.273, where everything works fine. Remotion is already working with the vendor to rebuild Chrome with the proper codec support. Once that’s done and they release a fix, you’ll be able to upgrade without needing to change your media files.

#

I wish good luck in business.

#

Thanks a lot.

plush river
#

is version v4.0.289 the fix?