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

#5005(ffmpeg:new): monitor index alias for gdigrab input specification as handy alternative in multimonitors environments
by FFmpeg 13 Nov '15

13 Nov '15

#5005: monitor index alias for gdigrab input specification as handy alternative in multimonitors environments ----------------------------------+--------------------------------------- Reporter: user7415 | Type: enhancement Status: new | Priority: minor Component: ffmpeg | Version: unspecified Keywords: gdigrab | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- It's just a feature request. Using gdigrab I was wondering if is possible to select monitors by using an alias based on the monitor number index instead of cropping to a specific resolution with region and offsets. This will make a command more portable and resolution independent. Es: i have 3 monitors. ffmpeg -y -f -i monitor=1 -framerate 30 -c:v ffv1 capture.mkv to capture only the monitor index 1 ffmpeg -y -f -i monitor=1,2 -framerate 30 -c:v ffv1 capture.mkv to capture monitor 1 and 2 ffmpeg -y -f -i monitor=2,1,4 -framerate 30 -c:v ffv1 capture.mkv to capture monitor 2,1 and 4 stitched in the specified order. I hope it will not be a big deal, but will be nice if you will implement it! Best Regards -- Ticket URL: <https://trac.ffmpeg.org/ticket/5005> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#5004(undetermined:new): ffmpeg leaks memory decoding mpeg2video/encoding mpeg1video
by FFmpeg 13 Nov '15

13 Nov '15

#5004: ffmpeg leaks memory decoding mpeg2video/encoding mpeg1video -------------------------------------+------------------------------------- Reporter: c-14 | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When decoding raw mpeg2video and encoding to raw mpeg1video, ffmpeg leaks memory. Note: I have been unable to reproduce with non-mpeg2video input (eg using -f lavfi -i testsrc directly in the command encoding to mpeg1video does not cause the leaks) How to reproduce: {{{ ffbuild/source/ffmpeg/ffmpeg_g -hide_banner -loglevel quiet -f lavfi -i testsrc -c:v mpeg2video -t 120 -f mpeg2video pipe:1 | valgrind --leak- check=yes ffbuild/source/ffmpeg/ffmpeg_g -f mpegvideo -threads 1 -i - -f mpeg1video -an -threads 1 - > /dev/null ==6798== Memcheck, a memory error detector ==6798== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6798== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==6798== Command: ffbuild/source/ffmpeg/ffmpeg_g -f mpegvideo -threads 1 -i - -f mpeg1video -an -threads 1 - ==6798== ffmpeg version N-76639-g58d32c0 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.3 (Gentoo 4.9.3 p1.0, pie-0.6.2) configuration: --prefix=/home/radiocarbon/ffbuild --extra-libs=-lstdc++ --enable-fontconfig --enable-libzimg --enable-gpl --enable-libass --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 libavutil 55. 5.100 / 55. 5.100 libavcodec 57. 15.100 / 57. 15.100 libavformat 57. 14.100 / 57. 14.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 15.100 / 6. 15.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100 Input #0, mpegvideo, from 'pipe:': Duration: N/A, bitrate: N/A Stream #0:0: Video: mpeg2video (Main), yuv420p(tv), 320x240 [SAR 1:1 DAR 4:3], max. 104857 kb/s, 25 fps, 25 tbr, 1200k tbn, 50 tbc Output #0, mpeg1video, to 'pipe:': Metadata: encoder : Lavf57.14.100 Stream #0:0: Video: mpeg1video, yuv420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc57.15.100 mpeg1video Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> mpeg1video (native)) frame= 3000 fps= 67 q=7.2 Lsize= 3214kB time=00:02:00.00 bitrate= 219.4kbits/s video:3214kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% ==6798== ==6798== HEAP SUMMARY: ==6798== in use at exit: 1,265,196 bytes in 8,995 blocks ==6798== total heap usage: 482,338 allocs, 473,343 frees, 32,619,710 bytes allocated ==6798== ==6798== 358 bytes in 1 blocks are possibly lost in loss record 3 of 7 ==6798== at 0x4C2C576: memalign (vg_replace_malloc.c:858) ==6798== by 0x4C2C691: posix_memalign (vg_replace_malloc.c:1021) ==6798== by 0xEBA04F: av_malloc (mem.c:97) ==6798== by 0xEAA913: av_buffer_alloc (buffer.c:71) ==6798== by 0xEAA913: av_buffer_make_writable (buffer.c:157) ==6798== by 0x94E487: make_tables_writable (mpegpicture.c:45) ==6798== by 0x94E487: ff_alloc_picture (mpegpicture.c:259) ==6798== by 0x954DB3: alloc_picture (mpegvideo.c:350) ==6798== by 0x954DB3: ff_mpv_frame_start (mpegvideo.c:1246) ==6798== by 0x91C57A: mpeg_field_start (mpeg12dec.c:1674) ==6798== by 0x922CCB: decode_chunks (mpeg12dec.c:2716) ==6798== by 0x92341E: mpeg_decode_frame (mpeg12dec.c:2832) ==6798== by 0xA78667: avcodec_decode_video2 (utils.c:2103) ==6798== by 0x494591: decode_video (ffmpeg.c:2092) ==6798== by 0x498C4F: process_input_packet (ffmpeg.c:2341) ==6798== ==6798== 1,264,798 (71,952 direct, 1,192,846 indirect) bytes in 2,998 blocks are definitely lost in loss record 7 of 7 ==6798== at 0x4C2C576: memalign (vg_replace_malloc.c:858) ==6798== by 0x4C2C691: posix_memalign (vg_replace_malloc.c:1021) ==6798== by 0xEBA35B: av_malloc (mem.c:97) ==6798== by 0xEBA35B: av_mallocz (mem.c:254) ==6798== by 0xEAA7FD: av_buffer_ref (buffer.c:94) ==6798== by 0xEB3394: frame_copy_props.constprop.4 (frame.c:361) ==6798== by 0x95F66A: frame_end (mpegvideo_enc.c:1660) ==6798== by 0x95F66A: ff_mpv_encode_picture (mpegvideo_enc.c:1832) ==6798== by 0xA78133: avcodec_encode_video2 (utils.c:1858) ==6798== by 0x496841: do_video_out (ffmpeg.c:1196) ==6798== by 0x49BE80: reap_filters (ffmpeg.c:1387) ==6798== by 0x47D20A: transcode_step (ffmpeg.c:4059) ==6798== by 0x47D20A: transcode (ffmpeg.c:4103) ==6798== by 0x47D20A: main (ffmpeg.c:4296) ==6798== ==6798== LEAK SUMMARY: ==6798== definitely lost: 71,952 bytes in 2,998 blocks ==6798== indirectly lost: 1,192,846 bytes in 5,995 blocks ==6798== possibly lost: 358 bytes in 1 blocks ==6798== still reachable: 40 bytes in 1 blocks ==6798== suppressed: 0 bytes in 0 blocks ==6798== Reachable blocks (those to which a pointer was found) are not shown. ==6798== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==6798== ==6798== For counts of detected and suppressed errors, rerun with: -v ==6798== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/5004> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

Re: [FFmpeg-trac] #1845(avformat:closed): Encoded movies with mov_text subtitles do not play with QT Player
by FFmpeg 12 Nov '15

12 Nov '15

#1845: Encoded movies with mov_text subtitles do not play with QT Player --------------------------------------+------------------------------------ Reporter: Atarikid | Owner: Type: defect | Status: closed Priority: normal | Component: avformat Version: git-master | Resolution: fixed Keywords: mov mov_text | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | --------------------------------------+------------------------------------ Changes (by philipl): * status: open => closed * resolution: => fixed Comment: During GSoC this year, my intern implemented support for most of the text formatting capabilities in timed text, including applying a non-trivial default style when encoding. He didn't do anything with display area positioning and sizing, but nevertheless, we now observe that, at least on OSX, the QT Player is happily showing subtitles at a reasonable size in a reasonable position. I suspect this is due to the default style being more meaningful, and triggering some default positioning logic in the QT Player. So, certainly this is fixed on OSX. My intern said he was not able to see any subtitles on windows with or without his changes. That still needs investigating, but it's a separate issue, so I'm going to mark this as closed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1845#comment:31> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1869(avformat:closed): Decode raw v210 streams
by FFmpeg 12 Nov '15

12 Nov '15

#1869: Decode raw v210 streams -------------------------------------+------------------------------------ Reporter: ximmortal | Owner: Type: enhancement | Status: closed Priority: wish | Component: avformat Version: git-master | Resolution: fixed Keywords: v210 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------ Changes (by kierank): * status: reopened => closed * resolution: => fixed Comment: Fixed in 480bad7c6d087d9cd10ae4ab7b4e12cb594aa4c5 -- Ticket URL: <https://trac.ffmpeg.org/ticket/1869#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1087(avcodec:open): support decoding the CineForm codec
by FFmpeg 11 Nov '15

11 Nov '15

#1087: support decoding the CineForm codec -------------------------------------+------------------------------------- Reporter: dericed | Owner: Type: enhancement | Status: open Priority: wish | Component: avcodec Version: git-master | Resolution: Keywords: CFHD, | Blocked By: CineForm | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by richardpl): Get specification and contact developers, me for example. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1087#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1087(avcodec:open): support decoding the CineForm codec
by FFmpeg 11 Nov '15

11 Nov '15

#1087: support decoding the CineForm codec -------------------------------------+------------------------------------- Reporter: dericed | Owner: Type: enhancement | Status: open Priority: wish | Component: avcodec Version: git-master | Resolution: Keywords: CFHD, | Blocked By: CineForm | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by caseyh): With VR coming down the pipeline, we are looking at the best way of dealing with much higher resolution files efficiently and it seems that for windows, Cineform may be the best way to go when dealing with moving between Adobe and ffmpeg. What is the proper place to try to contribute to VC-5 decoding (any maybe even encoding?) support to be added to avcodec. Also, what is needed to make this happen - I can gather documents and contact people easily enough. Also, what is necessary to increase the priority for the ticket? -- Ticket URL: <https://trac.ffmpeg.org/ticket/1087#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#3842(avformat:new): AAC (mp4a) DASH takes abnormally long to detect (~4 - 6s)
by FFmpeg 11 Nov '15

11 Nov '15

#3842: AAC (mp4a) DASH takes abnormally long to detect (~4 - 6s) -------------------------------------+------------------------------------- Reporter: viperfx | Type: defect Status: new | Priority: normal Component: avformat | Version: 2.2.4 Keywords: DASH, mp4a, | Blocked By: aac | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: It takes roughly ~4s for FFmpeg to detect the codec of a mp4a audio stream in the DASH container for an audio of length ~3m. The audio stream is from youtube. I have checked the location of the moov atom and it appears to be at the front of the file. I have spoken with devs on #ffmpeg-devel and they have confirmed the same issue and suggest that it should not take this long. Here is the output using boxdumper: http://tny.cz/571eb4af How to reproduce: {{{ Obtain the youtube audio stream link using youtube-dl (https://github.com/rg3/youtube-dl) % youtube-dl -f 140 -g YOUTUBE_URL where YOUTUBE_URL is the url of any youtube video. Pick a music video of length 3-4mins so you can notice the ~4s delay. The youtube-dl command will print out a long URL string that you can input to FFmpeg or ffplay to notice the issue % ffmpeg -i "STREAM_URL" or % ffplay "STREAM_URL" My FFmpeg info: ffmpeg version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 9 2014 10:03:55 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2.1 --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-libfdk-aac --enable- openssl 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 Output of a typical audio stream: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'STREAM_URL': Metadata: major_brand : dash minor_version : 0 compatible_brands: iso6mp41 creation_time : 2014-03-08 01:30:29 Duration: 00:04:00.70, start: 0.000000, bitrate: 127 kb/s Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) Metadata: creation_time : 2014-03-08 01:30:29 handler_name : SoundHandler }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3842> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 16

#4984(undetermined:new): ffmpeg amerge and amix filter delay when working with RTSP
by FFmpeg 09 Nov '15

09 Nov '15

#4984: ffmpeg amerge and amix filter delay when working with RTSP -------------------------------------+------------------------------------- Reporter: leogsa | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: RTSP | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- ffmpeg amerge and amix filter delay I need to take audio-streams from several IP cameras and merge them into one stream, so that they would sound simaltaneousely. I tried filter "amix": (for testing purposes I take audio-stream 2 times from the same camera. yes, I tried 2 cameras - result is the same) ffmpeg -i rtsp://user:pass@172.22.5.202 -i rtsp://user:pass@172.22.5.202 -map 0:a -map 1:a -filter_complex amix=inputs=2:duration=first:dropout_transition=3 -ar 22050 -vn -f flv rtmp://172.22.45.38:1935/live/stream1 result: I say "hello". And hear in speakers the first "hello" and in 1 second I hear the second "hello". Instead of hearing two "hello"'s simaltaneousely. also I tried filter "amerge": ffmpeg -i rtsp://user:pass@172.22.5.202 -i rtsp://user:pass@172.22.5.202 -map 0:a -map 1:a -filter_complex amerge -ar 22050 -vn -f flv rtmp:// 172.22.45.38:1935/live/stream1 result: the same as in the first example, but now I hear the first "hello" in left speaker and in 1 second I hear the second "hello" in right speaker, instead of hearing two "hello"'s in both speakers simaltaneousely. Here is ful command-line output for both variants: amix: ffmpeg -i rtsp://admin:12345@172.22.5.202 -i rtsp:// admin:12345 at 172.22.5.202 -map 0:a -map 1:a -filter_complex amix=inputs=2:duration=longest:dropout_transition=0 -vn -ar 22050 -f flv rtmp://172.22.45.38:1935/live/stream1 ffmpeg version N-76031-g9099079 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-16) configuration: --enable-gpl --enable-libx264 --enable-libmp3lame --enable-nonfree --enable-version3 libavutil 55. 4.100 / 55. 4.100 libavcodec 57. 6.100 / 57. 6.100 libavformat 57. 4.100 / 57. 4.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 11.100 / 6. 11.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.100 / 2. 0.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, rtsp, from 'rtsp://admin:12345@172.22.5.202': Metadata: title : Media Presentation Duration: N/A, start: 0.032000, bitrate: N/A Stream #0:0: Video: h264 (Baseline), yuv420p, 1280x720, 20 fps, 25 tbr, 90k tbn, 40 tbc Stream #0:1: Audio: adpcm_g726, 8000 Hz, mono, s16, 16 kb/s Stream #0:2: Data: none Input #1, rtsp, from 'rtsp://admin:12345@172.22.5.202': Metadata: title : Media Presentation Duration: N/A, start: 0.032000, bitrate: N/A Stream #1:0: Video: h264 (Baseline), yuv420p, 1280x720, 20 fps, 25 tbr, 90k tbn, 40 tbc Stream #1:1: Audio: adpcm_g726, 8000 Hz, mono, s16, 16 kb/s Stream #1:2: Data: none Output #0, flv, to 'rtmp://172.22.45.38:1935/live/stream1': Metadata: title : Media Presentation encoder : Lavf57.4.100 Stream #0:0: Audio: mp3 (libmp3lame) ([2][0][0][0] / 0x0002), 22050 Hz, mono, fltp (default) Metadata: encoder : Lavc57.6.100 libmp3lame Stream mapping: Stream #0:1 (g726) -> amix:input0 Stream #1:1 (g726) -> amix:input1 amix -> Stream #0:0 (libmp3lame) Press [q] to stop, [?] for help [rtsp @ 0x2689600] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [rtsp @ 0x2727c60] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [rtsp @ 0x2689600] max delay reached. need to consume packet [NULL @ 0x268c500] RTP: missed 38 packets [rtsp @ 0x2689600] max delay reached. need to consume packet [NULL @ 0x268d460] RTP: missed 4 packets [flv @ 0x2958360] Failed to update header with correct duration. [flv @ 0x2958360] Failed to update header with correct filesize. size= 28kB time=00:00:06.18 bitrate= 36.7kbits/s video:0kB audio:24kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 16.331224% and amerge: # ffmpeg -i rtsp://admin:12345@172.22.5.202 -i rtsp:// admin:12345 at 172.22.5.202 -map 0:a -map 1:a -filter_complex amerge -vn -ar 22050 -f flv rtmp://172.22.45.38:1935/live/stream1 ffmpeg version N-76031-g9099079 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-16) configuration: --enable-gpl --enable-libx264 --enable-libmp3lame --enable-nonfree --enable-version3 libavutil 55. 4.100 / 55. 4.100 libavcodec 57. 6.100 / 57. 6.100 libavformat 57. 4.100 / 57. 4.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 11.100 / 6. 11.100 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.100 / 2. 0.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, rtsp, from 'rtsp://admin:12345@172.22.5.202': Metadata: title : Media Presentation Duration: N/A, start: 0.064000, bitrate: N/A Stream #0:0: Video: h264 (Baseline), yuv420p, 1280x720, 20 fps, 25 tbr, 90k tbn, 40 tbc Stream #0:1: Audio: adpcm_g726, 8000 Hz, mono, s16, 16 kb/s Stream #0:2: Data: none Input #1, rtsp, from 'rtsp://admin:12345@172.22.5.202': Metadata: title : Media Presentation Duration: N/A, start: 0.032000, bitrate: N/A Stream #1:0: Video: h264 (Baseline), yuv420p, 1280x720, 20 fps, 25 tbr, 90k tbn, 40 tbc Stream #1:1: Audio: adpcm_g726, 8000 Hz, mono, s16, 16 kb/s Stream #1:2: Data: none [Parsed_amerge_0 @ 0x3069cc0] No channel layout for input 1 [Parsed_amerge_0 @ 0x3069cc0] Input channel layouts overlap: output layout will be determined by the number of distinct input channels Output #0, flv, to 'rtmp://172.22.45.38:1935/live/stream1': Metadata: title : Media Presentation encoder : Lavf57.4.100 Stream #0:0: Audio: mp3 (libmp3lame) ([2][0][0][0] / 0x0002), 22050 Hz, stereo, s16p (default) Metadata: encoder : Lavc57.6.100 libmp3lame Stream mapping: Stream #0:1 (g726) -> amerge:in0 Stream #1:1 (g726) -> amerge:in1 amerge -> Stream #0:0 (libmp3lame) Press [q] to stop, [?] for help [rtsp @ 0x2f71640] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [rtsp @ 0x300fb40] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [rtsp @ 0x2f71640] max delay reached. need to consume packet [NULL @ 0x2f744a0] RTP: missed 18 packets [flv @ 0x3058b00] Failed to update header with correct duration. [flv @ 0x3058b00] Failed to update header with correct filesize. size= 39kB time=00:00:04.54 bitrate= 70.2kbits/s video:0kB audio:36kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 8.330614% UPDATE 30 oct 2015: I found interesting detail when connecting 2 cameras (they have different microphones and I hear the difference between them): the order of "Hello"'s from different cams depends on the ORDER OF INPUTS. with command ffmpeg -i rtsp://cam2 -i rtsp://cam1 -map 0:a -map 1:a -filter_complex amix=inputs=2:duration=longest:dropout_transition=0 -vn -ar 22050 -f flv rtmp://172.22.45.38:1935/live/stream1 I hear "hello" from 1st cam and then in 1 second "hello" from 2nd cam. ----- with command ffmpeg -i rtsp://cam1 -i rtsp://cam2 -map 0:a -map 1:a -filter_complex amix=inputs=2:duration=longest:dropout_transition=0 -vn -ar 22050 -f flv rtmp://172.22.45.38:1935/live/stream1 I hear "hello" from 2nd cam and then in 1 second "hello" from 1st cam. So, As I understand - ffmpeg takes inputs not simaltaneousely, but in the order of inputs given. P.S. FILES are mixed and merged perfectly with same commands. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4984> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#4999(undetermined:new): Skipping frames for GoPro videos recorder with Ambarella
by FFmpeg 09 Nov '15

09 Nov '15

#4999: Skipping frames for GoPro videos recorder with Ambarella -------------------------------------+------------------------------------- Reporter: Den-ffmpeg | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Hi! I am trying to work with GoPro videos made by Ambarella AVC. I tried to convert any video from that camera and output video was lagging. The problem is old, it was reproduced in version 2.8.1 and has been existing at least from version 2.2.4 Input and output videos are attached. How to reproduce: {{{ ffmpeg -i "D:\videos\h264_gopro_ambarella.mp4" -vcodec h264 "D:\videos\lags_on_output_video.avi" ffmpeg version 2.8.1 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-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpe g --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-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable- decklink --enable-zlib libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 }}} PS if you try to convert input file (h264_gopro_ambarella.mp4), you will see some errors in console output. It appeared after I reduced the size of file to 10 MB. If needed I will send you original file (about 25 MB) -- Ticket URL: <https://trac.ffmpeg.org/ticket/4999> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

Re: [FFmpeg-trac] #726(undetermined:open): support for copying SMPTE 436M caption tracks
by FFmpeg 08 Nov '15

08 Nov '15

#726: support for copying SMPTE 436M caption tracks -------------------------------------+------------------------------------- Reporter: dericed | Owner: Type: enhancement | Status: open Priority: wish | Component: Version: git-master | undetermined Keywords: cc mxf | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 1 -------------------------------------+------------------------------------- Comment (by da8eat): I explained last 8 bytes in the post by the link below http://mogurenko.com/2015/10/30/closed-captions-and-mxf/ Replying to [comment:10 funman]: > (8) - ??? > > For the attached sample the last 8 bytes are 0000 004c 0000 0001, for another sample I have it's 0000 0050 0000 0001 > It could be some variation of the "ADF" Ancillary Data Flag which is 0x000 0x3ff 0x3ff -- Ticket URL: <https://trac.ffmpeg.org/ticket/726#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0