#7372 closed defect (fixed)
[regression][eac3] Unable to parse channels information while compiling with ac3 decoder disabled.
| Reported by: | Adam Pasyniuk | Owned by: | |
|---|---|---|---|
| Priority: | minor | Component: | avcodec |
| Version: | git-master | Keywords: | eac3 regression |
| Cc: | onemda@gmail.com, puracz@vewd.com | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug:
When ffmpeg is compiled with ac3 decoder disabled ffmpeg is unable to extract channel information from ts file.
It can be a regression after a changes introduced in: ae9297097696f3d06417a6e8a5368d5f38a6edb4
How to reproduce:
Before ae9297097696f3d06417a6e8a5368d5f38a6edb4 commit:
> $ ./ffprobe -i ~/builds/ts_multi_codec.ts [±e5819fa629]
ffprobe version N-90480-ge5819fa629 Copyright (c) 2007-2018 the FFmpeg developers
built with gcc 5.5.0 (Ubuntu 5.5.0-12ubuntu1~16.04) 20171010
configuration: --prefix=/home/apasyniuk/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/apasyniuk/ffmpeg_build/include --extra-ldflags=-L/home/apasyniuk/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/apasyniuk/bin --disable-decoder=ac3
libavutil 56. 12.100 / 56. 12.100
libavcodec 58. 16.100 / 58. 16.100
libavformat 58. 10.100 / 58. 10.100
libavdevice 58. 2.100 / 58. 2.100
libavfilter 7. 13.100 / 7. 13.100
libswscale 5. 0.102 / 5. 0.102
libswresample 3. 0.101 / 3. 0.101
[mpegts @ 0x2722b00] DTS discontinuity in stream 0: packet 3 with DTS 123306, packet 4 with DTS 126906
Input #0, mpegts, from '/home/apasyniuk/builds/ts_multi_codec.ts':
Duration: 00:01:21.02, start: 1.370067, bitrate: 4749 kb/s
Program 2
Stream #0:0[0x21]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x24]: Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), 192 kb/s
Stream #0:2[0x25]: Audio: aac (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp, 128 kb/s
Stream #0:1[0x24]: Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), 192 kb/s
ffprobe is able to extract information about channels 5.1
after ae9297097696f3d06417a6e8a5368d5f38a6edb4 commit:
> $ ./ffprobe -i ~/builds/ts_multi_codec.ts [±ae92970976]
ffprobe version N-90481-gae92970976 Copyright (c) 2007-2018 the FFmpeg developers
built with gcc 5.5.0 (Ubuntu 5.5.0-12ubuntu1~16.04) 20171010
configuration: --prefix=/home/apasyniuk/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/apasyniuk/ffmpeg_build/include --extra-ldflags=-L/home/apasyniuk/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/apasyniuk/bin --disable-decoder=ac3
libavutil 56. 12.100 / 56. 12.100
libavcodec 58. 16.100 / 58. 16.100
libavformat 58. 10.100 / 58. 10.100
libavdevice 58. 2.100 / 58. 2.100
libavfilter 7. 13.100 / 7. 13.100
libswscale 5. 0.102 / 5. 0.102
libswresample 3. 0.101 / 3. 0.101
[mpegts @ 0x3715b00] DTS discontinuity in stream 0: packet 3 with DTS 123306, packet 4 with DTS 126906
[mpegts @ 0x3715b00] Could not find codec parameters for stream 1 (Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, 0 channels): unspecified number of channels
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '/home/apasyniuk/builds/ts_multi_codec.ts':
Duration: 00:01:21.02, start: 1.370067, bitrate: 4749 kb/s
Program 2
Stream #0:0[0x21]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x24]: Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, 0 channels
Stream #0:2[0x25]: Audio: aac (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp, 115 kb/s
Unsupported codec with id 86056 for input stream 1
we get 0 channels and following log
[mpegts @ 0x3715b00] Could not find codec parameters for stream 1 (Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, 0 channels): unspecified number of channels Consider increasing the value for the 'analyzeduration' and 'probesize' options
Link to test file : http://streaming.dolby.com/ftproot/mitXperts/ts/ts_multi_codec.ts
Additionaly after reverting part of the changes everything seems to work correctly in this case:
g show 5e14c2b1a5441 libavcodec/aac_ac3_parser.c | git apply -R
Change History (18)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I try this and yes it works now.
Maybe it's good idea to add this config check to next if with bit_rate parameter?
diff --git a/third_party/ffmpeg/libavcodec/aac_ac3_parser.c b/third_party/ffmpeg/libavcodec/aac_ac3_parser.c
index 54e459844f14..46e73014560e 100644
--- a/third_party/ffmpeg/libavcodec/aac_ac3_parser.c
+++ b/third_party/ffmpeg/libavcodec/aac_ac3_parser.c
@@ -89,7 +89,7 @@ get_next:
the frame). */
if (avctx->codec_id != AV_CODEC_ID_AAC) {
avctx->sample_rate = s->sample_rate;
- if (avctx->codec_id != AV_CODEC_ID_EAC3) {
+ if ((CONFIG_EAC3_DECODER && avctx->codec_id != AV_CODEC_ID_EAC3) || (!CONFIG_EAC3_DECODER)) {
avctx->channels = s->channels;
avctx->channel_layout = s->channel_layout;
}
@@ -97,7 +97,7 @@ get_next:
avctx->audio_service_type = s->service_type;
}
- if (avctx->codec_id != AV_CODEC_ID_EAC3)
+ if ((CONFIG_EAC3_DECODER && avctx->codec_id != AV_CODEC_ID_EAC3) || (!CONFIG_EAC3_DECODER))
avctx->bit_rate = s->bit_rate;
}
comment:3 by , 6 years ago
| Keywords: | eac3 regression added |
|---|---|
| Priority: | normal → important |
comment:4 by , 5 years ago
| Status: | new → open |
|---|
Important? Really? I do not see it. https://github.com/FFmpeg/FFmpeg/blob/a8ec0685ac1cfbeb0e87f47b86d4f0b5cf75d745/libavcodec/aac_ac3_parser.c#L90
follow-up: 10 comment:5 by , 4 years ago
| Cc: | added |
|---|
This bug causes a problem for us at Vewd with every update we make.
Is there anything we could do to support getting this fixed?
comment:7 by , 4 years ago
At this moment I can only offer some developer time and effort, but I'd need some guidance.
Do you think we could make any progress that way?
follow-up: 9 comment:8 by , 4 years ago
This bug is still reproducible today on a16bcc13d9c9db484717c3c19980532fad11c2de
Configuration used to reproduce:
./configure --disable-everything --disable-all --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-static --enable-avcodec --enable-avformat --enable-avutil --enable-fft --enable-rdft --enable-static --disable-debug --disable-bzlib --disable-error-resilience --disable-iconv --disable-lzo --disable-network --disable-schannel --disable-sdl2 --disable-symver --disable-xlib --disable-zlib --disable-securetransport --disable-faan --disable-alsa --disable-autodetect --enable-decoder=vorbis,flac --enable-decoder=pcm_u8,pcm_s16le,pcm_s24le,pcm_s32le,pcm_f32le,mp3 --enable-decoder=pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw --enable-demuxer=ogg,matroska,wav,flac,mp3,mov,av1 --enable-parser=vorbis,flac,mpegaudio,vp9,av1 --disable-linux-perf --x86asmexe=nasm '--optflags="-O2"' --enable-decoder=theora,vp8 --enable-parser=vp3,vp8 --enable-pic '--cc=ccache clang' '--cxx=ccache clang++' --enable-decoder=aac,aac_latm,mp2,mp3,hevc --enable-demuxer=aac,ac3,eac3,loas,mp3,mov,mpegts,mpegtsraw --enable-parser=aac,mpegaudio,aac_latm,ac3,vc1,mpeg4video,mpegvideo,vp8,vp9,h264,hevc --enable-bsf=vp9_superframe,h264_mp4toannexb --enable-error-resilience --enable-ffprobe --enable-protocol=file
Steps to reproduce were the same as in description of this report.
Patch submitted for review.
Ran regression tests of the submitted patch on top of a16bcc13d9c9db484717c3c19980532fad11c2de, build with the following configuration:
./configure --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-debug --disable-linux-perf --x86asmexe=nasm '--optflags="-O2"' --enable-pic '--cc=ccache clang' '--cxx=ccache clang++'
Regression tests passed OK.
comment:9 by , 4 years ago
Replying to puracz:
./configure --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-debug --disable-linux-perf --x86asmexe=nasm '--optflags="-O2"' --enable-pic '--cc=ccache clang' '--cxx=ccache clang++'
Regression tests passed OK.
Unrelated to this ticket:
The options --disable-debug, --disable-linux-perf, --x86asmexe, --enable-pic and especially --optflags should generally not be used, less so for regression test.
follow-up: 11 comment:10 by , 4 years ago
| Priority: | important → minor |
|---|
Replying to puracz:
This bug causes a problem for us at Vewd with every update we make.
Just curious:
Why do you disable the ac3 decoder if you know that you need it to avoid issues?
comment:11 by , 4 years ago
Replying to cehoyos:
We aim to reduce code size in order to get a smaller binary. We had no problems with this configuration before the change that caused this regression.
follow-up: 13 comment:12 by , 4 years ago
Did you compare the size of the binaries with eac3 decoder and both with and without ac3 decoder (which is mostly a subset of eac3)?
I don’t see --enable-small in your configure line...
comment:13 by , 4 years ago
Replying to cehoyos:
Did you compare the size of the binaries with eac3 decoder and both with and without ac3 decoder (which is mostly a subset of eac3)?
Sorry, looking at your configure line again, I am not sure anymore if I understand this ticket at all...
Anyway, if your goal is a small binary: gcc is 5% smaller than clang here, enable-small brings another 5%.
comment:14 by , 4 years ago
As far as I can see in our bug tracker, the config provided here is just for the purpose of reproducing the bug on x86 - it was found in the course of investigation on our side. Originally we noticed the bug on a TV device which I think uses a different configuration (though, I could be wrong here). From a quick look at the records in our bug tracker I've found no traces of such binary size comparison being made.
comment:15 by , 4 years ago
I suppose this answers the issue here https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210128162646.2811269-5-andreas.rheinhardt@gmail.com/
"the options applying to the EAC-3 encoder
are a proper subset of the options for the AC-3 encoders"
Usually we do such things in that case, even if in that particular case it is a bug in gcc. BTW, you need to report that to gcc bugzilla. https://patchwork.ffmpeg.org/project/ffmpeg/patch/572a9e842ce7e0da60fb20cf3cfcf606bb31ec43.1611641682.git.pross@xvid.org/
follow-up: 17 comment:16 by , 4 years ago
The mentioned patch doesn't seem to fix the bug. I've applied it today on top of ad2cc0e2f41f3be59e8c7c1a0ab5c813d7073643 and run the test. The bug was still reproducible with that patch applied.
Currently this patch remains the only one effectively fixing this bug on my end.
comment:17 by , 4 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Replying to puracz:
The mentioned patch doesn't seem to fix the bug.
Nothing indicates that it was meant to fix this issue.
Fixed by Piotr Uracz in 7ceceee8b6ceed2f5a1d53cde1afefad531b5a78
Try this patch:
diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c index 54e459844f..15fc929cb4 100644 --- a/libavcodec/aac_ac3_parser.c +++ b/libavcodec/aac_ac3_parser.c @@ -89,7 +89,7 @@ get_next: the frame). */ if (avctx->codec_id != AV_CODEC_ID_AAC) { avctx->sample_rate = s->sample_rate; - if (avctx->codec_id != AV_CODEC_ID_EAC3) { + if ((CONFIG_EAC3_DECODER && avctx->codec_id != AV_CODEC_ID_EAC3) || (!CONFIG_EAC3_DECODER)) { avctx->channels = s->channels; avctx->channel_layout = s->channel_layout; }