September 2011 - FFmpeg-trac - lists.ffmpeg.org

#464(FFmpeg:new): Bad merge commit from qatar/master ?
by FFmpeg 13 Sep '11

13 Sep '11

#464: Bad merge commit from qatar/master ? --------------------------------------+--------------------------------- Reporter: zimbatm | Owner: michael Type: defect | Status: new Priority: normal | Component: FFmpeg Version: git-master | Keywords: Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- After the merge commit 411cc5c46a89ce0a79832c37d0eab1ed884e5423, opt_thread_count is missing from ffmpeg.c (with other things) but still present if ffplay.c I think this change was unintended -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/464> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 3

#448(avcodec:new): libx264 preset's rc_lookahead value is overwritten
by FFmpeg 12 Sep '11

12 Sep '11

#448: libx264 preset's rc_lookahead value is overwritten ------------------------------------+-------------------------------------- Reporter: rectalogic | Type: defect Status: new | Priority: normal Component: avcodec | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+-------------------------------------- Specifying -preset slow with libx264 should result in rc_lookahead of 50, instead it is 40. In X264_init() x4->params.rc.i_lookahead is initialized to 50 by x264_param_default_preset() for the "slow" preset. But then later it is overwritten by avctx->rc_lookahead which is 40 This problem was introduced in commit d4b967131842e7c225e5f83cb82337d4474a0bb7 which added the rc_lookahead private option. From a gdb session: {{{ 257 if (x4->preset || x4->tune) (gdb) 258 if (x264_param_default_preset(&x4->params, x4->preset, x4->tune) < 0) { (gdb) p x4->preset $7 = 0x14790c0 "slow" (gdb) n 263 if (avctx->level > 0) (gdb) p x4->params.rc.i_lookahead $8 = 50 [...] 335 if (avctx->rc_lookahead >= 0) (gdb) 336 x4->params.rc.i_lookahead = avctx->rc_lookahead; (gdb) 337 if (avctx->weighted_p_pred >= 0) (gdb) p x4->params.rc.i_lookahead $9 = 40 }}} Full ffmpeg output: {{{ ffmpeg -i /tmp/apollo11.mov -an -codec:v libx264 -preset:v slow -y /tmp/foo.mp4 ffmpeg version N-32420-g88fddd0, Copyright (c) 2000-2011 the FFmpeg developers built on Sep 9 2011 20:33:39 with gcc 4.4.3 configuration: --extra-cflags=-I/opt/motionbox/foundation/6.4.0/include --extra-ldflags=-L/opt/motionbox/foundation/6.4.0/lib --enable-libx264 --enable-gpl --enable-debug=gdb3 --disable-optimizations libavutil 51. 16. 0 / 51. 16. 0 libavcodec 53. 13. 0 / 53. 13. 0 libavformat 53. 12. 0 / 53. 12. 0 libavdevice 53. 3. 0 / 53. 3. 0 libavfilter 2. 39. 0 / 2. 39. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 51. 2. 0 / 51. 2. 0 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x25d6780] max_analyze_duration 5000000 reached at 5000000 Seems stream 0 codec frame rate differs from container frame rate: 600.00 (600/1) -> 3.00 (3/1) Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/tmp/apollo11.mov': Metadata: creation_time : 1998-01-05 21:59:31 Duration: 00:00:06.66, start: 0.000000, bitrate: 22 kb/s Stream #0.0(eng): Video: svq1 (SVQ1 / 0x31515653), yuv410p, 80x60, 13 kb/s, SAR 1:1 DAR 4:3, 3 fps, 3 tbr, 600 tbn, 600 tbc Metadata: creation_time : 1998-01-05 21:59:31 Stream #0.1(eng): Audio: qcelp (Qclp / 0x706C6351), 8000 Hz, 1 channels, flt Metadata: creation_time : 1998-01-05 21:59:31 Incompatible pixel format 'yuv410p' for codec 'libx264', auto-selecting format 'yuv420p' [buffer @ 0x25d1200] w:80 h:60 pixfmt:yuv410p tb:1/1000000 sar:1/1 sws_param: [buffersink @ 0x25d7ec0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0x25d8520] w:80 h:60 fmt:yuv410p -> w:80 h:60 fmt:yuv420p flags:0x4 [libx264 @ 0x25de5c0] using SAR=1/1 [libx264 @ 0x25de5c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 [libx264 @ 0x25de5c0] profile Main, level 1.0 [libx264 @ 0x25de5c0] 264 - core 116 mbox/4.3.1 - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=0 b_adapt=2 b_bias=0 direct=3 weightb=0 open_gop=0 weightp=2 keyint=250 keyint_min=3 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to '/tmp/foo.mp4': Metadata: creation_time : 1998-01-05 21:59:31 encoder : Lavf53.12.0 Stream #0.0(eng): Video: h264 (![0][0][0] / 0x0021), yuv420p, 80x60 [SAR 1:1 DAR 4:3], q=-1--1, 3 tbn, 3 tbc Metadata: creation_time : 1998-01-05 21:59:31 Stream mapping: Stream #0.0 -> #0.0 (svq1 -> libx264) Press [q] to stop, [?] for help frame= 20 fps= 0 q=21.0 Lsize= 16kB time=00:00:06.33 bitrate= 20.8kbits/s video:15kB audio:0kB global headers:0kB muxing overhead 7.083741% frame I:1 Avg QP:20.35 size: 867 [libx264 @ 0x25de5c0] frame P:9 Avg QP:22.59 size: 852 [libx264 @ 0x25de5c0] frame B:10 Avg QP:23.73 size: 611 [libx264 @ 0x25de5c0] consecutive B-frames: 15.0% 50.0% 15.0% 20.0% [libx264 @ 0x25de5c0] mb I I16..4: 15.0% 0.0% 85.0% [libx264 @ 0x25de5c0] mb P I16..4: 4.4% 0.0% 57.8% P16..4: 10.6% 11.7% 15.6% 0.0% 0.0% skip: 0.0% [libx264 @ 0x25de5c0] mb B I16..4: 0.0% 0.0% 37.5% B16..8: 18.0% 18.0% 19.6% direct: 6.5% skip: 0.5% L0:49.4% L1:27.2% BI:23.4% [libx264 @ 0x25de5c0] direct mvs spatial:0.0% temporal:100.0% [libx264 @ 0x25de5c0] coded y,uvDC,uvAC intra: 96.1% 94.7% 63.3% inter: 75.4% 92.2% 28.5% [libx264 @ 0x25de5c0] i16 v,h,dc,p: 0% 64% 18% 18% [libx264 @ 0x25de5c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 32% 13% 11% 5% 6% 9% 6% 8% 10% [libx264 @ 0x25de5c0] i8c dc,h,v,p: 35% 18% 29% 17% [libx264 @ 0x25de5c0] Weighted P-Frames: Y:33.3% UV:22.2% [libx264 @ 0x25de5c0] ref P L0: 76.5% 8.8% 5.9% 5.9% 1.5% 1.5% [libx264 @ 0x25de5c0] ref B L0: 96.8% 2.4% 0.9% [libx264 @ 0x25de5c0] kb/s:17.57 }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/448> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 2

#373(avdevice:new): e35c674d breaks alsa output in matroska
by FFmpeg 12 Sep '11

12 Sep '11

#373: e35c674d breaks alsa output in matroska -------------------------+---------------------- Reporter: llogan | Owner: Type: defect | Status: new Priority: normal | Component: avdevice Version: git-master | Keywords: Blocked By: | Blocking: Reproduced: 0 | Analyzed: 0 -------------------------+---------------------- [http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e35c674d13a7f180412cfe0585… e35c674d13a7f180412cfe058530a2e7f1d49a90] bad [http://git.videolan.org/?p=ffmpeg.git;a=commit;h=8bfd7f6a475225a0595bf657f8… 8bfd7f6a475225a0595bf657f8b99a8fffb461e4] good {{{ $ ./ffmpeg -v 9 -loglevel 99 -f alsa -ac 2 -i pulse -acodec pcm_s16le -y ~/output.mka ffmpeg version N-31358-g2f56a97, Copyright (c) 2000-2011 the FFmpeg developers built on Jul 30 2011 11:33:09 with gcc 4.5.2 configuration: libavutil 51. 11. 0 / 51. 11. 0 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 5. 0 / 53. 5. 0 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 24. 3 / 2. 24. 3 libswscale 2. 0. 0 / 2. 0. 0 [alsa @ 0xac4a360] All info found [alsa @ 0xac4a360] Estimating duration from bitrate, this may be inaccurate Input #0, alsa, from 'pulse': Duration: N/A, start: 1312054761.614575, bitrate: N/A Stream #0.0, 1, 1/1000000: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s Output #0, matroska, to '/home/lou/output.mka': Metadata: encoder : Lavf53.5.0 Stream #0.0, 0, 1/1000: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop, [?] for help [matroska @ 0xac45920] Writing block at offset 519, size 128, pts 0, dts 0, duration 1, flags 128 [matroska @ 0xac45920] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1 >= 1 av_interleaved_write_frame(): Invalid argument }}} This output is from [http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2f56a97f2488146f209de415e3… 2f56a97f] which merged the bad commit. 32-bit Ubuntu Natty. Current git master (g3b5ddf0) has the same behavior. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/373> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 4

#273(avcodec:new): h264 video decoding aborts due to too low number of "slices"
by FFmpeg 12 Sep '11

12 Sep '11

#273: h264 video decoding aborts due to too low number of "slices" -----------------------------------+-------------------------- Reporter: gerhard_s | Type: defect Status: new | Priority: normal Component: avcodec | Version: unspecified Keywords: h264 slice MAX_SLICES | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | -----------------------------------+-------------------------- I'm using h264 video codec for VoIP between linphone (on my machine, openSUSE 11.4, x86_64, using ffmpeg git dated on 20110604 and libx264-115) and Bria 3.2 (on Windows 7) on the other end. I had the problem that after a few seconds the call terminated issuing the message "Too many slices, increase MAX_SLICES and recompile". I patched h264.h by increasing MAX_SLICES from 16 to 32 and now it works fine again. I think MAX_SLICES is currently too low, should be increased to at least 32. I don't know if Bria would send even more slices if the bandwidth was even bigger or video resolution was bigger. Is there a limit given by the codec for a reasonable upper threshold? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/273> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 7

#323(avfilter:new): [patch] properly detect and compile with opencv 2.2+
by FFmpeg 12 Sep '11

12 Sep '11

#323: [patch] properly detect and compile with opencv 2.2+ ----------------------+-------------------------- Reporter: mm | Type: enhancement Status: new | Priority: normal Component: avfilter | Version: unspecified Keywords: opencv | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | ----------------------+-------------------------- For libavfilter/vf_libopencv.c starting with OpenCV version 2.2 only the opencv_core and opencv_imgproc headers and libraries are required. Example patch below adds proper support for this case. This is relevant for master and oldabi. {{{ diff --git a/configure b/configure index fd4b034..ea74df3 100755 --- a/configure +++ b/configure @@ -2900,6 +2900,8 @@ enabled libnut && require libnut libnut.h nut_demuxer_init -lnut enabled libopencore_amrnb && require libopencore_amrnb opencore- amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb enabled libopencore_amrwb && require libopencore_amrwb opencore- amrwb/dec_if.h D_IF_init -lopencore-amrwb enabled libopencv && require_pkg_config opencv opencv/cxcore.h cvCreateImageHeader +enabled libopencv && check_pkg_config opencv opencv2/imgproc/imgproc_c.h cvCreateImageHeader && add_cflags -DHAVE_OPENCV2 || + require_pkg_config opencv opencv/cxcore.h cvCreateImageHeader enabled libopenjpeg && require libopenjpeg openjpeg.h opj_version -lopenjpeg enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h RTMP_Socket enabled libschroedinger && require_pkg_config schroedinger-1.0 schroedinger/schro.h schro_init diff --git a/libavfilter/vf_libopencv.c b/libavfilter/vf_libopencv.c index e1b51c5..f22b2bc 100644 --- a/libavfilter/vf_libopencv.c +++ b/libavfilter/vf_libopencv.c @@ -25,8 +25,13 @@ /* #define DEBUG */ +#ifdef HAVE_OPENCV2 +#include <opencv2/core/core_c.h> +#include <opencv2/imgproc/imgproc_c.h> +#else #include <opencv/cv.h> #include <opencv/cxcore.h> +#endif #include "libavutil/avstring.h" #include "libavutil/file.h" #include "avfilter.h" }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/323> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 2

#380(avfilter:new): Mistake in ffmpeg's docs for yadif
by FFmpeg 12 Sep '11

12 Sep '11

#380: Mistake in ffmpeg's docs for yadif ----------------------+-------------------------- Reporter: pshchelo | Type: defect Status: new | Priority: normal Component: avfilter | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | ----------------------+-------------------------- == Docs describe the values for yadif's parity parameter the other way around. == '''ffmpeg version''': N-31706-g335bbe4 I've checked main git branch and docs are still like in the version I've used. == Test file == Attached test file: dv-bff.avi This is a short sample of video captured from JVC camcorder through IEEE1394 with the help of Windows Import Video on Windows Vista. This is DV video and it must be interlaced with bottom-field-first (BFF) field order as stated in many places, e.g here [http://avisynth.org/mediawiki/Interlaced_fieldbased#About_DV_.2F_DVD_in_rel…] == How to test for error: == apply yadif with BFF (according to ffmpeg's yadif docs), field separation and doubling the framerate: ffmpeg -i dv-bff.avi -vf yadif=1:0 -r 50 output.avi You will get a jagged video, although by applying yadif=1:1 (which, according to the docs, is top-field-first) you get a smooth playback. == Reasoning == I have tripple-checked the parity with other tools. GSpot video analysis software reports it to be BFF. If you play tricks similar to the one above with !VirtualDub and mplayer, the results also point that the video is BFF. In fact, applying the same yadif parameters in mplayer and ffmpeg results in the same behaviour, athough according to their respective docs the meaning of parity values 0 or 1 is exactly opposite. The auto parity recognition of ffmpeg works fine though - video encoded with yadif=1:-1 plays smoothly. I have also checked this with DVD interlaced source, which, according to this[http://avisynth.org/mediawiki/Interlaced_fieldbased#About_DV_.2F_DVD_i…, must be top-field-first. The result is similar to DV case - Gspot reports TFF, mplayer's yadif plays it nice with TFF, but ffmpeg's yadif plays it nice with BFF as per docs. As summary I strongly suspect the mistake in ffmeg's docs for yadif filter - there the explanations of meanings for the field parity parameter should be swapped. I made a corresponding patch to filters.texi file and attached it here. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/380> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 5

#242(undetermined:new): add support for -newdata
by FFmpeg 11 Sep '11

11 Sep '11

#242: add support for -newdata ----------------------------+-------------------------- Reporter: dericed | Type: enhancement Status: new | Priority: normal Component: undetermined | Version: unspecified Keywords: dcodec newdata | Blocked By: Blocking: | Reproduced: 0 Analyzed: 0 | ----------------------------+-------------------------- Since we now have -dcodec, can we have -newdata. This would allow users to copy more than one data track from the source container to the output container. -- Ticket URL: <http://ffmpeg.org/trac/ffmpeg/ticket/242> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 2

#459(avcodec:new): YASM Generation error in dsputil_yasm.asm & workaround
by FFmpeg 11 Sep '11

11 Sep '11

#459: YASM Generation error in dsputil_yasm.asm & workaround -------------------------------------+------------------------------------- Reporter: sabouring | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: yasm clipd | master macro | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Since August, 16th, i have problem to generate "libavcodec/x86/dsputil_yasm.asm". It gives the following errors : YASM libavcodec/x86/dsputil_yasm.o libavcodec/x86/dsputil_yasm.asm:1122: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1122: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1122: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1122: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1122: error: undefined symbol `CLIPD_MMX.loop' (first use) libavcodec/x86/dsputil_yasm.asm:1122: error: (Each undefined symbol is reported only once.) libavcodec/x86/dsputil_yasm.asm:1125: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1125: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1125: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1125: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1127: error: undefined symbol `CLIPD_SSE2.loop' (first use) libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: instruction expected after label libavcodec/x86/dsputil_yasm.asm:1130: error: undefined symbol `CLIPD_SSE41.loop' (first use) make: *** [libavcodec/x86/dsputil_yasm.o] Error 1 I am currently using openSUSE, and YASM version is : # yasm --version yasm 1.1.0.2352 Finally I found that the problem was commit 38e06c2, where clipd macros have moved from libavcodec/x86/dsputil_yasm.asm to libavutil/x86/x86util.asm : commit 38e06c2969184b5b55ec41d0c053b2480ab52846 Author: Ronald S. Bultje <rsbultje(a)gmail.com> Date: Tue Aug 16 21:23:53 2011 -0700 Move clipd macros to x86util.asm. This allows sharing them between multiple .asm files. libavcodec/x86/dsputil_yasm.asm | 34 +--------------------------------- libavutil/x86/x86util.asm | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 33 deletions(-) Having a look at the code, i can't see anything wrong; macro have moved, but an include has been properly added in dsputil_yasm.asm. However, i am not a YASM expert but i guess this is a YASM bug. Up to now i have simply reverted 38e06c2, since noone seemed to use this common part elsewhere in the code. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/459> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 10

#457(undetermined:new): vaapi h264 decoding artefacts
by FFmpeg 11 Sep '11

11 Sep '11

#457: vaapi h264 decoding artefacts -------------------------------------+------------------------------------- Reporter: gimli | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I work on vaapi support for xine using ffmpeg as decoder. While working in my xine stuff i discovered that since quite a while decoding of some h264 live material on dvb-s2 was broken with vaapi in ffmpeg. The affected material was showing artefacts in the decoded picture. After some research i discovered following commit for vpdau : http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a4ab70f92e4d8705434a2fee42… based on that commit i made similar changes to vaapi_h264.c which are in the attached patch. This patch is fixing the artefacts. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/457> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 1

#445(FFmpeg:new): Wrong FLV duration metadata field
by FFmpeg 11 Sep '11

11 Sep '11

#445: Wrong FLV duration metadata field -------------------------------------+------------------------------------- Reporter: burek | Owner: michael Type: defect | Status: new Priority: minor | Component: FFmpeg Version: git- | Keywords: flv meta master | duration Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 -------------------------------------+------------------------------------- When ffmpeg is used like this: '''ffmpeg -t 00:00:30 -i valid.flv -acodec copy -vcodec copy invalid.flv''' (extracting a part of the video to a new file) then the resulting file (invalid.flv) contains wrong duration metadata field (copied from the original 'valid.flv') which confuses all FLV web players, because the navigation can't be accurate because of that. I personally always use "'''flvmeta -Uf invalid.flv'''" after this kind of cutting, but it would be nice if ffmpeg would actually write correct values in the output file -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/445> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

1 3