Transcodes using hevc_nvenc not copying audio as expected to the output

[Jordan Fearnley]

Summary of the bug:

Since commit 9a245bdf5d7860b8bc5e5c21a105a075925b719a, transcodes using -c:v hevc_nvenc -c:a copy do not appear to copy over audio in the exact same manner as it did previously. In some limited playback scenarios, the resulting transcoded file's audio track can end up not being played at all.

How the bug was discovered:

Audio playback issues were encountered when playing a file via Jellyfin on an LG TV. I could not reproduce this playback issue on any other client as impacted transcodes playback fine on players tested on my PC, and even playback fine when served via Jellyfin on a android client. The impacted transcodes have all had a source framerate of 23.98fps.

When using ffprobe -show_streams -select_streams a to try diagnose the issue, I observed that when the audio was 'copied' over during the transcode, any impacted files would have the profile set to unknown, rather than the expected (in this situation) value of LC.

Additionally, the ffprobe output also indicated that the values for duration_ts & duration went from N/A in non-impacted files, to the actual expected values in impacted files.

Available logfile output:

​https://gist.github.com/fearnlj01/e1a72c2b3aaa9666922bd4106efcb3d8

This gist contains 4x files, as listed below. These files have also been attached to this ticket.

nvenc-audioprofile-unknown-probe.log | Impacted transcode, ffprobe audio stream output
nvenc-audioprofile-unknown-ffmpeg.log | Impacted transcode, ffmpeg output

nvenc-audioprofile-aac_lc-ffmepg.log | Non-impacted transcode, ffprobe audio stream output
nvenc-audioprofile-aac_lc-probe.log | Non-impacted transcode, ffmpeg output

I also have the 30s source file used for the above transcodes which I will try to attach to the ticket with filename of nvenc-audioprofile-source.mkv.

Steps for reproduction of the issue:

Note that the issue seems to only appear when using NVENC, so an appropriately capable gpu would be required to reproduce. This should, at the least, be specifically reproducible when using an Nvidia GeForce RTX 3060 Ti.

• Using a build of ffmpeg from before commit 9a245bdf5d7860b8bc5e5c21a105a075925b719a:

ffmpeg -i nvenc-audioprofile-source.mkv -c:v hevc_nvenc -c:a copy -y -f matroska output.mkv"

• Using ffprobe -show_streams -select_streams a output.mkv, verify that the output file has the expected encoding profile set for the audio stream

• Using a build of ffmpeg which includes the aforementioned commit:

ffmpeg -i nvenc-audioprofile-source.mkv -c:v hevc_nvenc -c:a copy -y -f matroska output.mkv"

• Using ffprobe -show_streams -select_streams a output.mkv, verify that the output file does not have the expected encoding profile set for the audio stream

I am unsure as to what steps can be taken to reproduce the core issue of the audio track not being used for playback, however I suspect that this would be out of scope for FFMPEG even if easily reproducible. I would however expect that ffprobe should be able to show the audio encoding profile not as unknown, especially when copying from an AAC source with profile LC.

[Jordan Fearnley]

Non-impacted transcode - FFMPEG output

[Jordan Fearnley]

Non-impacted transcode - ffprobe output

[Jordan Fearnley]

Impacted transcode - FFMPEG output

[Jordan Fearnley]

Impacted transcode - ffprobe output

[Jordan Fearnley]

The sample source media that was used for testing conducted thus far has been uploaded to streams.videolan.org/upload/ (as per the guidance in https://ffmpeg.org/bugreports.html). This should have a filename of nvenc-audioprofile-source.mkv, and should also (hopefully) be linked to this ticket.

[hydra3333]

is it only hevc, or is h264 affected as well ?

[Jordan Fearnley]

I've just done another test run now with -c:v h264_nvenc to confirm, albeit using a different input source. I get the same issue as initially reported when doing it this way as well so it appears this isn't just limited to hevc.

I also sent off the binaries of ffmpeg I've been using to test this over to an associate who has a 40 series GPU, and it looks like this issue does not occur when using -c:v av1_nvenc. The same issue could still be reproduced when using -c:v hevc_nvenc on this other device, so it looks like it's just h264 & hevc that are impacted.

For the sake of completeness, I've done a quick test using -c:v libx265 to ensure that this issue doesn't occur - outcome is as expected and there are no problems occuring in this scenario.

[Balling]

Should be fixed, because revert occured: ac7c265b33b52f914ebe05e581bbe9343eca1186

[Jordan Fearnley]

Tried it out and everything appears to be normal once again on my end 🥳