November 2015 - FFmpeg-trac - lists.ffmpeg.org

#4869(undetermined:new): Capture with error msg: Application provided invalid, non monotonically increasing
by FFmpeg 08 Nov '15

08 Nov '15

#4869: Capture with error msg: Application provided invalid, non monotonically increasing -------------------------------------+------------------------------------- Reporter: MrNice | 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: I try to capture from a S-VHS player and Dazzle DVC100, audio directly connected from the player to the input line of the integrated audio card. When I run the command I get the following pattern: -Error message in red Application provided invalid, non monotonically increasing dts to muxer in stream 0: Then a frame is dropped Then I get a lot of warning messages in yellow Past duration 0.xxxxxx too large where 0.xxxxxx increase from 0.6xxxx to 0.9xxxx Then stop To test more accurately, I removed the tape from the player and got a blue, still image with the program number wrote in white. This still image is very stable, no static. When I run the command to capture the still image I get the above pattern at regular time. See the first log Then I removed the last part of the command -aspect 4:3 -f sdl "Dazzle output" I get the above pattern WITHOUT the error message in red but still with the warning and frame drop. See the second log When I remove all related to audio (input / output) the error is still present. How to reproduce: ./ffmpeg -report -f pulse -ar 44100 -ac 2 -channel_layout stereo -thread_queue_size 512 -itsoffset -0.20 -i alsa_input.pci-0000_00_14.2 .analog-stereo -f v4l2 -ts mono2abs -channel 1 -video_size 720x576 -pix_fmt yuyv422 -thread_queue_size 512 -i /dev/video0 -c:v ffv1 -level 3 -aspect 4:3 -pix_fmt yuv422p -c:a pcm_s16le /Store3/Test/t_`date +%Y%m%d_%H%M`.mkv -aspect 4:3 -f sdl "Dazzle output" -- Ticket URL: <https://trac.ffmpeg.org/ticket/4869> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#4996(undetermined:new): QuickView Pro not respecting section 4 of the GNU LGPL
by FFmpeg 08 Nov '15

08 Nov '15

#4996: QuickView Pro not respecting section 4 of the GNU LGPL -------------------------------------+------------------------------------- Reporter: | Type: license michael.kostylev | violation Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- The binary archive can be taken from ftp://ftp.multimediaware.com/qv/ Just in case, its contents: Archive: qvpro260.zip Length Date Time Name --------- ---------- ----- ---- 398 2014-11-15 02:00 file_id.diz 1178472 2014-11-15 02:00 qv.exe 38484 2014-11-15 02:00 qv.txt 42594 2014-11-15 02:00 qv.dok 2928 2014-11-15 02:00 changes.txt 1966 2014-11-15 02:00 register.txt 2107 2014-11-15 02:00 register.dok --------- ------- 1266949 7 files Just a few words from http://www.multimediaware.com/qv/qvdoc.htm: This product uses parts of FFmpeg, Copyright (c) Fabrice Bellard. FFmpeg is available under the terms of the GNU Lesser General Public License Source code of FFmpeg can be downloaded from http://ffmpeg.org or is available upon request. The FFmpeg files were used without modification in this product. I would say that this is not enough and the product ignores all requirements from the fourth section of the GNU LGPL v2.1. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4996> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

Re: [FFmpeg-trac] #1452(avformat:reopened): image2 to support %t
by FFmpeg 07 Nov '15

07 Nov '15

#1452: image2 to support %t -------------------------------------+------------------------------------ Reporter: burek | Owner: Type: enhancement | Status: reopened Priority: wish | Component: avformat Version: git-master | Resolution: Keywords: image2 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by OmegaPhil): * cc: OmegaPhil@… (added) -- Ticket URL: <https://trac.ffmpeg.org/ticket/1452#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#4951(ffmpeg:new): Different frame rate using ts and mov containers
by FFmpeg 06 Nov '15

06 Nov '15

#4951: Different frame rate using ts and mov containers -------------------------------------+------------------------------------- Reporter: liamf91 | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: 2.8.1 Keywords: h264 mov ts | Blocked By: frame rate incorrect | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- I am using a udp video source @ 1080i, 25FPS, 25K bitrate, when I output into a .ts and use ffprobe the file shows 25 fps, 50 tbr, 90k tbn, 50 tbc I then change the file extension to be a mov and probe the file i get the following output 50 fps, 50 tbr, 90k tbn, 50 tbc. I am using the following command but just changing the file extension ffmpeg -i udp://@239.200.90.1:11080 -vcodec copy -acodec pcm_s16le -top 1 /tmp/interlaced1080.mov The output from ffmpeg is the following Output #0, mov, to '/tmp/interlaced1080.mov': Metadata: encoder : Lavf56.40.101 Stream #0:0: Video: h264 (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 50 tbr, 90k tbn, 90k tbc Stream #0:1: Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, s16, 1536 kb/s Which displays the it is outputting into the file at 25 fps but this isn't the same when I use ffprobe on the finished file. My version and build information is as follows ffmpeg version 2.8.1-static http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.3 (Debian 4.9.3-4) -- Ticket URL: <https://trac.ffmpeg.org/ticket/4951> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 17

Re: [FFmpeg-trac] #3356(undetermined:open): feature request: Segment HLS streams on SCTE 35 markers
by FFmpeg 06 Nov '15

06 Nov '15

#3356: feature request: Segment HLS streams on SCTE 35 markers -------------------------------------+------------------------------------- Reporter: adamscybot | Owner: Type: enhancement | Status: open Priority: wish | Component: Version: git-master | undetermined Keywords: hls bounty | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Comment (by wkelleher): @er.anshul.maheshwari@gmail.com any progress here? Do you have a branch somewhere that can be tested? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3356#comment:25> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#4989(undetermined:new): avfilter_graph_create_filter() eventually hits pthread::EAGAIN on multi-threading
by FFmpeg 05 Nov '15

05 Nov '15

#4989: avfilter_graph_create_filter() eventually hits pthread::EAGAIN on multi- threading -------------------------------------+------------------------------------- Reporter: czhang384 | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I was trying to convert OPUS to PCM format for my project. And I modified transcoding.c example from the source. I did use one other library as well but chances for its memory problems are really low, so I am guessing some APIs in transcoding.c example may cause memory problem? There was no specific way to reproduce my problem: my program uses ffmpeg to transcode one file, and then passes trancoded file/packet to the other library. I create an infinite loop to test its limit, and it ranges 300~1500 loops of reading one single file (every loop will have 2 ffmpeg to read the same file). But the error is consistent: [AVFilterGraph @ 0x12171640] Error initializing threading. I check with source code, and it gives pthread::EAGAIN, which means the pthread hits the limit. Here are some of my investigations so far: 1. avfilter_graph_create_filter() will call thread_init_internal() internally, and then it creats 25 pthreads each. This means I need to limit # of threads. I use 4 threads, every thread uses 2 ffmpeg to loop the file, so it is 25*4*3 = 200 threads. Given original 4 threads, it expects [4, 204] active threads at any time. I tested it, and it number was correct. 2. I checked memory with valgrind: by running 1-5 thread and loops few times. The consistent memory problem is "40 bytes still reachable". From my research, it is ffmpeg ticket: https://trac.ffmpeg.org/ticket/3194, where one internal mutex lock is not freed and occupies that 40 bytes memory. 3. I run only 1 thread. And so far it has been loop ~1900 times and looks alright. So I am wandering whether any APIs in trancoding.c may allocate some secret memory in multi-threading. If not, I guess I can check other non- ffmpeg-related sections on it. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4989> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#4986(undetermined:new): video artifacts when encoding a 10 bit image sequence, using 10 bit build of x264
by FFmpeg 04 Nov '15

04 Nov '15

#4986: video artifacts when encoding a 10 bit image sequence, using 10 bit build of x264 -------------------------------------+------------------------------------- Reporter: spacediver | 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: When I encode a 16 bit png file using the 10 bit x264 build, there are artifacts present in the video that are not present when the original png files are viewed. I brought this to Zeranoe's attention, who suggested it may be a bug in swscale, and that I report it. How to reproduce: If you have a 10 bit video pipeline (including display), then you won't need to enable dithering in madVR to see this. If you have an 8 bit system, then dithering will need to be enabled (rendering/dithering/pick your favourite dithering mode). Make sure enable fullscreen exclusive mode is checked (rendering/general settings). First, load up "1.png" in madVR, and switch to fullscreen. Turn lights off, and let your eyes dark adapt. You should see 8 distinct vertical bars that fill the screen. Now load up "test.mp4". This is a movie file that was created from an image sequence of 10 images similar to 1.png. Once file is loaded, scroll the slider to the beginning (it should be paused). Now switch to full screen, and inspect the image. On my end, the third and fourth bars are identical, so there are only seven distinct bars. Now using CTRL+rightarrow, step through the 10 frames, and notice how the same sort of artifact appears across many of these gradients. Also notice that on some frames, there are gradient divisions where they shouldn't be. For example, see frame 6 (and compare with 6.png). The images are grayscale gradients. Each image contains eight 10bit codes: the first image has codes 0-7 (out of a possible 1023), the second has codes 8-15, etc. They were created in Matlab, by first encoding in the range of 1-1024, then multiplying by 64, and then subtracting 1, so that they were appropriately scaled to fit the 16 png format. I'm attaching two images (corresponding to the 1st and 6th frames of the mp4), and the encoded mp4. I'm using the following build of ffmeg (static, win32): x264 10-bit Builds (20151027-git-e6f9952), found here: https://ffmpeg.zeranoe.com/blog/?p=435 This is the code I'm using to encode the video: {{{ % ffmpeg -start_number 1 -i %d.png test.mp4 here is the console output: >ffmpeg -start_number 1 -i %d.png test.mp4 ffmpeg version N-76277-ge6f9952 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 5.2.0 (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-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-lib gsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable- libopencore-amrnb --enable-libop encore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable- libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable- libvidstab --enable-libvo-aa cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable- libwavpack --enable-libwebp - -enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --e nable-zlib libavutil 55. 4.100 / 55. 4.100 libavcodec 57. 10.100 / 57. 10.100 libavformat 57. 11.100 / 57. 11.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 14.100 / 6. 14.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.100 / 2. 0.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, image2, from '%d.png': Duration: 00:00:00.40, start: 0.000000, bitrate: N/A Stream #0:0: Video: png, rgb48be(pc), 1920x1200, 25 fps, 25 tbr, 25 tbn, 25 tbc No pixel format specified, yuv444p10le for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. [libx264 @ 009a8c20] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2 [libx264 @ 009a8c20] profile High 4:4:4 Predictive, level 5.0, 4:4:4 10-bit [libx264 @ 009a8c20] 264 - core 148 r2638 7599210 - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http ://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fas t_pskip=1 chroma_qp_offset=4 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlace d=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 op en_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree= 1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=81 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'test.mp4': Metadata: encoder : Lavf57.11.100 Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p10le, 1920x1200, q=-1--1, 25 f ps, 12800 tbn, 25 tbc Metadata: encoder : Lavc57.10.100 libx264 Stream mapping: Stream #0:0 -> #0:0 (png (native) -> h264 (libx264)) Press [q] to stop, [?] for help frame= 10 fps=9.3 q=-1.0 Lsize= 5kB time=00:00:00.32 bitrate= 123.2kbits/s video:4kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 22.623196% [libx264 @ 009a8c20] frame I:1 Avg QP:20.00 size: 551 [libx264 @ 009a8c20] frame P:8 Avg QP:20.62 size: 291 [libx264 @ 009a8c20] frame B:1 Avg QP:21.00 size: 451 [libx264 @ 009a8c20] consecutive B-frames: 80.0% 20.0% 0.0% 0.0% [libx264 @ 009a8c20] mb I I16..4: 0.0% 100.0% 0.0% [libx264 @ 009a8c20] mb P I16..4: 15.8% 4.8% 0.0% P16..4: 0.1% 0.0% 0.0% 0.0% 0.0% skip:79 .3% [libx264 @ 009a8c20] mb B I16..4: 0.0% 5.8% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:94 .2% L0: 0.0% L1: 0.0% BI:100.0% [libx264 @ 009a8c20] 8x8 transform intra:53.4% inter:100.0% [libx264 @ 009a8c20] coded y,u,v intra: 0.0% 0.0% 0.0% inter: 0.0% 0.0% 0.0% [libx264 @ 009a8c20] i16 v,h,dc,p: 98% 0% 2% 0% [libx264 @ 009a8c20] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 0% 83% 0% 0% 0% 0% 0% 0% [libx264 @ 009a8c20] Weighted P-Frames: Y:100.0% UV:0.0% [libx264 @ 009a8c20] kb/s:66.58 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4986> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#4972(ffmpeg:new): Source and Destination have different frame counts
by FFmpeg 04 Nov '15

04 Nov '15

#4972: Source and Destination have different frame counts -------------------------------------+------------------------------------- Reporter: gzrw | Type: defect Status: new | Priority: important Component: ffmpeg | Version: Keywords: different | unspecified frame counts | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug:I encode a clip cut from a film, the frames count of the source is 14408, that of encoded result is 14411. I have almost gone crazy for days, the -vsync options does not resolve my problem at all. How to reproduce: {{{ % rem ffmpeg -y -i 0.264 -c:v libx264 -b:v 700k -s 720x480 -preset fast -f mpegts 0_1.264 ffmpeg version N-71455-gfbdaebb Copyright built with gcc 4.9.2 (GCC) }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4972> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 8

#4232(ffmpeg:new): gdigrab does not get correct monitor resolution on hidpi device when grabbing desktop
by FFmpeg 03 Nov '15

03 Nov '15

#4232: gdigrab does not get correct monitor resolution on hidpi device when grabbing desktop -------------------------------------+------------------------------------- Reporter: umansky | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: Keywords: gdigrab, | unspecified desktop | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: On a hidpi device such as a touchscreen tablet, running Windows 7, attempting to grab the desktop when the DPI setting is set to a number higher than 100% in Control Panel\Appearance and Personalization\Display results in a cropped video and does not grab the entire desktop. If I set the DPI setting back to 100%, gdigrab correctly gets the right resolution, but this is undesierable as text is practically impossible to read. How to reproduce: {{{ % ffmpeg.exe -f gdigrab -i desktop video.mp4 -report ffmpeg version N-68881-ga79ac73 Copyright (c) 2000-2015 the FFmpeg developers built on Jan 5 2015 22:02:22 with gcc 4.9.2 (GCC) }}} This reports the resolution of the tablet as 1280x800, when the actual resolution of the screen is 1920x1200. If I give it the -video_size flag to be the actual resolution of the monitor, it says I've gone out of bounds. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4232> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#4983(undetermined:new): Grayscale PNG to grayscale rawvideo gives strange result
by FFmpeg 02 Nov '15

02 Nov '15

#4983: Grayscale PNG to grayscale rawvideo gives strange result -------------------------------------+------------------------------------- Reporter: kagami | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- I have simple 16x16 grayscale PNG image with checkboard pattern. Pixel values go like this: {{{0x00 0xff ..}}} I convert it to rawvideo grayscale with: {{{ffmpeg -i in.png -f rawvideo -pix_fmt gray out.y}}} and it gives me following result: {{{ $ xxd out.y 00000000: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 00000010: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 00000020: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 00000030: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 00000040: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 00000050: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 00000060: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 00000070: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 00000080: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 00000090: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 000000a0: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 000000b0: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 000000c0: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 000000d0: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ 000000e0: ff00 ff00 ff00 ff00 ff00 ff00 ff00 ff00 ................ 000000f0: 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff ................ }}} For some reason I get {{{0xff 0x00 ..}}} pattern in the output. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4983> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1