PCM audio not being transcoded in mp4_segment_recorder

[irichter]

When attempting to record rtsp streams with PCM audio, record_segment() (in /src/video/mp4_segment_recorder.c) unconditionally copies the audio stream parameters without checking is_audio_codec_compatible_with_mp4().

Log excerpt:

[2026-03-06 22:02:28] [INFO] Including audio stream in MP4 recording
[mp4 @ 0x7c270815acc0] Could not find tag for codec pcm_alaw in stream #1, codec not currently supported in container
[2026-03-06 22:02:28] [ERROR] Failed to write header: -22 (Invalid argument)
[2026-03-06 22:02:28] [ERROR] Header write failed with EINVAL, likely due to invalid video parameters
[2026-03-06 22:02:28] [ERROR] Video stream parameters: width=1920, height=1080, codec_id=27
[2026-03-06 22:02:28] [ERROR] Audio stream parameters: codec_id=65543, sample_rate=8000, channels=1
[2026-03-06 22:02:28] [ERROR] PCM A-law (G.711 A-law) audio codec is not compatible with MP4 format
[2026-03-06 22:02:28] [ERROR] Audio transcoding to AAC should be enabled automatically
[2026-03-06 22:02:28] [ERROR] If the issue persists, try disabling audio recording for this stream

[matteius]

Fix pushed to main in commit 9a610fd.

record_segment() was unconditionally copying audio stream parameters without checking is_audio_codec_compatible_with_mp4(), so PCM codecs (pcm_alaw, pcm_mulaw, etc.) were being passed straight through to the MP4 muxer, which rejects them.

The fix adds the same codec compatibility check and PCM-to-AAC transcoding that the mp4_writer path already had:

1. Before creating the output audio stream, checks codec compatibility. If the codec is an incompatible PCM variant, sets up PCM→AAC transcoding via transcode_mulaw_to_aac(). If transcoding setup fails, audio is disabled gracefully instead of crashing the header write.
2. During packet writing, PCM audio packets are transcoded to AAC via transcode_audio_packet() before being written.
3. Audio transcoder resources are cleaned up on segment cleanup.

Also consolidated duplicate is_pcm_codec() / extern declarations across mp4_writer.c and mp4_writer_core.c into proper declarations in mp4_writer_internal.h.

@irichter — please test with your PCM A-law stream and confirm the fix resolves the issue.

[irichter]

@matteius, I'm not sure what's going on, but the transcode isn't working correctly. The last two lines of the log (mentioning NaN and invalid argument) repeat until I kill the process.

[2026-03-06 23:32:21] [INFO] Attempting to transcode PCM A-law (G.711 A-law) audio to AAC for MP4 compatibility
[aac @ 0x7af11c032900] Too many bits 16384.000000 > 6144 per frame requested, clamping to max
[2026-03-06 23:32:21] [INFO] Successfully configured transcoding from μ-law to AAC for rtsp://REDACTED/stream1
[2026-03-06 23:32:21] [INFO] Sample rate: 8000, Channels: 1, Bit rate: 48000
[aac @ 0x7af11c032900] Qavg: nan
[2026-03-06 23:32:21] [INFO] Successfully set up PCM-to-AAC transcoding for MP4 recording
[2026-03-06 23:32:21] [INFO] Recording started...
[2026-03-06 23:32:21] [INFO] Found first key frame, starting recording
[2026-03-06 23:32:21] [INFO] Added recording at segment start (ID: 7, trigger_type: scheduled) for file: /REDACTED/recording_20260306_233219.mp4
[aac @ 0x7af11c003b80] Too many bits 16384.000000 > 6144 per frame requested, clamping to max
[2026-03-06 23:32:21] [INFO] Successfully initialized audio transcoder from μ-law to AAC for rtsp://REDACTED/stream1
[2026-03-06 23:32:21] [INFO] Sample rate: 8000, Channels: 1, Bit rate: 48000
[aac @ 0x7af11c003b80] Input contains (near) NaN/+-Inf
[2026-03-06 23:32:21] [ERROR] Failed to send frame to encoder: Invalid argument

[matteius]

Did you test the commitI just pushed or no? what is the version string from the systems page with the git hash?

[irichter]

Hash is 0.29.1-95f527e8 (per the system page).

EDIT: The build is from 9a610f, and I checked that make has nothing to do.

Additional edit: Apparently, version.h wasn't getting regenerated. Per documentation for cmake's configure_file(), it won't get regenerated unless the input changes, so it's not reliable when revisions change unless there's a new checkout.

For reference, when viewing the stream in VLC, the audio is decoded as 16 bits per sample (I assume this is when the 8-bit alaw is mapped to a linear value). Where the aac encoder getting the "6144" bit frame length? Is it assuming that the audio is already compressed?