Low-level error in DCA XLL decode becomes ignored in dcadec.c then SWResample crashes NPX

[Heinrich Tegethoff]

Summary of the bug:

• Input: (dca) DTS 48000 Hz, 8 ch 7.1 (s32p)

• Call: API avcodec_receive_frame(), after avcodec_send_packet()

-> libavcodec/dca_xll.c/parse_band_data() produces and logs error "Invalid NAVI position\n"
OK.

-> parse_band_data returns AVERROR_INVALIDDATA
OK.

• Up-stack: Caller libavcodec/dcadec.c/dcadec_decode_frame().ff_dca_xll_parse() handles AVERROR(EAGAIN), AVERROR(ENOMEM) and AV_EF_EXPLODE but ignores AVERROR_INVALIDDATA

• Crash: 2 out of 8 planes (the XLL channels) of the "successfully" decoded frame are unassigned => the next unit in flow, the SWResampler, crashes with NPX.

ffmpeg version 4.0

built with gcc 7.3.0 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
libswscale 5. 1.100 / 5. 1.100
libswresample 3. 1.100 / 3. 1.100

How to reproduce:

• own Java/JNI i/f to libavcodec et al with elementary DTS MA stream of copyrighted material

• [SWR] FC: FL:0.160189 FR:0.160189 FC:0.226541 LFE:0.000000 BL:0.113270 BR:0.113270 SL:0.113270 SR:0.113270

• BUG HUNTING OUTPUT:

  send 6760 B                   <<< pre avcodec_receive_frame 
  swr  1 1 1 1 1 1 1 1 ok       <<< SWR input planes ok/NULL
  send 4116 B                   
  #>> E  Invalid NAVI position  <<< av_log (from BUG HUNTING)
  swr  1 1 1 1 1 1 -99 -99 #    <<< ok ok ok ok ok ok NULL NULL
  # A fatal error has been detected by the Java Runtime Environment:
  #
  #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fffb3ec0feb, pid=13912, tid=0x0000000000003e94
  #
  # JRE version: Java(TM) SE Runtime Environment (8.0_162-b12) (build 1.8.0_162-b12)
  # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.162-b12 mixed mode windows-amd64 compressed oops)
  
  # Problematic frame:
  # C  [swresample-3.dll+0x10feb]
  

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Carl Eugen Hoyos]

Please provide the input sample and explain how we can reproduce the issue.

[Heinrich Tegethoff]

DTS HD MA - final 4116 bytes packet fails DCA XLL

[Heinrich Tegethoff]

Reproduce:

• Using doc/examples/decode_audio.c as starting point
  • Read attached erroneous sample (DUMP.dts)
  • av_parser_parse2 --> encoded packets with 1 DTS HD frame each
  • avcodec_send_packet --> plain send + receive mechanism
  • avcodec_receive_frame
• Using doc/examples/resampling_audio.c for SWResampler code, which fails, but due to an unhandled error code in dcadec.c
  • av_samples_alloc (ONCE!)
  • swr_convert
• The last packet in the attached sample audio (4116 bytes) raises dcaxll error by log message, returns error code, dcadec does not handle it, channel planes 7+8 are still NULL => SWR crashes accessing the planes.

[Hendrik]

A brief look at the code suggests that the decoder properly falls back to 5.1 core decoding if the XLL layer fails to decode.

Maybe your code does not handle on-the-fly channel configuration changes? Please do verify that frame->channels or avctx->channels actually mis-matches the number of allocated channel buffer. Only then would it actually be an error.

[Heinrich Tegethoff]

Yeah, my AVEncoder wrapper handles channel changes properly (TV recordings change often on movie/commercials), but my SWResampler feeder handles initial "changes" only.

frame->channels changes from 8 to 6 => I will handle it.

Suggestion: Please close ticket.

Thank you!

[Heinrich Tegethoff]

Fine!

On the other hand ...
From a higher viewpoint the Java part handles the on-the-fly channel configuration changes well, with the assumption that a packet identified by metadata as 7.1 (et al) decodes to 8 channels, which isn't true: a channel config change for a single frame with opposite metadata is misleading; and a frame drop, replacing it with silence, is clean (the Java corrects drop errors). This would require the expected error return code.

PS: The application on top is a tool similar to Cuttermaran, based on an entirely refactored ProjectX, and handles the entire flow from media input to intro-PDF with cast&crew and cover etc.
Cuttermaran handles SD (DVD/TV) very well, while Java + FFmpeg offers HD level (BD/HDTV). Audio transcoding is required for the cutter's "preview", video transcoding for the video fragments joiner. Designed for GIANT video material backbone :-)

[Hendrik]

If you don't want fallback to core decoding with DTS, you can set the explode error flag, and it'll instead return you the INVALID_DATA error.