5.1 encoding with iamf-tools results in four streams

[Kurville]

Since 5.1 encoding with FFmpeg 8 is problematic (see #41), I encoded with iamf-tools and MP4Box, with the textproto for 5.1 Opus.

The result of this is an .iamf file with four audio streams. Once combined with the video, it keeps the four audio streams and once uploaded on YouTube, only the first audio stream is played back, the Left/Right couple.

Looking at the textproto, I see this and I think that maybe explains it?

audio_element_metadata { audio_element_id: 300 audio_element_type: AUDIO_ELEMENT_CHANNEL_BASED reserved: 0 codec_config_id: 200 audio_substream_ids: [0, 1, 2, 3] scalable_channel_layout_config { reserved: 0 channel_audio_layer_configs: [ { loudspeaker_layout: LOUDSPEAKER_LAYOUT_5_1_CH output_gain_is_present_flag: 0 recon_gain_is_present_flag: 0 reserved_a: 0 substream_count: 4 coupled_substream_count: 2

[Kurville]

After trying FFmpeg (incomplete processing on YT), iamf-tools ("incompatible" iamf file), and Eclipsa Audio VST plug-ins in Reaper (crash while rendering), it's finally Pro Tools Ultimate with the Eclipsa Audio AAX plug-ins that allowed me to create a 5.1 IAMF video.

It's only for 5.1 that I had this many problems. I recently did other IAMF videos with 3rd order Ambisonics, 5.1.4, and 7.1.4: it all went well with FFmpeg.

[jwcullen]

Not sure where the bug is yet, but here's some info and thoughts.

So IAMF represents audio using substreams. These are the elementary components. Substream are either uncoupled or coupled according to rules.

The correct representation is that 5.1 is composed of four substreams:

• Substream 1: L/R
• Substream 2: Ls/Rs
• Substream 3: C
• Substream 4 LFE

So I think the textproto is OK. You can compare vs. 5.1.4 and 7.1.4 have similar concepts of these.

I notice that in the first message, the tool reports these streams individually. The second screenshot understands it is treated as one IAMF stream.

This makes me think the problem is either in creating the IAMF file, or muxing it with video via GPAC. All before uploading to YouTube.

In my experience, ffmpeg will sometimes copy elementary streams. Especially with commands like -c:a copy. What command are you using with GPAC. The example command works best when input_video is strictly a video file without audio.

[Kurville]

The four streams version was with done with this textproto https://github.com/AOMediaCodec/iamf-tools/blob/main/iamf/cli/textproto_templates/5dot1_opus.textproto

Before muxing, I always strip the video files of audio and timecode streams.

The only way I was able to create a working file was with the Eclipsa plug-ins hosted in Pro Tools.

Can you replicate the problem with GPAC and the 5.1 Opus textproto?

I do notice though that iamf-tools used "GPAC2.4-revrelease" and the Eclipsa plug-ins used "GPAC2.5-DEV-rev1502-g945c0e4b1-master": maybe that's a factor?

[jwcullen]

Where do you see "GPAC2.4-revrelease"? iamf-tools doesn't bundle GPAC in anyway. It just has some docs to help show how to use IAMF with it. Also, some team members have contributed directly to GPAC.

The latest GPAC release is 2.4 from April 2024. This is actually too old. IAMF in GPAC was introduced in February 2025, with bug-fixes May 2025. If your local build is 2.4, you definitely should upgrade if you want to try it with IAMF.

I think if you do this, it is worth trying to create the file, upload it to YouTube again, and share a MediaInfo screenshot if it does not work as expected.

Can you replicate the problem with GPAC and the 5.1 Opus textproto?

I haven't tried to reproduce this yet, but I can try.

[Kurville]

See the image in my initial post ^^^