#5676 closed defect (fixed)
3.1 is broken with (at least) mp3 audio
| Reported by: | marillat | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | avutil |
| Version: | git-master | Keywords: | regression |
| Cc: | fritsch@kodi.tv, Michael Niedermayer | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Here is some examples with kodi or mpv. I can find more if you want.
with mpv playing an mp3 file
[ffmpeg/audio] mp3: Header missing Error decoding audio.
or with an avi file with mp3 audio :
[lavf] Too many packets in the demuxer packet queues: [lavf] video/0: 15583 packets, 117798898 bytes [lavf] audio/1: 417 packets, 160128 bytes
or with kodi :
UsiUsing host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/i386-linux-gnu/kodi/kodi.bin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0850f1bb in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) () [Current thread is 1 (Thread 0xacd059c0 (LWP 18147))]Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/i386-linux-gnu/kodi/kodi.bin'. Program terminated with signal SIGSEGV, Segmentation fault.
Change History (48)
comment:1 by , 8 years ago
| Priority: | critical → normal |
|---|
comment:3 by , 8 years ago
| Keywords: | regression added |
|---|---|
| Priority: | normal → important |
comment:4 by , 8 years ago
| Cc: | added |
|---|
comment:5 by , 8 years ago
As the one that currently bumps ffmpeg 3.1 within kodi I try to reproduce your mp3 issue. I think you need to upload a sample for investigation as my mp3 files are fine.
The error should also be reproducable with ffplay if this is a general ffmpeg 3.1 issue.
comment:6 by , 8 years ago
No this is not a general ffmpeg 3.1 issue but a library problem. libavformat I think, if I read correctly the mpv output.
[lavf] Too many packets in the demuxer packet queues: [lavf] video/0: 15583 packets, 117798898 bytes [lavf] audio/1: 417 packets, 160128 bytes
Packages come from https://www.deb-multimedia.org Debian repository i386 architecture.
Packages was built against 3.0.2 and when 3.1 packages have been installed mpv is unable to play an mp3 or a video file
mpv is unable to play == all == my mp3 files.
I've also received two bug reports from users (one for mpv and one for kodi).
Also I'm unable to play any video stream with chromium
I've not tested with others program, but I'm sure I can find other broken program.
comment:7 by , 8 years ago
Yeah and I sadly will close your kodi report - because kodi works fine for me and my dev colleagues currently testing 3.1, so we cannot reproduce, which seems to point to something else the way deb-multimedia builds its packages.
So for now your problem is a debian-multimedia repository issue, right?
comment:8 by , 8 years ago
Not a debian-multimedia repository issue but a ffmpeg issue.
I package ffmpeg since more than 10 years, and I see quicly where a problem come from like this one
I quote Michael Niedermayer from a bug report I did 3 years ago.
Its quite unfortunate that this issue hasnt been raised louder earlier.
comment:9 by , 8 years ago
Yeah - I appreciate your work, but I really wonder - why for us (kodi upstream devs) mp3 playback works just fine. When building against ffmpeg 3.1 - that's all I wonder.
So mind trying to build ffmpeg like this:
./configure --prefix=/opt/ffmpeg --extra-version='VERSION=3.1.0-Krypton-alpha' --disable-devices --enable-ffplay --disable-ffmpeg --disable-ffserver --disable-doc --enable-gpl --enable-runtime-cpudetect --enable-postproc --enable-vaapi --enable-vdpau --enable-bzlib --enable-gnutls --enable-muxer=spdif --enable-muxer=adts --enable-muxer=asf --enable-muxer=ipod --enable-encoder=ac3 --enable-encoder=aac --enable-encoder=wmav2 --enable-protocol=http --enable-libvorbis --enable-muxer=ogg --enable-encoder=libvorbis --enable-nonfree --enable-pthreads --enable-zlib --enable-encoder=png --enable-encoder=mjpeg --disable-mipsdsp --disable-mipsdspr2 --enable-nonfree
and kodi like that:
./bootstrap ; ./configure --with-ffmpeg=/opt/ffmpeg
Then you exactly use it as we use it, which works fine for us.
comment:10 by , 8 years ago
As english isn't my native language I try again :
kodi is not build against ffmpeg 3.1 but against ffmpeg 3.0.2 with shared libraries.
In the repository all packages are build against ffmpeg 3.0.2 and if I install ffmpeg 3.1 libraries all packages linked against 3.0.2 are broken (like mpv).
Now if I rebuild these packages (including kodi) against ffmpeg 3.1 then this bug is gone.
Do you see the problem ?
comment:11 by , 8 years ago
That is some information I could not spot throughout this entire bugreport. There were some major / minor version bumps in ffmpeg 3.1. As we build statically build against ffmpeg by default this is something we don't test at all.
In short: .so version bumped - not sure how you expect that to work.
comment:12 by , 8 years ago
Sorry I was wrong, according to: http://ffmpeg.org/download.html there is no major versions mismatch between 3.0.x and 3.1.x
So your issue is an (undocumented) ABI breakage then, which will affect a lot others applications, too.
comment:13 by , 8 years ago
| Component: | avformat → undetermined |
|---|---|
| Reproduced by developer: | set |
Reproducible with ffplay (but not ffmpeg), regression since 10424024a16a7646169b9c9008c5f7b77cbc2211
Please verify with kodi and/or mpv!
ffplay -i fate-suite/mp3-conformance/compl.bit
ffplay version N-78463-gfbc96c5 Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 4.7 (SUSE Linux)
configuration: --enable-shared
libavutil 55. 17.103 / 55. 27.100
libavcodec 57. 24.102 / 57. 48.101
libavformat 57. 25.100 / 57. 40.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 46.102
libswscale 4. 0.100 / 4. 1.100
libswresample 2. 0.101 / 2. 1.100
[mp3 @ 0x7fd1dc000920] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '/home/cehoyos/test/cehoyos/FFmpeg/fate-suite/mp3-conformance/compl.bit':
Duration: 00:00:05.19, start: 0.000000, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 48000 Hz, mono, s16p, 64 kb/s
Invalid sample rate or channel count!
Failed to open file 'fate-suite/mp3-conformance/compl.bit' or configure filtergraph
comment:14 by , 8 years ago
Sorry - I cannot reproduce. We (kodi) do not support dynamic linking out of exactly such reasons. I tried to build against shared libs, which worked okay, but starting ends in a smashed stack.
I will concentrate on the other bugreport that really affects the way we ship our application.
follow-up: 16 comment:15 by , 8 years ago
Here is the output from ffplay 3.0.2 and 3.1 libraries :
$ ffplay -debug 56 -fdebug ts foo.mp3
ffplay version 3.0.2 Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 5.3.1 (Debian 5.3.1-17) 20160429
configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libtesseract --libdir=/usr/lib/i386-linux-gnu --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libpulse --disable-mipsdsp --disable-mips32r2 --disable-msa --disable-mipsfpu --disable-mipsdspr2 --enable-libvidstab --enable-libzvbi --enable-avresample --enable-libutvideo --enable-libfdk-aac --enable-libx265 --enable-libbs2b --enable-libilbc --enable-libopenh264 --enable-libkvazaar --enable-libsnappy --enable-libsoxr --enable-libiec61883 --enable-vaapi --enable-opencl --cpu=i686 --enable-libdc1394 --disable-altivec --shlibdir=/usr/lib/i386-linux-gnu
libavutil 55. 17.103 / 55. 27.100
libavcodec 57. 24.102 / 57. 48.101
libavformat 57. 25.100 / 57. 40.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 46.102
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 1.100
libswresample 2. 0.101 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[file @ 0xaf000ba0] Setting default whitelist 'file,crypto' f=0/0
[mp3 @ 0xaf0004a0] Format mp3 probed with size=2048 and score=51
[mp3 @ 0xaf0004a0] pad 576 1800
[mp3 @ 0xaf0004a0] Skipping 0 bytes of junk at 417.
[mp3 @ 0xaf0004a0] Before avformat_find_stream_info() pos: 417 bytes read:65664 seeks:2 nb_streams:1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] demuxer injecting skip 1105 / discard 0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561878065151, dts=9223090561878065151, size=179, duration=368640, flags=1
[mp3 @ 0xaf001500] skip 1105 / discard 0 samples due to side data
[mp3 @ 0xaf001500] skip 1105/1152 samples
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561878433791, dts=9223090561878433791, size=156, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561878802431, dts=9223090561878802431, size=156, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561879171071, dts=9223090561879171071, size=156, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561879539711, dts=9223090561879539711, size=130, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561879908351, dts=9223090561879908351, size=130, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561880276991, dts=9223090561880276991, size=156, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561880645631, dts=9223090561880645631, size=104, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561881014271, dts=9223090561881014271, size=130, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561881382911, dts=9223090561881382911, size=130, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561881751551, dts=9223090561881751551, size=130, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561882120191, dts=9223090561882120191, size=104, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561882488831, dts=9223090561882488831, size=104, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561882857471, dts=9223090561882857471, size=104, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561883226111, dts=9223090561883226111, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561883594751, dts=9223090561883594751, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561883963391, dts=9223090561883963391, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561884332031, dts=9223090561884332031, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561884700671, dts=9223090561884700671, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561885069311, dts=9223090561885069311, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561885437951, dts=9223090561885437951, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561885806591, dts=9223090561885806591, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561886175231, dts=9223090561886175231, size=1044, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561886543871, dts=9223090561886543871, size=835, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561886912511, dts=9223090561886912511, size=835, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561887281151, dts=9223090561887281151, size=835, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561887649791, dts=9223090561887649791, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561888018431, dts=9223090561888018431, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561888387071, dts=9223090561888387071, size=522, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561888755711, dts=9223090561888755711, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561889124351, dts=9223090561889124351, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561889492991, dts=9223090561889492991, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561889861631, dts=9223090561889861631, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561890230271, dts=9223090561890230271, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561890598911, dts=9223090561890598911, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561890967551, dts=9223090561890967551, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561891336191, dts=9223090561891336191, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561891704831, dts=9223090561891704831, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561892073471, dts=9223090561892073471, size=835, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561892442111, dts=9223090561892442111, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561892810751, dts=9223090561892810751, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561893179391, dts=9223090561893179391, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561893548031, dts=9223090561893548031, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561893916671, dts=9223090561893916671, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561894285311, dts=9223090561894285311, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561894653951, dts=9223090561894653951, size=626, duration=368640, flags=1
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561895022591, dts=9223090561895022591, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561895391231, dts=9223090561895391231, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561895759871, dts=9223090561895759871, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] ff_read_packet stream=0, pts=NOPTS, dts=NOPTS, size=1024, duration=0, flags=0
[mp3 @ 0xaf0004a0] read_frame_internal stream=0, pts=9223090561896128511, dts=9223090561896128511, size=731, duration=368640, flags=1
[mp3 @ 0xaf0004a0] All info found
[mp3 @ 0xaf0004a0] After avformat_find_stream_info() pos: 31137 bytes read:65664 seeks:2 frames:50
Input #0, mp3, from 'foo.mp3':
Duration: 00:03:36.29, start: 0.025057, bitrate: 248 kb/s
Stream #0:0, 50, 1/14112000: Audio: mp3, 44100 Hz, stereo, s16p, 248 kb/s
Metadata:
encoder : LAME3.98r
detected 8 logical cores
[ffplay_abuffer @ 0xaf003780] Setting 'sample_rate' to value '44100'
[ffplay_abuffer @ 0xaf003780] Setting 'sample_fmt' to value 's16p'
[ffplay_abuffer @ 0xaf003780] Setting 'channels' to value '2'
[ffplay_abuffer @ 0xaf003780] Setting 'time_base' to value '1/44100'
[ffplay_abuffer @ 0xaf003780] Setting 'channel_layout' to value '0x3'
[ffplay_abuffer @ 0xaf003780] tb:1/44100 samplefmt:s16p samplerate:44100 chlayout:0x3
[ffplay_abuffersink @ 0xaf003fa0] auto-inserting filter 'auto-inserted resampler 0' between the filter 'ffplay_abuffer' and the filter 'ffplay_abuffersink'
[AVFilterGraph @ 0xaf01e6c0] query_formats: 2 queried, 0 merged, 3 already done, 0 delayed
[auto-inserted resampler 0 @ 0xaf011460] [SWR @ 0xaf026c80] Using s16p internally between filters
[auto-inserted resampler 0 @ 0xaf011460] ch:2 chl:stereo fmt:s16p r:44100Hz -> ch:2 chl:stereo fmt:s16 r:44100Hz
Invalid sample rate or channel count!
Failed to open file 'foo.mp3' or configure filtergraph
follow-up: 18 comment:16 by , 8 years ago
Replying to marillat:
Here is the output from ffplay 3.0.2 and 3.1 libraries :
I already provided this output.
Can you confirm that the issue you see with mpv is a regression since 10424024a16a7646169b9c9008c5f7b77cbc2211 ?
comment:17 by , 8 years ago
ffplay accesses AVFilterLink->channels, which is NOT part of the public API/ABI, and as such its no wonder it breaks when mixing up library versions. This is a bug in ffplay, not in avfilter.
Admittedly the public/private API/ABI separation within the same struct is not the best design, but its one we consistently use throughout various context structs, so it should not come as a surprise.
comment:18 by , 8 years ago
Replying to cehoyos:
Replying to marillat:
Here is the output from ffplay 3.0.2 and 3.1 libraries :
I already provided this output.
Can you confirm that the issue you see with mpv is a regression since 10424024a16a7646169b9c9008c5f7b77cbc2211 ?
The bug is still here.
follow-ups: 21 31 comment:20 by , 8 years ago
Replying to fritsch:
So choose the commit before that hash.
I'm now at 6992276acaaee32b33bd5f6e2f0d89588c4ae59a
The bug is gone from ffplay but still in mpv
follow-up: 22 comment:21 by , 8 years ago
| Reproduced by developer: | unset |
|---|
Replying to marillat:
Replying to fritsch:
So choose the commit before that hash.
I'm now at 6992276acaaee32b33bd5f6e2f0d89588c4ae59a
The bug is gone from ffplay but still in mpv
That means you have reported a different issue than the one I found for FFplay which is now ticket #5679.
I don't think the issue you see can be fixed without a bisect.
comment:22 by , 8 years ago
Replying to cehoyos:
Replying to marillat:
I'm now at 6992276acaaee32b33bd5f6e2f0d89588c4ae59a
The bug is gone from ffplay but still in mpv
That means you have reported a different issue than the one I found for FFplay which is now ticket #5679.
I don't think the issue you see can be fixed without a bisect.
Then bump the soname of libavformat. For now shared libraries are broken.
comment:23 by , 8 years ago
I believe all developers would prefer to fix the issue. This will only be possible once the commit that introduced the issue is known.
comment:24 by , 8 years ago
Latest ffmpeg master and HEAD of release/3.1 should not cause this issue anymore.
comment:27 by , 8 years ago
Replying to cehoyos:
Which commit should have fixed this?
I guess the hope was 0a6d7602308e0f3060d9a6e6b44ae7bf5bbd7841 or 1fdf549462449c98acdedd37ac1582bba218b425 would have fixed this.
comment:28 by , 8 years ago
I cannot reproduce this with release/3.1 + release/3.0
ffplay version n3.0.2-52-g2d9a6ae Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.0
WARNING: library configuration mismatch
avutil configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
avcodec configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
avformat configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
avdevice configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
avfilter configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
swscale configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
swresample configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
postproc configuration: --enable-gpl --cc='ccache gcc' --enable-shared --disable-stripping --enable-pthreads --enable-debug=3 --cpu=core2 --samples=fate-suite/ --enable-libfreetype --enable-nonfree --enable-version3 --assert-level=2 --enable-iconv --enable-libass --prefix=release/3.1
libavutil 55. 17.103 / 55. 27.100
libavcodec 57. 24.102 / 57. 48.101
libavformat 57. 25.100 / 57. 40.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 47.100
libswscale 4. 0.100 / 4. 1.100
libswresample 2. 0.101 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[mp3 @ 0x7fef780008c0] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'fate-suite/mp3-conformance/compl.bit':
Duration: 00:00:05.19, start: 0.000000, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 48000 Hz, mono, s16p, 64 kb/s
2.92 M-A: 0.000 fd= 0 aq= 7KB vq= 0KB sq= 0B f=0/0
follow-up: 34 comment:29 by , 8 years ago
Can someone confirm that this issue still exists with
"libavfilter 6. 31.100 / 6. 47.100"
the quoted test a few hours ago used a older libavfilter
follow-up: 32 comment:30 by , 8 years ago
https://github.com/mpv-player/mpv/issues/3295
Maybe this is at fault, at least for mpv.
comment:31 by , 8 years ago
Replying to marillat:
Replying to fritsch:
So choose the commit before that hash.
I'm now at 6992276acaaee32b33bd5f6e2f0d89588c4ae59a
The bug is gone from ffplay but still in mpv
Could you check with commits 26abd5149ebf9602d8036be4c6e72e08c98ea998 and 1a708780f3d4b431996d118df4e448b4f2a7942e?
If the former works but the latter fails, then it's an mpv bug (directly accessing fields marked as having no direct access).
comment:32 by , 8 years ago
Replying to jamrial:
https://github.com/mpv-player/mpv/issues/3295
Maybe this is at fault, at least for mpv.
Well, that ticked was closed and they apparently don't plan to fix it. So assuming i'm right with the stuff from comment 31 then this is not an ffmpeg bug, but API misuse by library users.
comment:33 by , 8 years ago
If you from a quick grep find similar issues in kodi code - I am happy to fix them, already found two positions: http://sprunge.us/hAhC
follow-up: 35 comment:34 by , 8 years ago
Replying to michael:
Can someone confirm that this issue still exists with
"libavfilter 6. 31.100 / 6. 47.100"
the quoted test a few hours ago used a older libavfilter
Still the same with mpv, ffplay, kodi and chromium
ffplay version 3.1 Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 5.4.0 (Debian 5.4.0-4) 20160609
configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libtesseract --libdir=/usr/lib/i386-linux-gnu --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libpulse --disable-mipsdsp --disable-mips32r2 --disable-mips32r6 --disable-msa --disable-mipsfpu --disable-mipsdspr2 --enable-libvidstab --enable-libzvbi --enable-avresample --enable-libfdk-aac --enable-libx265 --enable-libbs2b --enable-libilbc --enable-libopenh264 --enable-libkvazaar --enable-libsnappy --enable-libsoxr --disable-podpages --enable-libiec61883 --enable-vaapi --enable-opencl --cpu=i686 --enable-libdc1394 --disable-altivec --shlibdir=/usr/lib/i386-linux-gnu
libavutil 55. 27.100 / 55. 27.100
libavcodec 57. 48.101 / 57. 48.101
libavformat 57. 40.101 / 57. 40.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 46.102 / 6. 47.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
Input #0, mp3, from 'foo.mp3':= 0KB vq= 0KB sq= 0B f=0/0
Duration: 00:03:36.29, start: 0.025057, bitrate: 248 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 248 kb/s
Metadata:
encoder : LAME3.98r
Invalid sample rate or channel count!
Failed to open file 'foo.mp3' or configure filtergraph
follow-up: 36 comment:35 by , 8 years ago
Replying to marillat:
Replying to michael:
Can someone confirm that this issue still exists with
"libavfilter 6. 31.100 / 6. 47.100"
the quoted test a few hours ago used a older libavfilter
Still the same with mpv, ffplay, kodi and chromium
ffplay version 3.1 Copyright (c) 2003-2016 the FFmpeg developers libavfilter 6. 46.102 / 6. 47.100
That's not "libavfilter 6. 31.100 / 6. 47.100" (ffmpeg 3.0 cli from your distro using release/3.1 libraries at runtime).
Could you see the analysis above? comments 30, 31, 32 and 33.
comment 31 mentions the commit that most assuredly introduced this issue, meaning this is a bug in mpv/kodi/chromium regarding their usage of fields marked as not public and not an ffmpeg problem, but i need confirmation.
comment:36 by , 8 years ago
Replying to jamrial:
Replying to marillat:
Replying to michael:
Can someone confirm that this issue still exists with
"libavfilter 6. 31.100 / 6. 47.100"
the quoted test a few hours ago used a older libavfilter
Still the same with mpv, ffplay, kodi and chromium
ffplay version 3.1 Copyright (c) 2003-2016 the FFmpeg developers libavfilter 6. 46.102 / 6. 47.100That's not "libavfilter 6. 31.100 / 6. 47.100" (ffmpeg 3.0 cli from your distro using release/3.1 libraries at runtime).
Syill the same with ffplay 6. 31.100 / 6. 47.100
Could you see the analysis above? comments 30, 31, 32 and 33.
comment 31 mentions the commit that most assuredly introduced this issue, meaning this is a bug in mpv/kodi/chromium regarding their usage of fields marked as not public and not an ffmpeg problem, but i need confirmation.
This bug is gone with 26abd5149ebf9602d8036be4c6e72e08c98ea998 checkout for mpv, kodi and chromium but ffplay still fail. here is libraries version with this commit.
libavutil 55. 17.103 / 55. 18.100 libavcodec 57. 24.102 / 57. 24.103 libavformat 57. 25.100 / 57. 25.100 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 31.100 / 6. 32.100 libavresample 3. 0. 0 / 3. 0. 0 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100
With 1a708780f3d4b431996d118df4e448b4f2a7942e checkout the problem is like in 3.1 mpv, kodi, chromium doesn't work, when ffplay is able to play an mp3 file:
comment:37 by , 8 years ago
| Component: | undetermined → avutil |
|---|---|
| Status: | new → open |
follow-up: 39 comment:38 by , 8 years ago
Replying to marillat:
Replying to jamrial:
That's not "libavfilter 6. 31.100 / 6. 47.100" (ffmpeg 3.0 cli from your distro using release/3.1 libraries at runtime).
Syill the same with ffplay 6. 31.100 / 6. 47.100
I just tried release/3.0 ffplay with release/3.1 libraries and i can play mp3 files just fine
ffplay version n3.0.2-27-gfbdf5ca Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 5.4.0 (Rev1, Built by MSYS2 project)
configuration: --enable-gpl --enable-shared --target-os=mingw32 --arch=x86_64 --cpu=haswell --extra-cflags='-D_WIN32_WINNT=0x0602' --samples=../samples --prefix=/mingw64
libavutil 55. 17.103 / 55. 27.100
libavcodec 57. 24.102 / 57. 48.101
libavformat 57. 25.100 / 57. 40.101
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 47.100
libswscale 4. 0.100 / 4. 1.100
libswresample 2. 0.101 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[mp3 @ 00000207af80e2e0] Skipping 1044 bytes of junk at 2927.=0/0
[mp3 @ 00000207af80e2e0] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'Caramell - Caramelldansen (Speedycake Remix).mp3':
Metadata:
title : Caramelldansen (Speedycake Remix)
artist : Caramell
Duration: 00:02:56.80, start: 0.000000, bitrate: 320 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
1.30 M-A: 0.000 fd= 0 aq= 26KB vq= 0KB sq= 0B f=0/0
1.46 M-A: 0.000 fd= 0 aq= 29KB vq= 0KB sq= 0B f=0/0
Commit 0a6d7602308e0f3060d9a6e6b44ae7bf5bbd7841 from release/3.1 changed the field order in AVFilterLink and now it's the same as in 3.0, fixing ffplay 3.0 with 3.1 libraries.
This bug is gone with 26abd5149ebf9602d8036be4c6e72e08c98ea998 checkout for mpv, kodi and chromium
Alright, this confirms the issue is that all three of those projects are directly accessing fields from AVFrame that are marked as no direct access.
This is not an ffmpeg bug but theirs. Kodi already fixed them in https://github.com/xbmc/xbmc/pull/10043 (not yet committed). mpv doesn't plan to fix them as mentioned in comment 32, and Chromium should probably be made aware of it.
Distros should recompile all three applications (preferably a version where they fixed their api misuse) to target ffmpeg 3.1.1 (to be released soon).
but ffplay still fail. here is libraries version with this commit.
libavutil 55. 17.103 / 55. 18.100 libavcodec 57. 24.102 / 57. 24.103 libavformat 57. 25.100 / 57. 25.100 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 31.100 / 6. 32.100 libavresample 3. 0. 0 / 3. 0. 0 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100With 1a708780f3d4b431996d118df4e448b4f2a7942e checkout the problem is like in 3.1 mpv, kodi, chromium doesn't work, when ffplay is able to play an mp3 file:
The commit that broke ffplay (10424024a16a7646169b9c9008c5f7b77cbc2211) is newer than this one. There's no way this checkout fails with ffplay. See:
ffplay version n3.0.2-27-gfbdf5ca Copyright (c) 2003-2016 the FFmpeg developers
built with gcc 5.4.0 (Rev1, Built by MSYS2 project)
configuration: --enable-gpl --enable-shared --target-os=mingw32 --arch=x86_64 --cpu=haswell --extra-cflags='-D_WIN32_WINNT=0x0602' --samples=../samples --prefix=/mingw64
libavutil 55. 17.103 / 55. 18.100
libavcodec 57. 24.102 / 57. 24.103
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 32.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
[mp3 @ 0000029c2d69e1c0] Skipping 1044 bytes of junk at 2927.=0/0
[mp3 @ 0000029c2d69e1c0] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'Caramell - Caramelldansen (Speedycake Remix).mp3':
Metadata:
title : Caramelldansen (Speedycake Remix)
artist : Caramell
Duration: 00:02:56.80, start: 0.000000, bitrate: 320 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
1.07 M-A: -0.000 fd= 0 aq= 29KB vq= 0KB sq= 0B f=0/0
I'm not closing this ticket for now since there are still some ongoing discussions regarding these applications misusing ffmpeg's api.
comment:39 by , 8 years ago
Replying to jamrial:
Alright, this confirms the issue is that all three of those projects are directly accessing fields from AVFrame that are marked as no direct access.
This is not an ffmpeg bug but theirs. Kodi already fixed them in https://github.com/xbmc/xbmc/pull/10043 (not yet committed). mpv doesn't plan to fix them as mentioned in comment 32, and Chromium should probably be made aware of it.
Kody, mpv chromium and maybe others.
mlt is also broken :
Loading envelope ...
"Processing audio, please wait."
[mp3 @ 0xa0361680] Header missing
[producer avformat] foo.mp3
audio decoding error -1094995529
comment:40 by , 8 years ago
I think you did not get the point. FFmpeg is not in any way responsible for broken software that uses ffmpeg in a wrong way, by e.g. non public API usage.
As responsible downstream maintainer, make upstream aware of these issues and fix the root cause.
For kodi you can pick the linked PR, but keep in in mind that kodi upstream only supports statically linked ffmpeg anyways.
follow-up: 43 comment:41 by , 8 years ago
a branch that attempts to keep the private fields in the same location is here:
(if anyone wants to test if for example that would fix all issues)
https://github.com/michaelni/FFmpeg/tree/ABI-3.1.1
comment:42 by , 8 years ago
| Cc: | added |
|---|
comment:43 by , 8 years ago
Replying to michael:
a branch that attempts to keep the private fields in the same location is here:
(if anyone wants to test if for example that would fix all issues)
https://github.com/michaelni/FFmpeg/tree/ABI-3.1.1
kodi, mpv, chromium and ffplay works fine. I don't remember the mlt (melt) command line to reproduce this bug.
Thanks Michael for your work.
follow-up: 45 comment:44 by , 8 years ago
Hendrik asks on the ML if the frame.h commit (https://github.com/michaelni/FFmpeg/commit/7d6e0b9e3045b73cbf480119ea49d57c614fa010) is enough to fix this or if the 2nd commit (https://github.com/michaelni/FFmpeg/commit/972e898fafbd37849b4d1c5d7e8ebf7f9a480394) is needed too?
comment:45 by , 8 years ago
Replying to michael:
Hendrik asks on the ML if the frame.h commit (https://github.com/michaelni/FFmpeg/commit/7d6e0b9e3045b73cbf480119ea49d57c614fa010) is enough to fix this or if the 2nd commit (https://github.com/michaelni/FFmpeg/commit/972e898fafbd37849b4d1c5d7e8ebf7f9a480394) is needed too?
The first patch fix mpv and chromium but not kodi.
Both patches fix also kodi.
follow-up: 47 comment:46 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
fixes in release/3.1 branch will be in 3.1.1
(77473002898f1dce18761c8a9bca48a8fe888d2e, f617b94c233fb070810c03478968c3e036787564)
follow-up: 48 comment:47 by , 8 years ago
Replying to michael:
fixes in release/3.1 branch will be in 3.1.1
(77473002898f1dce18761c8a9bca48a8fe888d2e, f617b94c233fb070810c03478968c3e036787564)
For the record, this was not a "fix" but rather a compromise from our side where we decided to break our own ABI to accommodate to the fact library users misuse our APIs. And all to save distros some headaches.
comment:48 by , 8 years ago
Replying to jamrial:
Replying to michael:
fixes in release/3.1 branch will be in 3.1.1
(77473002898f1dce18761c8a9bca48a8fe888d2e, f617b94c233fb070810c03478968c3e036787564)
For the record, this was not a "fix" but rather a compromise from our side where we decided to break our own ABI to accommodate to the fact library users misuse our APIs. And all to save distros some headaches.
Thanks, I appreciate your efforts.
Please explain how the issue you see can be reproduced.