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

#3399(undetermined:new): Scaling MP4 Video results in bad output MP4
by FFmpeg 25 Oct '24

25 Oct '24

#3399: Scaling MP4 Video results in bad output MP4 --------------------------------------+---------------------------------- Reporter: mressler | Type: defect Status: new | Priority: normal Component: undetermined | Version: 2.1.3 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------------+---------------------------------- Summary of the bug: Attempting to scale an MP4/H264 1920x1080 source video to 1024:-1 (also Mp4/H264) results in odd playback in different players. VLC shows green box artifacts, QuickTime and MPlayer both show jerky/slow playback. How to reproduce: (Grab source from: https://www.dropbox.com/s/thy8zxbvx1ygqru/VID_20130619_161750_449.mp4) {{{ % ffmpeg -i VID_20130619_161750_449.mp4 -vf "scale=1024:-1" VID_scaled.mp4 }}} VID_scaled.mp4 ends up with green artifacts in VLC and doesn't play appropriately in QuickTime or MPlayer. Interestingly, if I clip the video first via: {{{ % ffmpeg -i VID_20130619_161750_449.mp4 -ss 18 -t 15 -c:v copy -c:a copy clip2.mp4 }}} And then run the scale command: {{{ % ffmpeg -i clip2.mp4 -vf "scale=1024:-1" VID_clip_scaled.mp4 }}} The resulting video plays fine in VLC, QuickTime, and MPlayer. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3399> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#3386(undetermined:new): [H264] [Regression] illegal short term buffer state detected
by FFmpeg 19 Jun '24

19 Jun '24

#3386: [H264] [Regression] illegal short term buffer state detected -------------------------------------+------------------------------------- Reporter: | Type: defect Underground78 | Priority: normal Status: new | Version: git- Component: | master undetermined | Blocked By: Keywords: | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- '''Summary of the bug:''' A regression in H264 decoding was apparently introduced about 3 months ago. It leads to artifacts appearing during playback with "illegal short term buffer state detected" errors being reported in the log. '''How to reproduce:''' Try [http://stfcc.org/misc/bbc2.sample.ts this sample] in ffplay for example. {{{ >ffplay.exe bbc2.sample.ts ffplay version N-60646-gd601106 Copyright (c) 2003-2014 the FFmpeg developers built on Feb 15 2014 03:11:41 with gcc 4.8.2 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable- librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo- aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-zlib libavutil 52. 63.101 / 52. 63.101 libavcodec 55. 52.101 / 55. 52.101 libavformat 55. 32.101 / 55. 32.101 libavdevice 55. 9.101 / 55. 9.101 libavfilter 4. 1.102 / 4. 1.102 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 [NULL @ 04011580] start time is not set in estimate_timings_from_pts [mpegts @ 0400d160] PES packet size mismatch Last message repeated 1 times Input #0, mpegts, from 'bbc2.sample.ts': Duration: 00:00:47.48, start: 0.200000, bitrate: 8424 kb/s Program 1 Stream #0:0[0x157c]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv , bt709), 1440x1080 [SAR 4:3 DAR 16:9], 23.75 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x157d](eng): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, ster eo, fltp, 192 kb/s Stream #0:2[0x157f](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) Stream #0:3[0x1580](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) No codec could be found with id 94215 [h264 @ 054c1980] illegal short term buffer state detected }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3386> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#3438(documentation:new): Add documentation for adding a FATE test
by FFmpeg 02 Oct '23

02 Oct '23

#3438: Add documentation for adding a FATE test -------------------------------------+------------------------------------- Reporter: | Owner: Timothy_Gu | Status: new Type: | Component: enhancement | documentation Priority: wish | Keywords: fate Version: git- | Blocking: master | Analyzed by developer: 0 Blocked By: | Reproduced by developer: 1 | -------------------------------------+------------------------------------- Documentation for adding a FATE test is very useful for people who submit their own small filter or decoder and who wish to add regression tests for them. Libav has a rudimentary tutorial [https://wiki.libav.org/FATE here]. The place I have on mind to store this kind of info is [[FATE/AddingATest]]. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3438> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#3433(ffmpeg:new): using "shortest" results in mismatched audio and video lengths
by FFmpeg 02 Oct '23

02 Oct '23

#3433: using "shortest" results in mismatched audio and video lengths -----------------------------------+-------------------------------------- Reporter: mjmvisser | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git-master Keywords: shortest | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+-------------------------------------- Summary of the bug: "-shortest" does not add trim/atrim filters, so the length of each output stream will be a multiple of sample size. In the given example, the video is exactly 1s, but the resulting output is 1.02s. If "-t 1.000" is passed instead of "-shortest", the resulting output is exactly 1s. The difference is that using "-t" adds trim/atrim filters, so the last frame->nb_samples encoded will be truncated to fit the given duration. How to reproduce: {{{ % ffmpeg -y -probesize 500000 -f image2 -r 25 -i colorbars.%04d.png -i 100Hz_44100Hz_16bit_05sec.wav -shortest -c:v png -c:a pcm_s16le -q:v 1 -2 -f mov colorbars.mov Note that input streams have durations of 5s and 1s. % ffprobe colorbars.mov Note that the output stream has a duration of 1.02s. ffmpeg version N-60960-gf3eef02 built on Feb 28 2014 10:31:20 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3433> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#3457(undetermined:new): HEVC encoding (to mkv) broken since Mar 9 in ffmpeg
by FFmpeg 08 Nov '22

08 Nov '22

#3457: HEVC encoding (to mkv) broken since Mar 9 in ffmpeg -------------------------------------+------------------------------------- Reporter: | Type: defect johnthescavenger | Priority: normal Status: new | Version: Component: | unspecified undetermined | Blocked By: Keywords: | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- So, if you build ffmpeg with x265, and try to use it to encode HEVC video to an MKV file, then it dies with the following message: {{{Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input}}} This is using x265 at revision 6468. Earlier versions of ffmpeg did work, but then they started dying with that message recently. I did a git- bisect; one of the commits temporarily broke the build, so I had to skip it, but I was able to narrow it down to these: {{{ The first bad commit could be any of: a823d0948683bd97dd58556b5740e434166209a8 38aee6408a6732b8ac86341dabf6683c08caa1c1 We cannot bisect more! }}} Both of these talk about HEVC, and one talks about Matroska. (There have been API changes to x265 in the past, but in this case the problem seems to be on ffmpeg's end.) Full error output and command used: {{{ Alvin:~ john$ ~/ffmpeg/build/ffmpeg -i Redlettermedia- TheDudebrosEpisode1TooGloseForComfort624.m4v -vcodec hevc -acodec copy out.mkv ffmpeg version N-61313-g1f36ebf Copyright (c) 2000-2014 the FFmpeg developers built on Mar 11 2014 21:55:56 with gcc 4.8.2 (MacPorts gcc48 4.8.2_0) configuration: --enable-libx265 --enable-libopus --enable-gpl libavutil 52. 66.101 / 52. 66.101 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 34.100 / 55. 34.100 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, mov,mp4,m4a,3gp,3g2,mj2, from 'Redlettermedia- TheDudebrosEpisode1TooGloseForComfort624.m4v': Metadata: major_brand : M4V minor_version : 1 compatible_brands: isomiso2avc1M4A M4V mp42 creation_time : 1970-01-01 00:00:00 encoder : Lavf52.62.0 Duration: 00:01:13.84, start: 0.000000, bitrate: 702 kb/s Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 640x358 [SAR 1:1 DAR 320:179], 613 kb/s, 29.97 fps, 29.97 tbr, 2997 tbn, 59.94 tbc (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : VideoHandler Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 86 kb/s (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : SoundHandler x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64 x265 [info]: Main profile, Level-2.1 (Main tier) x265 [info]: WPP streams / pool / frames : 6 / 2 / 1 x265 [info]: CU size : 64 x265 [info]: Max RQT depth inter / intra : 1 / 1 x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / refs : 1 / 1 / 3 x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-200 kbps / 1.0 / 1 x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide Output #0, matroska, to 'out.mkv': Metadata: major_brand : M4V minor_version : 1 compatible_brands: isomiso2avc1M4A M4V mp42 encoder : Lavf55.34.100 Stream #0:0(eng): Video: hevc (libx265), yuv420p, 640x358 [SAR 1:1 DAR 320:179], q=2-31, 200 kb/s, 90k tbn, 29.97 tbc (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : VideoHandler Stream #0:1(eng): Audio: aac ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, 86 kb/s (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : SoundHandler Stream mapping: Stream #0:0 -> #0:0 (h264 -> libx265) Stream #0:1 -> #0:1 (copy) Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3457> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

#3595(avcodec:new): Support >5 channels in E-AC-3 audio
by FFmpeg 13 Sep '22

13 Sep '22

#3595: Support >5 channels in E-AC-3 audio ----------------------------------+--------------------------------------- Reporter: 11rcombs | Type: enhancement Status: new | Priority: minor Component: avcodec | Version: git-master Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- E-AC-3 supports up to 15 full-bandwidth channels, but libavcodec's encoder currently doesn't support 6.1 and 7.1 channel layouts. Do these layouts just need to be added to ff_ac3_channel_layouts, or would this require additional work on the encoder? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3595> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 35

#3511(undetermined:new): support FrameRate in dpx files
by FFmpeg 29 Jul '22

29 Jul '22

#3511: support FrameRate in dpx files -------------------------------------+------------------------------------- Reporter: dericed | Owner: Type: | Status: new enhancement | Component: Priority: normal | undetermined Version: git- | Keywords: dpx master | Blocking: Blocked By: | Analyzed by developer: 0 Reproduced by developer: 0 | -------------------------------------+------------------------------------- Summary of the enhancement: A request for frame rate support in the dpx encoder/decoder. The dpx IndustryFilmInfoHeader (and the Television one) have a frame rate field. See: http://www.fileformat.info/format/dpx/egff.htm How to reproduce: Making a test set of dpx files at 18 fps. I use -t 1 and -r:v 18 so 18 dpx files are created. {{{ ffmpeg -f lavfi -i color -r:v 18 -t 1 -f image2 -y 18fps_%06d.dpx ffmpeg version 2.2 Copyright (c) 2000-2014 the FFmpeg developers built on Mar 26 2014 16:18:04 with Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2 --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 --enable-ffplay --enable-libopenjpeg --extra- cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 ' 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, lavfi, from 'color': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc Output #0, image2, to '18fps_%06d.dpx': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: dpx, rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 90k tbn, 18 tbc Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> dpx) Press [q] to stop, [?] for help frame= 18 fps=0.0 q=-1.0 Lsize=N/A time=00:00:01.00 bitrate=N/A dup=0 drop=4 video:4079kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -100.000526% }}} Reading the first dpx shows a default frame rate of 25. {{{ ffmpeg -i 18fps_000001.dpx ffmpeg version 2.2 Copyright (c) 2000-2014 the FFmpeg developers built on Mar 26 2014 16:18:04 with Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2 --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 --enable-ffplay --enable-libopenjpeg --extra- cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 ' 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, image2, from '18fps_000001.dpx': Duration: 00:00:00.04, start: 0.000000, bitrate: N/A Stream #0:0: Video: dpx, rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc At least one output file must be specified }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3511> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3409(undetermined:new): Impossible to transcode full range RGB videos with libx264, and keep full range + proper colors
by FFmpeg 15 Jan '22

15 Jan '22

#3409: Impossible to transcode full range RGB videos with libx264, and keep full range + proper colors -------------------------------------+------------------------------------- Reporter: mzso | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I encountered this while trying to transcode screencasted videos with fraps or ut-video streams. When using yuv444p pixel format I get washed out, too light videos. "-color_range" has no affect. People suggested: "-vf colormatrix=bt601:bt709" But it also doesn't have an affect. x264 itself has issues with RGB full range videos, if I use i444 with it I also get improper output. But if I use "--output-csp rgb" it succeds in encoding a proper output file, though with a large file size. I can't even achieve this with ffmpeg because it doesn't let me use RGB with libx264: "Incompatible pixel format 'rgb24' for codec 'libx264', auto-selecting format 'yuv444p'" -- Ticket URL: <https://trac.ffmpeg.org/ticket/3409> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 24

#3389(ffmpeg:new): Feature Request - Isolate and normalize video content
by FFmpeg 29 Aug '21

29 Aug '21

#3389: Feature Request - Isolate and normalize video content -------------------------------------+------------------------------------- Reporter: Rafajafar | Type: Status: new | enhancement Component: ffmpeg | Priority: wish Keywords: feature | Version: request normalize video | unspecified Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Hey, I have an interesting problem and I'm solving it with OpenCV. It's be great if the solution could come straight from ffmpeg, though! I need to: 1) cropdetect 2) crop surrounding borders from a video 3) resize video to normalize its dimensions In other words, all I want is one command that will detect the frame-by- frame borders and in the same step, crop it, and also resize it. And I want this done for the entire video, not a single frame. It's gotta be possible, right? The applications are very useful in video analysis. I've spoken to colleagues of mine and they are doing this manually themselves. It would be great to be able to work this feature into the automation surrounding ffmpeg in our tools. My personal application, for instance, is in detecting videos that are similar using content perceptual hashing. Another colleague of mine works for the Center for Missing and Exploited Children. He does similar work, but with pHashing. I can see applications for ContentID type systems across the board. I'm sure this is a low on the totem pole request, but if you have any spare cycles, this would really rock in the world of computer vision and video analysis! Thanks for your consideration, --Collin -- Ticket URL: <https://trac.ffmpeg.org/ticket/3389> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3586(avcodec:new): [discrepancy with libav] avcodec_encode_video2 merges packet side data with the packet body
by FFmpeg 10 Apr '21

10 Apr '21

#3586: [discrepancy with libav] avcodec_encode_video2 merges packet side data with the packet body -------------------------------------+------------------------------------- Reporter: Lastique | Type: defect Status: new | Priority: normal Component: avcodec | Version: 2.2.1 Keywords: libav | Blocked By: avcodec_encode_video2 avpacket | Reproduced by developer: 0 av_packet_merge_side_data | Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- We have an application which uses ffmpeg to encode video in h263. The application requests h263_mb_info side data by setting the "mb_info" option on the encoder context: {{{ av_opt_set_int(av_ctx, "mb_info", 1400, AV_OPT_SEARCH_CHILDREN) }}} Later we call avcodec_encode_video2() to encode frames. The problem is that ffmpeg avcodec_encode_video2() returns AVPackets with the encoded frame and some amount of junk at the end. From the source code I can see that the junk is actually the encoded side data (mb_info) appended to the h263 packet by av_packet_merge_side_data() which is called by avcodec_encode_video2(). This appended side data prevents the packets from being decoded by ffmpeg 2.2.1 (I tried both decoding through the API and ffplay). Decoding results in many messages such as: {{{ slice end not reached but screenspace end (399 left 019CE3, score= -7) concealing 88 DC, 88 AC, 88 MV errors in P frame }}} and corrupted image. This is also different from libav behavior. At least 9.x and 10.x versions don't merge side data into the packet body, and when using libav we don't have the decoding problem. Looking at the libavcodec code I don't really understand why the call to av_packet_merge_side_data() is needed. Side data, at least mb_info in case of h263, is not the part of the encoded media and thus should not be part of the packet body. Since the packet size (AVPacket::size) includes the appended side data, there is no way to obtain the size of the actual media. I suspect, av_packet_split_side_data() can be used to restore the original un-merged packet, but (a) it is not documented and (b) doing av_packet_merge_side_data() and av_packet_split_side_data() is a waste of memory and CPU (note: we pre-allocate packet data buffer to optimize performance). Therefore my preferred solution would be to remove the call to av_packet_merge_side_data() from avcodec_encode_video2(). If that call cannot be removed then what is the correct way to obtain the actual media from the merged packet? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3586> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11