July 2014 - FFmpeg-trac - lists.ffmpeg.org

#3714(undetermined:new): Muxing results in bigger file size than original file
by FFmpeg 23 Aug '19

23 Aug '19

#3714: Muxing results in bigger file size than original file -------------------------------------+------------------------------------- Reporter: DavJames | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Muxing results in bigger file size than original file How to reproduce: Created a Mux.bat file as below and put it in the Windows Send To folder. Right-clicked a TS file and selected Send To "Mux.bat" file. The resulting file created is larger than the original. That shouldn't happen. I once had a 22.4GB file and after Muxing it was 1GB larger! "X:\Portable Installations\ffmpeg-2014 May 14-git- 72dcd48-win64-static\bin\ffmpeg.exe" -i %1 -vcodec copy -acodec copy "%~d1%~p1%~n1.copy.ts" FFmpeg version: 2014-05-13 git-72dcd48 -- Ticket URL: <https://trac.ffmpeg.org/ticket/3714> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#3426(avcodec:new): CMYK jpeg image is not detected
by FFmpeg 12 Jan '19

12 Jan '19

#3426: CMYK jpeg image is not detected --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Keywords: mjpeg Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- The second (smaller) sample for ticket #2799 that I found on Wikipedia still does not decode correctly with current FFmpeg, no warning is shown. {{{ $ ffmpeg -i Channel_digital_image_CMYK_color.jpg ffmpeg version N-60950-gfbf9837 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 27 2014 23:27:01 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from 'Channel_digital_image_CMYK_color.jpg': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: mjpeg, yuva444p(pc), 500x333, 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} https://trac.ffmpeg.org/attachment/ticket/2799/Channel_digital_image_CMYK_c… -- Ticket URL: <https://trac.ffmpeg.org/ticket/3426> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3527(undetermined:new): jpegls: support cmyk
by FFmpeg 12 Jan '19

12 Jan '19

#3527: jpegls: support cmyk -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: new Priority: normal | Component: Version: | undetermined unspecified | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 -------------------------------------+------------------------------------- {{{ C:\>ffmpeg -i cmyk.jls out.bmp ffmpeg version N-61570-gaa86ccc Copyright (c) 2000-2014 the FFmpeg developers built on Mar 17 2014 22:01:34 with gcc 4.8.2 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable- libfreetyp e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp eex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable- libvo-aa cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable- libwavp ack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable -zlib libavutil 52. 67.100 / 52. 67.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 34.101 / 55. 34.101 libavdevice 55. 11.100 / 55. 11.100 libavfilter 4. 3.100 / 4. 3.100 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, image2, from 'cmyk.jls': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: jpegls, rgb24, 1024x768, 25 tbr, 25 tbn, 25 tbc Output #0, image2, to 'out.bmp': Metadata: encoder : Lavf55.34.101 Stream #0:0: Video: bmp, bgr24, 1024x768, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (jpegls -> bmp) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:2304kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -100 .000931% }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3527> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3459(undetermined:new): tiff: support cmyk color mode
by FFmpeg 12 Jan '19

12 Jan '19

#3459: tiff: support cmyk color mode -------------------------------------+------------------------------------- Reporter: ami_stuff | Owner: Type: defect | Status: new Priority: normal | Component: Version: | undetermined unspecified | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 -------------------------------------+------------------------------------- http://www.datafilehost.com/d/37fa9042 {{{ C:\>ffmpeg -i 32bit_CMYK.tif ffmpeg version N-61336-g11ed7ec Copyright (c) 2000-2014 the FFmpeg developers built on Mar 13 2014 02:24:33 with gcc 4.5.0 (GCC) 20100414 (Fedora MinGW 4.5. 0-1.fc14) configuration: --prefix=/var/www/users/research/ffmpeg/snapshots/build --arch= x86 --target-os=mingw32 --cross-prefix=i686-pc-mingw32- --cc='ccache i686 -pc-min gw32-gcc' --enable-pthreads --enable-memalign-hack --enable-runtime- cpudetect -- enable-cross-compile --enable-static --disable-shared --extra- libs='-lws2_32 -lw inmm -lpthread' --extra-cflags='--static -I/var/www/users/research/ffmpeg/snapsh ots/build/include' --extra-ldflags='-static -L/var/www/users/research/ffmpeg/sna pshots/build/lib' --enable-bzlib --enable-zlib --enable-gpl --enable- version3 -- enable-nonfree --enable-libx264 --enable-libspeex --enable-libtheora --enable-li bvorbis --enable-libfaac --enable-libxvid --enable-libopencore-amrnb --enable-li bopencore-amrwb --enable-libmp3lame --enable-libfreetype --enable-libvpx --disab le-decoder=libvpx libavutil 52. 66.101 / 52. 66.101 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 34.101 / 55. 34.101 libavdevice 55. 11.100 / 55. 11.100 libavfilter 4. 3.100 / 4. 3.100 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 [tiff @ 0x2300820] Color mode 5 is not supported [image2 @ 0x222f940] decoding for stream 0 failed [image2 @ 0x222f940] Could not find codec parameters for stream 0 (Video: tiff): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options 32bit_CMYK.tif: could not find codec parameters }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3459> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#3726(avcodec:new): mpeg4 vdpau decoding failed
by FFmpeg 28 Dec '18

28 Dec '18

#3726: mpeg4 vdpau decoding failed -------------------------------------+------------------------------------- Reporter: Ilya87 | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: mpeg4 vdpau | master Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Summary of the bug: How to reproduce: {{{ My OS' configuration is Arch Linux x86_64, libvdpau 0.7, nvidia driver 337.25, GeForce GTX 560, ffmpeg built 17.06.2014 15:26 MSK from git Every time I play mpeg4 part2 encoded files using QMPlay2 (with VDPAU) I have the following error (and no image obviously): [mpeg4 @ 0x1b05120] Image too small, temporary buffers cannot function [mpeg4 @ 0x1b05120] get_buffer() failed to allocate context scratch buffers. Without VDPAU all is OK. The same situation repeats with mplayer -vc ffodivxvdpau -vo vdpau "file.avi" [mpeg4 @ 0x7fd25a5ff380]Image too small, temporary buffers cannot function [mpeg4 @ 0x7fd25a5ff380]get_buffer() failed to allocate context scratch buffers. Error while decoding frame! And again all is good with decoding using -vc ffodivx ffplay -decoders show me the following: V....D mpeg4_vdpau MPEG-4 part 2 (VDPAU) (codec mpeg4) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3726> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 8

#3406(avcodec:new): H.264 threaded decode error
by FFmpeg 14 Dec '18

14 Dec '18

#3406: H.264 threaded decode error --------------------------------------+--------------------------------- Reporter: Cigaes | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- There are some samples that decode correctly with threads turned off or only a few threads, but fail to decode with mode threads. For example: {{{ $ ./ffmpeg_g -threads 4 -i /tmp/sf.h264 -f framecrc -c png - ffmpeg version N-60805-gc8f3c3a Copyright (c) 2000-2014 the FFmpeg developers built on Feb 21 2014 20:26:22 with gcc 4.8 (Debian 4.8.2-15) configuration: --enable-shared --disable-static --enable-gpl --enable- libx264 --enable-libopus --enable-libass --enable-libfreetype --enable- opengl --assert-level=2 libavutil 52. 65.100 / 52. 65.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 1.103 / 4. 1.103 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 Input #0, h264, from '/tmp/sf.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv444p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1200k tbn, 50 tbc #software: Lavf55.33.100 #tb 0: 1/25 Output #0, framecrc, to 'pipe:': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: png, rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 -> png) Press [q] to stop, [?] for help 0, 0, 0, 1, 14600, 0x4d4b3314 0, 1, 1, 1, 20624, 0x9d04c3da 0, 2, 2, 1, 20373, 0x3224514e 0, 3, 3, 1, 16474, 0x5a53824a 0, 4, 4, 1, 20997, 0xe2ac63ec 0, 5, 5, 1, 21466, 0x3a5edae1 0, 6, 6, 1, 15290, 0x9fb36a83 0, 7, 7, 1, 19601, 0x8af6664a 0, 8, 8, 1, 20217, 0x96032e30 0, 9, 9, 1, 16655, 0x6e0a0985 0, 10, 10, 1, 18492, 0x12b572b4 0, 11, 11, 1, 18118, 0x6b1994d6 frame= 12 fps=0.0 q=0.0 Lsize= 1kB time=00:00:00.48 bitrate= 12.2kbits/s video:218kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -99.671165% }}} {{{ $ ./ffmpeg_g -threads 5 -i /tmp/sf.h264 -f framecrc -c png - ffmpeg version N-60805-gc8f3c3a Copyright (c) 2000-2014 the FFmpeg developers built on Feb 21 2014 20:26:22 with gcc 4.8 (Debian 4.8.2-15) configuration: --enable-shared --disable-static --enable-gpl --enable- libx264 --enable-libopus --enable-libass --enable-libfreetype --enable- opengl --assert-level=2 libavutil 52. 65.100 / 52. 65.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 1.103 / 4. 1.103 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 Input #0, h264, from '/tmp/sf.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv444p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1200k tbn, 50 tbc #software: Lavf55.33.100 #tb 0: 1/25 Output #0, framecrc, to 'pipe:': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: png, rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 -> png) Press [q] to stop, [?] for help Error while decoding stream #0:0: Invalid data found when processing input [h264 @ 0xa81240] reference picture missing during reorder Last message repeated 1 times [h264 @ 0xa81240] Missing reference picture, default is 65548 Last message repeated 1 times [h264 @ 0xad9200] reference picture missing during reorder [h264 @ 0xad9200] Missing reference picture, default is 65556 0, 0, 0, 1, 14600, 0x4d4b3314 0, 1, 1, 1, 20624, 0x9d04c3da 0, 3, 3, 1, 20373, 0x3224514e 0, 4, 4, 1, 16474, 0x5a53824a 0, 5, 5, 1, 21099, 0x61cb8a88 0, 6, 6, 1, 21466, 0x7d3727ad 0, 8, 8, 1, 15370, 0x4b0bcbbd 0, 9, 9, 1, 19775, 0xed275f1c 0, 10, 10, 1, 16851, 0x0725c06b 0, 11, 11, 1, 16717, 0xd445fc7c frame= 10 fps=0.0 q=0.0 Lsize= 1kB time=00:00:00.48 bitrate= 10.3kbits/s video:179kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -99.663483% }}} The {{{-c png}}} is necessary to reproduce the problem in this particular case, but threading issues are sensitive to timing. Helgrind spews a load of errors too: {{{ ==10123== Helgrind, a thread error detector ==10123== Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al. ==10123== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==10123== Command: ./ffmpeg_g -threads 5 -i /tmp/sf.h264 -f framecrc -c png - ==10123== ffmpeg version N-60805-gc8f3c3a Copyright (c) 2000-2014 the FFmpeg developers built on Feb 21 2014 20:26:22 with gcc 4.8 (Debian 4.8.2-15) configuration: --enable-shared --disable-static --enable-gpl --enable- libx264 --enable-libopus --enable-libass --enable-libfreetype --enable- opengl --assert-level=2 libavutil 52. 65.100 / 52. 65.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 1.103 / 4. 1.103 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 Input #0, h264, from '/tmp/sf.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv444p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1200k tbn, 50 tbc #software: Lavf55.33.100 #tb 0: 1/25 Output #0, framecrc, to 'pipe:': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: png, rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (h264 -> png) Press [q] to stop, [?] for help ==10123== ---Thread-Announcement------------------------------------------ ==10123== ==10123== Thread #11 was created ==10123== at 0x7BC40BE: clone (clone.S:76) ==10123== by 0x78C5FF4: do_clone.constprop.4 (createthread.c:74) ==10123== by 0x78C7473: pthread_create@@GLIBC_2.2.5 (createthread.c:244) ==10123== by 0x4C2D8F0: ??? (in /usr/lib/valgrind/vgpreload_helgrind- amd64-linux.so) ==10123== by 0x58A417F: ff_frame_thread_encoder_init (frame_thread_encoder.c:204) ==10123== by 0x5B7B5D1: avcodec_open2 (utils.c:1305) ==10123== by 0x4210EA: transcode_init (ffmpeg.c:2658) ==10123== by 0x406F8E: main (ffmpeg.c:3413) ==10123== ==10123== ---Thread-Announcement------------------------------------------ ==10123== ==10123== Thread #1 is the program's root thread ==10123== ==10123== ---------------------------------------------------------------- ==10123== ==10123== Lock at 0x103824B0 was first observed ==10123== at 0x4C2E96A: pthread_mutex_init (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x58A4082: ff_frame_thread_encoder_init (frame_thread_encoder.c:176) ==10123== by 0x5B7B5D1: avcodec_open2 (utils.c:1305) ==10123== by 0x4210EA: transcode_init (ffmpeg.c:2658) ==10123== by 0x406F8E: main (ffmpeg.c:3413) ==10123== ==10123== Possible data race during write of size 8 at 0x103814B8 by thread #11 ==10123== Locks held: 1, at address 0x103824B0 ==10123== at 0x58A3E54: worker (frame_thread_encoder.c:105) ==10123== by 0x4C2DA86: ??? (in /usr/lib/valgrind/vgpreload_helgrind- amd64-linux.so) ==10123== by 0x78C6E0D: start_thread (pthread_create.c:311) ==10123== by 0x7BC40FC: clone (clone.S:113) ==10123== ==10123== This conflicts with a previous read of size 8 by thread #1 ==10123== Locks held: none ==10123== at 0x58A4487: ff_thread_video_encode_frame (frame_thread_encoder.c:275) ==10123== by 0x41DCCB: reap_filters (ffmpeg.c:997) ==10123== by 0x407BFD: main (ffmpeg.c:3399) ==10123== ==10123== Address 0x103814B8 is 152 bytes inside a block of size 4856 alloc'd ==10123== at 0x4C2BA30: memalign (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x4C2BB57: posix_memalign (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x6E4A7AC: av_malloc (mem.c:94) ==10123== by 0x6E4A96D: av_mallocz (mem.c:244) ==10123== by 0x58A403F: ff_frame_thread_encoder_init (frame_thread_encoder.c:165) ==10123== by 0x5B7B5D1: avcodec_open2 (utils.c:1305) ==10123== by 0x4210EA: transcode_init (ffmpeg.c:2658) ==10123== by 0x406F8E: main (ffmpeg.c:3413) ==10123== 0, 0, 0, 1, 14600, 0x4d4b3314 0, 1, 1, 1, 20624, 0x9d04c3da4 bitrate= 19.0kbits/s 0, 2, 2, 1, 20373, 0x3224514e8 bitrate= 15.3kbits/s 0, 3, 3, 1, 16474, 0x5a53824a2 bitrate= 14.1kbits/s 0, 4, 4, 1, 20997, 0xe2ac63ec6 bitrate= 13.4kbits/s 0, 5, 5, 1, 21466, 0x3a5edae10 bitrate= 13.1kbits/s 0, 6, 6, 1, 15290, 0x9fb36a832:-22.-77 bitrate=N/A 0, 7, 7, 1, 19601, 0x8af6664a 0, 8, 8, 1, 20217, 0x96032e30 0, 9, 9, 1, 16655, 0x6e0a0985 0, 10, 10, 1, 18492, 0x12b572b4 0, 11, 11, 1, 18118, 0x6b1994d6 frame= 12 fps=0.7 q=0.0 Lsize= 1kB time=00:00:00.48 bitrate= 12.2kbits/s video:218kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -99.671165% ==10123== ---------------------------------------------------------------- ==10123== ==10123== Lock at 0x1038AD20 was first observed ==10123== at 0x4C2E96A: pthread_mutex_init (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x5B75323: default_lockmgr_cb (utils.c:81) ==10123== by 0x5B7AD9D: ff_lock_avcodec (utils.c:3299) ==10123== by 0x5B7B07C: avcodec_open2 (utils.c:1193) ==10123== by 0x54647A3: avformat_find_stream_info (utils.c:2993) ==10123== by 0x412DE0: open_input_file (ffmpeg_opt.c:860) ==10123== by 0x4177C0: ffmpeg_parse_options (ffmpeg_opt.c:2597) ==10123== by 0x406F20: main (ffmpeg.c:3600) ==10123== ==10123== Possible data race during write of size 4 at 0x10385924 by thread #1 ==10123== Locks held: 1, at address 0x1038AD20 ==10123== at 0x5AD50FD: ff_frame_thread_free (pthread_frame.c:565) ==10123== by 0x5754DBA: avcodec_close (utils.c:2602) ==10123== by 0x407618: main (ffmpeg.c:3491) ==10123== ==10123== Address 0x10385924 is 68 bytes inside a block of size 72 alloc'd ==10123== at 0x4C2BA30: memalign (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x4C2BB57: posix_memalign (in /usr/lib/valgrind /vgpreload_helgrind-amd64-linux.so) ==10123== by 0x6E4A7AC: av_malloc (mem.c:94) ==10123== by 0x6E4A96D: av_mallocz (mem.c:244) ==10123== by 0x5AD53E5: ff_frame_thread_init (pthread_frame.c:641) ==10123== by 0x5B7B5FF: avcodec_open2 (utils.c:1313) ==10123== by 0x4214D7: transcode_init (ffmpeg.c:2144) ==10123== by 0x406F8E: main (ffmpeg.c:3413) ==10123== ==10123== ==10123== For counts of detected and suppressed errors, rerun with: -v ==10123== Use --history-level=approx or =none to gain increased speed, at ==10123== the cost of reduced accuracy of conflicting-access information ==10123== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2274 from 350) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3406> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#3783(ffmpeg:new): ffmpeg shoud init decoders before filters
by FFmpeg 14 Dec '18

14 Dec '18

#3783: ffmpeg shoud init decoders before filters --------------------------------------+-------------------------------- Reporter: Cigaes | Owner: Type: defect | Status: new Priority: minor | Component: ffmpeg Version: git-master | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+-------------------------------- {{{ ./ffmpeg_g -lavfi sine -t 5 -y /tmp/test.ac3 ./ffmpeg_g -c ac3_fixed -i /tmp/test.ac3 -f null - }}} {{{ ffmpeg version N-64757-g277e5ca Copyright (c) 2000-2014 the FFmpeg developers built on Jul 18 2014 10:43:46 with gcc 4.9 (Debian 4.9.0-7) configuration: --enable-shared --disable-static --enable-gpl --enable- libx264 --enable-libopus --enable-libass --enable-libfreetype --assert- level=2 libavutil 52. 92.101 / 52. 92.101 libavcodec 55. 69.100 / 55. 69.100 libavformat 55. 48.101 / 55. 48.101 libavdevice 55. 13.102 / 55. 13.102 libavfilter 4. 11.102 / 4. 11.102 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 19.100 / 0. 19.100 libpostproc 52. 3.100 / 52. 3.100 [ac3 @ 0xfc8cc0] Estimating duration from bitrate, this may be inaccurate Input #0, ac3, from '/tmp/test.ac3': Duration: 00:00:05.02, start: 0.000000, bitrate: 96 kb/s Stream #0:0: Audio: ac3, 44100 Hz, mono, fltp, 96 kb/s Output #0, null, to 'pipe:': Metadata: encoder : Lavf55.48.101 Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s Metadata: encoder : Lavc55.69.100 pcm_s16le Stream mapping: Stream #0:0 -> #0:0 (ac3 (ac3_fixed) -> pcm_s16le (native)) Press [q] to stop, [?] for help Input stream #0:0 frame changed from rate:44100 fmt:fltp ch:1 chl:mono to rate:44100 fmt:s16p ch:1 chl:mono size=N/A time=00:00:05.01 bitrate=N/A video:0kB audio:432kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown }}} Notice this particular line: {{{ Input stream #0:0 frame changed from rate:44100 fmt:fltp ch:1 chl:mono to rate:44100 fmt:s16p ch:1 chl:mono }}} This happens because filters are initialized before decoders: some properties of the stream, especially the sample format, often depend on the decoder. If a different decoder is used for decoding than the one used for probing, the result is considered a change in format. This is handled correctly but gives wrong information and wastes resources. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3783> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#3621(avformat:new): "pts < dts" causing crash in av_interleaved_write_frame(): Invalid argument
by FFmpeg 12 Dec '18

12 Dec '18

#3621: "pts < dts" causing crash in av_interleaved_write_frame(): Invalid argument ----------------------------------+-------------------------------------- Reporter: tmm1 | Type: defect Status: new | Priority: normal Component: avformat | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+-------------------------------------- I have some h264/mkv files that ffmpeg blows up on while remuxing, due to non-monotonic pts timestamps. {{{ $ ffmpeg -nostats -i test.mkv -c:v copy -c:a copy out.mkv ffmpeg version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers built on May 7 2014 00:59:53 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: --enable-shared --enable-pthreads --enable-gpl --enable- version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libavresample 1. 2. 0 / 1. 2. 0 libswscale 2. 5.102 / 2. 5.102 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, matroska,webm, from 'test.mkv': Metadata: encoder : libebml v1.3.0 + libmatroska v1.4.0 creation_time : 2014-05-06 09:28:53 Duration: 00:44:21.01, start: 0.000000, bitrate: 0 kb/s Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 2k tbc (default) Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default) Stream #0:2(eng): Subtitle: subrip (default) Output #0, matroska, to 'out.mkv': Metadata: encoder : Lavf55.33.100 Stream #0:0(eng): Video: h264 (H264 / 0x34363248), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 1k tbn, 1k tbc (default) Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), 384 kb/s (default) Stream #0:2(eng): Subtitle: ssa (default) Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Stream #0:2 -> #0:2 (subrip -> ssa) Press [q] to stop, [?] for help [matroska @ 0x7f9c6283de00] pts (375) < dts (418) in stream 0 av_interleaved_write_frame(): Invalid argument frame= 11 fps=0.0 q=-1.0 Lsize= 217kB time=00:00:00.59 bitrate=2983.2kbits/s video:189kB audio:27kB subtitle:0 data:0 global headers:0kB muxing overhead 0.492406% }}} Here are the video packets from -debug_ts on one of the files: {{{ muxer <- type:video pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 size:32998 muxer <- type:video pkt_pts:42 pkt_pts_time:0.042 pkt_dts:42 pkt_dts_time:0.042 size:31878 muxer <- type:video pkt_pts:83 pkt_pts_time:0.083 pkt_dts:83 pkt_dts_time:0.083 size:34437 muxer <- type:video pkt_pts:125 pkt_pts_time:0.125 pkt_dts:125 pkt_dts_time:0.125 size:26936 muxer <- type:video pkt_pts:167 pkt_pts_time:0.167 pkt_dts:167 pkt_dts_time:0.167 size:22856 muxer <- type:video pkt_pts:209 pkt_pts_time:0.209 pkt_dts:209 pkt_dts_time:0.209 size:22355 muxer <- type:video pkt_pts:250 pkt_pts_time:0.25 pkt_dts:250 pkt_dts_time:0.25 size:14882 muxer <- type:video pkt_pts:292 pkt_pts_time:0.292 pkt_dts:292 pkt_dts_time:0.292 size:3548 muxer <- type:video pkt_pts:334 pkt_pts_time:0.334 pkt_dts:334 pkt_dts_time:0.334 size:2954 muxer <- type:video pkt_pts:417 pkt_pts_time:0.417 pkt_dts:417 pkt_dts_time:0.417 size:138 muxer <- type:video pkt_pts:375 pkt_pts_time:0.375 pkt_dts:418 pkt_dts_time:0.418 size:140 [matroska @ 0x7fb88c0eaa00] pts (375) < dts (418) in stream 0 av_interleaved_write_frame(): Invalid argument }}} I believe the error can be ignored, as ffmpeg will attempt to fix timestamps in the output file. {{{ --- a/libavformat/mux.c +++ b/libavformat/mux.c @@ -486,7 +486,6 @@ static int compute_pkt_fields2(AVFormatContext *s, AVStream *st, AVPacket *pkt) if (pkt->dts != AV_NOPTS_VALUE && pkt->pts != AV_NOPTS_VALUE && pkt->pts < pkt->dts) { av_log(s, AV_LOG_ERROR, "pts (%s) < dts (%s) in stream %d\n", av_ts2str(pkt->pts), av_ts2str(pkt->dts), st->index); - return AVERROR(EINVAL); } av_dlog(s, "av_write_frame: pts2:%s dts2:%s\n", }}} With the change above, ffmpeg on master warns me but is able to process my entire input file without crashing: {{{ [matroska @ 0x7fabdc034600] pts (375) < dts (418) in stream 0 [matroska @ 0x7fabdc034600] Non-monotonous DTS in output stream 0:0; previous: 418, current: 375; changing to 418. This may result in incorrect timestamps in the output file. frame= 152 fps=0.0 q=-1.0 Lsize= 4475kB time=00:00:06.48 bitrate=5654.2kbits/s video:4168kB audio:303kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.089263% }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3621> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 10

#3622(avformat:new): Second audio track in mov sometimes marked as default
by FFmpeg 20 Sep '18

20 Sep '18

#3622: Second audio track in mov sometimes marked as default -------------------------------------+------------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: important | Component: avformat Version: git- | Keywords: mov master | regression Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 -------------------------------------+------------------------------------- Related to ticket #468, #1174 and #2626 The following command line produces an output file with exactly one enabled audio track (the first one), the second audio track is not enabled: {{{ $ ffmpeg -i fate-suite/mp3-conformance/compl.bit -i fate- suite/mp3-conformance/he_32khz.bit -acodec aac -strict -2 -map 0:0 -map 1:0 out.mov }}} But the following command produces an output file with two enabled audio tracks, this is bad for playback with QuickTime: {{{ $ ffmpeg -i fate-suite/aac/al04_44.mp4 -i fate-suite/aac/al05_44.mp4 -acodec aac -strict -2 -map 0:0 -map 1:0 out2.mov ffmpeg version N-63026-g54ae588 Copyright (c) 2000-2014 the FFmpeg developers built on May 7 2014 22:40:04 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 52. 81.100 / 52. 81.100 libavcodec 55. 60.103 / 55. 60.103 libavformat 55. 37.102 / 55. 37.102 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'fate-suite/aac/al04_44.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp42isom creation_time : 2004-02-19 14:38:56 Duration: 00:00:08.24, start: 0.000000, bitrate: 67 kb/s Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 63 kb/s (default) Metadata: creation_time : 2004-02-19 14:38:56 handler_name : soun Input #1, mov,mp4,m4a,3gp,3g2,mj2, from 'fate-suite/aac/al05_44.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp42isom creation_time : 2004-02-19 14:38:56 Duration: 00:00:07.43, start: 0.000000, bitrate: 131 kb/s Stream #1:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default) Metadata: creation_time : 2004-02-19 14:38:56 handler_name : soun Output #0, mov, to 'out2.mov': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp42isom encoder : Lavf55.37.102 Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 128 kb/s (default) Metadata: creation_time : 2004-02-19 14:38:56 handler_name : soun Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default) Metadata: creation_time : 2004-02-19 14:38:56 handler_name : soun Stream mapping: Stream #0:0 -> #0:0 (aac -> aac) Stream #1:0 -> #0:1 (aac -> aac) Press [q] to stop, [?] for help size= 252kB time=00:00:08.24 bitrate= 250.6kbits/s video:0kB audio:246kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.660035% }}} out2.mov has both audio tracks enabled, this is a regression since 800ea20c -- Ticket URL: <https://trac.ffmpeg.org/ticket/3622> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 30

#3635(undetermined:new): Have machines for fate and developers with particular instruction sets
by FFmpeg 10 Sep '18

10 Sep '18

#3635: Have machines for fate and developers with particular instruction sets -------------------------------------+------------------------------------- Reporter: kurosu | Type: Status: new | sponsoring request Component: | Priority: normal undetermined | Version: Keywords: | unspecified Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- The benefits would be: - Developers can implement assembly for said insn set (eg aarch64, avx, avx2) - Developers can evaluate the impact of a change on said insn set (eg a buffer change breaking avx but not ssex) - fate can be set up to verify if something breaks on a device with said insn set (eg SSE2 insn used in SSE1 code on SSE1 machine) -- Ticket URL: <https://trac.ffmpeg.org/ticket/3635> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3