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

#3405(undetermined:new): Bizare behaviour with RTP mpegts sources,
by FFmpeg 09 Jan '15

09 Jan '15

#3405: Bizare behaviour with RTP mpegts sources, -------------------------------------+------------------------------------- Reporter: sharbatgula | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: RTP, | Blocked By: mpegts, source mix-up | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Hi, I'm transcoding a bunch of SD sources from SPTS mpegts transported on different multicast addresses with RTP on port 5530. (VBR h264 video, mp2 audio) When I transcode the first source from mcast IP1:5530 the output is sort of OK (occasional green patches and false reporting of unsupported source features) Once I run a second ffmpeg instance to transcode source IP2:5530 the second instance is not ingesting IP2 content but IP1 and both instances start to interfere and they don't even come to a state to start transcoding. It's bizare that even two ffplay instances tuned to different sources play back the same content! I tried playing back with vlc and there is no such problem. {{{ % ffmpeg -y -f mpegts -i rtp://@239.2.2.22:5530 -threads 0 -acodec libfdk_aac -ab 64k -ar 44100 -vcodec libx264 -vprofile baseline -vlevel 1.3 -x264opts fps=25:keyint=100:bitrate=200 -s 320x240 -f mpegts udp://224.10.2.3:5004?pkt_size=1316 I uploaded a sample of my mpegts on: ftp://upload.ffmpeg.org/MPlayer/incoming/ts__sample.ts ffmpeg version 2.1.git built on Jan 30 2014 12:22:30 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3405> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 9

#3404(avfilter:new): Request: hqx filter
by FFmpeg 10 Nov '14

10 Nov '14

#3404: Request: hqx filter -------------------------------------+------------------------------------- Reporter: wyatt8740 | Type: Status: new | enhancement Component: avfilter | Priority: wish Keywords: request hqx | Version: Blocking: | unspecified Analyzed by developer: 0 | Blocked By: | Reproduced by developer: 0 -------------------------------------+------------------------------------- Summary of the request: I'd like a hqx filter for FFmpeg - it would be very useful for video game recordings. The source is here: http://web.archive.org/web/20070125113756/http://www.hiend3d.com/hq3x.html The non - archive.org version of the site does not contain source code or examples. This filter is really amazing, and I hope someone can implement it. Be aware that there is also a hq2x and a hq4x, but I am linking to 3x because it contains the most information on how the filter works. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3404> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

#3427(ffmpeg:new): Negative time format contains too many minuses: -577014:-32:-22.-77
by FFmpeg 31 Aug '14

31 Aug '14

#3427: Negative time format contains too many minuses: -577014:-32:-22.-77 -------------------------------------+------------------------------------- Reporter: | Type: defect q345t7n3o67ym23oy8939t | Priority: normal Status: new | Version: Component: ffmpeg | unspecified Keywords: format | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: time format for negative time contains too many minuses: "-577014:-32:-22.-77", but should be "-577014:32:22.77". ffmpeg version: N-60087-g94a5241 from http://ffmpeg.zeranoe.com/builds/ How to reproduce: {{{ % "ffmpeg.exe" -loglevel "debug" -i "http://93.95.99.231:8200/" -f "segment" -codec "copy" -map "0" -segment_format "mpegts" -segment_list "target file.csv" -segment_list_size "0" -segment_list_type "csv" -segment_time "906" -segment_start_number "0" -reset_timestamps "1" "target file %d.ts" }}} … and wait negative time. My ffmpeg log contains: {{{ frame=89905 fps= 25 q=-1.0 size=N/A time=00:59:57.34 bitrate=N/A frame=89921 fps= 25 q=-1.0 size=N/A time=00:59:57.97 bitrate=N/A frame=89936 fps= 25 q=-1.0 size=N/A time=00:59:58.57 bitrate=N/A frame=89952 fps= 25 q=-1.0 size=N/A time=-577014:-32:-22.-77 bitrate=N/A frame=89952 fps= 25 q=-1.0 Lsize=N/A time=00:59:59.15 bitrate=N/A }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3427> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 16

#3412(avcodec:new): h264 gray decoding failure
by FFmpeg 17 Aug '14

17 Aug '14

#3412: h264 gray decoding failure --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: minor | Component: avcodec Version: git-master | Keywords: h264 Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- Output has green macroblocks, not a regression. {{{ $ ffmpeg -flags +gray -i fate-suite/h264/interlaced_crop.mp4 -qscale 2 out.avi ffmpeg version N-60871-g2a3cb1c Copyright (c) 2000-2014 the FFmpeg developers built on Feb 24 2014 11:17:11 with gcc 4.7 (SUSE Linux) configuration: --enable-gray 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. 1.103 / 4. 1.103 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 18.100 / 0. 18.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'fate- suite/h264/interlaced_crop.mp4': Metadata: major_brand : avc1 minor_version : 0 compatible_brands: isomavc1 creation_time : 2010-10-07 15:03:51 Duration: 00:00:05.04, start: 0.000000, bitrate: 551 kb/s Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 547 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc (default) Metadata: creation_time : 2010-10-07 15:03:51 handler_name : GPAC ISO Video Handler Please use -q:a or -q:v, -qscale is ambiguous Output #0, avi, to 'out.avi': Metadata: major_brand : avc1 minor_version : 0 compatible_brands: isomavc1 ISFT : Lavf55.33.100 Stream #0:0(und): Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 tbn, 25 tbc (default) Metadata: creation_time : 2010-10-07 15:03:51 handler_name : GPAC ISO Video Handler Stream mapping: Stream #0:0 -> #0:0 (h264 -> mpeg4) Press [q] to stop, [?] for help frame= 126 fps=0.0 q=2.0 Lsize= 2926kB time=00:00:05.04 bitrate=4755.8kbits/s video:2917kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead 0.296020% }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3412> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#3410(undetermined:new): v4l2 crash
by FFmpeg 13 Jul '14

13 Jul '14

#3410: v4l2 crash -------------------------------------+------------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: important | Component: Version: git- | undetermined master | Keywords: v4l2 crash Blocked By: | regression SIGSEGV Reproduced by developer: 0 | Blocking: | Analyzed by developer: 0 -------------------------------------+------------------------------------- v4l2 input crashes here in libswscale if I force uyvy422, this is a regression since a05a44e2 The ffplay crash is not reproducible with valgrind, the crash with ffmpeg is only reproducible with valgrind. {{{ $ valgrind ./ffmpeg_g -f v4l2 -pix_fmt uyvy422 -i /dev/video0 -pix_fmt yuv420p -f null - ==3446== Memcheck, a memory error detector ==3446== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3446== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3446== Command: ./ffmpeg_g -f v4l2 -pix_fmt uyvy422 -i /dev/video0 -pix_fmt yuv420p -f null - ==3446== ffmpeg version N-60842-g72e6913 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 23 2014 19:27:16 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl 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, video4linux2,v4l2, from '/dev/video0': Duration: N/A, start: 1393181634.113993, bitrate: 176947 kb/s Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 768x576, 176947 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc ==3446== Invalid read of size 8 ==3446== at 0x6ADD59F: __GI___strncasecmp_l (in /lib64/libc-2.15.so) ==3446== by 0x6A918A5: ____strtod_l_internal (in /lib64/libc-2.15.so) ==3446== by 0xD1684E: av_strtod (eval.c:98) ==3446== by 0xD17094: parse_primary (eval.c:324) ==3446== by 0xD17B20: parse_factor (eval.c:483) ==3446== by 0xD17D1B: parse_term (eval.c:532) ==3446== by 0xD16DDE: parse_expr (eval.c:556) ==3446== by 0xD17F1C: av_expr_parse (eval.c:673) ==3446== by 0xD18063: av_expr_parse_and_eval (eval.c:710) ==3446== by 0x4CA1F6: config_props (vf_scale.c:256) ==3446== by 0x48E10C: avfilter_config_links (avfilter.c:254) ==3446== by 0x48E0EF: avfilter_config_links (avfilter.c:243) ==3446== Address 0x75a61e0 is 0 bytes inside a block of size 3 alloc'd ==3446== at 0x4C290FE: memalign (in /usr/lib64/valgrind /vgpreload_memcheck-amd64-linux.so) ==3446== by 0x4C291A7: posix_memalign (in /usr/lib64/valgrind /vgpreload_memcheck-amd64-linux.so) ==3446== by 0xD1F229: av_malloc (mem.c:94) ==3446== by 0xD17E65: av_expr_parse (eval.c:650) ==3446== by 0xD18063: av_expr_parse_and_eval (eval.c:710) ==3446== by 0x4CA1F6: config_props (vf_scale.c:256) ==3446== by 0x48E10C: avfilter_config_links (avfilter.c:254) ==3446== by 0x48E0EF: avfilter_config_links (avfilter.c:243) ==3446== by 0x4922EE: avfilter_graph_config (avfiltergraph.c:276) ==3446== by 0x4788B2: configure_filtergraph (ffmpeg_filter.c:901) ==3446== by 0x4832E6: transcode_init (ffmpeg.c:2488) ==3446== by 0x4677C8: main (ffmpeg.c:3413) ==3446== ==3446== Invalid read of size 8 ==3446== at 0x6ADD5A7: __GI___strncasecmp_l (in /lib64/libc-2.15.so) ==3446== by 0x6A918A5: ____strtod_l_internal (in /lib64/libc-2.15.so) ==3446== by 0xD1684E: av_strtod (eval.c:98) ==3446== by 0xD17094: parse_primary (eval.c:324) ==3446== by 0xD17B20: parse_factor (eval.c:483) ==3446== by 0xD17D1B: parse_term (eval.c:532) ==3446== by 0xD16DDE: parse_expr (eval.c:556) ==3446== by 0xD17F1C: av_expr_parse (eval.c:673) ==3446== by 0xD18063: av_expr_parse_and_eval (eval.c:710) ==3446== by 0x4CA1F6: config_props (vf_scale.c:256) ==3446== by 0x48E10C: avfilter_config_links (avfilter.c:254) ==3446== by 0x48E0EF: avfilter_config_links (avfilter.c:243) ==3446== Address 0x75a61e8 is 5 bytes after a block of size 3 alloc'd ==3446== at 0x4C290FE: memalign (in /usr/lib64/valgrind /vgpreload_memcheck-amd64-linux.so) ==3446== by 0x4C291A7: posix_memalign (in /usr/lib64/valgrind /vgpreload_memcheck-amd64-linux.so) ==3446== by 0xD1F229: av_malloc (mem.c:94) ==3446== by 0xD17E65: av_expr_parse (eval.c:650) ==3446== by 0xD18063: av_expr_parse_and_eval (eval.c:710) ==3446== by 0x4CA1F6: config_props (vf_scale.c:256) ==3446== by 0x48E10C: avfilter_config_links (avfilter.c:254) ==3446== by 0x48E0EF: avfilter_config_links (avfilter.c:243) ==3446== by 0x4922EE: avfilter_graph_config (avfiltergraph.c:276) ==3446== by 0x4788B2: configure_filtergraph (ffmpeg_filter.c:901) ==3446== by 0x4832E6: transcode_init (ffmpeg.c:2488) ==3446== by 0x4677C8: main (ffmpeg.c:3413) ==3446== Output #0, null, to 'pipe:': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 768x576, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> rawvideo) Press [q] to stop, [?] for help [null @ 0x743c140] Encoder did not produce proper pts, making some up. ==3446== Invalid read of size 8 ==3446== at 0xD09308: uyvytoyuv420_mmxext (rgb2rgb_template.c:2147) ==3446== by 0xCFED7D: uyvyToYuv420Wrapper (swscale_unscaled.c:287) ==3446== by 0xCC3060: sws_scale (swscale.c:1101) ==3446== by 0x4CAEB4: filter_frame (vf_scale.c:423) ==3446== by 0x48EE59: ff_filter_frame_framed (avfilter.c:1081) ==3446== by 0x48F360: default_filter_frame (avfilter.c:1161) ==3446== by 0x48EE59: ff_filter_frame_framed (avfilter.c:1081) ==3446== by 0x48FF58: ff_filter_frame (avfilter.c:1161) ==3446== by 0x494011: request_frame (buffersrc.c:500) ==3446== by 0x4942AA: av_buffersrc_add_frame_internal (buffersrc.c:181) ==3446== by 0x49463C: av_buffersrc_add_frame_flags (buffersrc.c:106) ==3446== by 0x47D119: decode_video (ffmpeg.c:1835) ==3446== Address 0x420aff9 is not stack'd, malloc'd or (recently) free'd ==3446== ==3446== ==3446== Process terminating with default action of signal 11 (SIGSEGV) ==3446== Access not within mapped region at address 0x420B000 ==3446== at 0xD09308: uyvytoyuv420_mmxext (rgb2rgb_template.c:2147) ==3446== by 0xCFED7D: uyvyToYuv420Wrapper (swscale_unscaled.c:287) ==3446== by 0xCC3060: sws_scale (swscale.c:1101) ==3446== by 0x4CAEB4: filter_frame (vf_scale.c:423) ==3446== by 0x48EE59: ff_filter_frame_framed (avfilter.c:1081) ==3446== by 0x48F360: default_filter_frame (avfilter.c:1161) ==3446== by 0x48EE59: ff_filter_frame_framed (avfilter.c:1081) ==3446== by 0x48FF58: ff_filter_frame (avfilter.c:1161) ==3446== by 0x494011: request_frame (buffersrc.c:500) ==3446== by 0x4942AA: av_buffersrc_add_frame_internal (buffersrc.c:181) ==3446== by 0x49463C: av_buffersrc_add_frame_flags (buffersrc.c:106) ==3446== by 0x47D119: decode_video (ffmpeg.c:1835) ==3446== If you believe this happened as a result of a stack ==3446== overflow in your program's main thread (unlikely but ==3446== possible), you can try to increase the size of the ==3446== main thread stack using the --main-stacksize= flag. ==3446== The main thread stack size used in this run was 8388608. ==3446== ==3446== HEAP SUMMARY: ==3446== in use at exit: 718,853 bytes in 134 blocks ==3446== total heap usage: 2,554 allocs, 2,420 frees, 2,775,626 bytes allocated ==3446== ==3446== LEAK SUMMARY: ==3446== definitely lost: 0 bytes in 0 blocks ==3446== indirectly lost: 0 bytes in 0 blocks ==3446== possibly lost: 2,448 bytes in 9 blocks ==3446== still reachable: 716,405 bytes in 125 blocks ==3446== suppressed: 0 bytes in 0 blocks ==3446== Rerun with --leak-check=full to see details of leaked memory ==3446== ==3446== For counts of detected and suppressed errors, rerun with: -v ==3446== ERROR SUMMARY: 7 errors from 3 contexts (suppressed: 2 from 2) Killed }}} {{{ (gdb) r -f v4l2 -pix_fmt uyvy422 -i /dev/video0 Starting program: /home/cehoyos/test/cehoyos/FFmpeg/ffplay_g -f v4l2 -pix_fmt uyvy422 -i /dev/video0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ffplay version N-60842-g72e6913 Copyright (c) 2003-2014 the FFmpeg developers built on Feb 23 2014 19:27:16 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl 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 Option -pix_fmt is deprecated, use -pixel_format. [New Thread 0x7ffff59eb700 (LWP 3562)] [New Thread 0x7ffff48c8700 (LWP 3563)] [New Thread 0x7ffff3fc6700 (LWP 3564)] Input #0, video4linux2,v4l2, from '/dev/video0':B sq= 0B f=0/0 Duration: N/A, start: 1393181754.236851, bitrate: 176947 kb/s Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 768x576, 176947 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc [New Thread 0x7ffff27bd700 (LWP 3565)] [New Thread 0x7ffff1fbc700 (LWP 3566)] [New Thread 0x7ffff17bb700 (LWP 3567)] [New Thread 0x7ffff0fba700 (LWP 3568)] [New Thread 0x7fffebfff700 (LWP 3569)] [New Thread 0x7fffeb7fe700 (LWP 3570)] [New Thread 0x7fffeaffd700 (LWP 3571)] [New Thread 0x7fffea7fc700 (LWP 3572)] [New Thread 0x7fffe9ffb700 (LWP 3573)] [New Thread 0x7fffe97fa700 (LWP 3574)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff27bd700 (LWP 3565)] 0x0000000000cfaef8 in extract_even_mmxext (count=<optimized out>, dst=0x7fffe4078fa0 "", src=0x7ffff37c6001 "") at libswscale/x86/rgb2rgb_template.c:2147 2147 __asm__ volatile( (gdb) bt #0 0x0000000000cfaef8 in extract_even_mmxext (count=<optimized out>, dst=0x7fffe4078fa0 "", src=0x7ffff37c6001 "") at libswscale/x86/rgb2rgb_template.c:2147 #1 uyvytoyuv420_mmxext (ydst=<optimized out>, udst=0x7fffe4093e80 "", vdst=0x7fffe40aef00 "", src=<optimized out>, width=768, height=576, lumStride=768, chromStride=384, srcStride=1536) at libswscale/x86/rgb2rgb_template.c:2439 #2 0x0000000000cf096e in uyvyToYuv420Wrapper (c=0x7fffe40037a0, src=<optimized out>, srcStride=<optimized out>, srcSliceY=0, srcSliceH=576, dstParam=0x7ffff27bc710, dstStride=0x7ffff27bc6e0) at libswscale/swscale_unscaled.c:287 #3 0x0000000000cb4c51 in sws_scale (c=<optimized out>, srcSlice=srcSlice@entry=0x7ffff27bc800, srcStride=srcStride@entry=0x7ffff27bc7c0, srcSliceY=srcSliceY@entry=0, srcSliceH=576, dst=dst@entry=0x7ffff27bc820, dstStride=0x7ffff27bc7d0) at libswscale/swscale.c:1101 #4 0x00000000004bcaa5 in scale_slice (field=<optimized out>, mul=<optimized out>, h=<optimized out>, sws=<optimized out>, cur_pic=<optimized out>, out_buf=<optimized out>, link=<optimized out>, y=<optimized out>) at libavfilter/vf_scale.c:423 #5 filter_frame (link=link@entry=0x7fffe40033c0, in=0x7fffe400ca80) at libavfilter/vf_scale.c:520 #6 0x0000000000480a4a in ff_filter_frame_framed (link=link@entry=0x7fffe40033c0, frame=0x7ffff37c6000, frame@entry=0x7fffe400ca80) at libavfilter/avfilter.c:1081 #7 0x0000000000481b49 in ff_filter_frame (link=link@entry=0x7fffe40033c0, frame=0x7fffe400ca80) at libavfilter/avfilter.c:1161 #8 0x0000000000485c02 in request_frame (link=0x7fffe40033c0) at libavfilter/buffersrc.c:500 #9 0x0000000000480e2a in ff_request_frame (link=0x7fffe40033c0) at libavfilter/avfilter.c:346 #10 0x0000000000480e94 in ff_request_frame (link=0x7fffe4003660) at libavfilter/avfilter.c:348 #11 0x0000000000480e94 in ff_request_frame (link=link@entry=0x7fffe4003280) at libavfilter/avfilter.c:348 #12 0x0000000000485428 in av_buffersink_get_frame_flags ( ctx=ctx@entry=0x7fffe40026a0, frame=0x7fffe40008c0, flags=0, flags@entry=-469755424) at libavfilter/buffersink.c:138 #13 0x00000000004731b5 in video_thread (arg=0x7ffff3fc7040) at ffplay.c:1972 #14 0x00007ffff6f0ae96 in ?? () from /usr/lib64/libSDL-1.2.so.0 #15 0x00007ffff6f4dcd9 in ?? () from /usr/lib64/libSDL-1.2.so.0 #16 0x00007ffff6ce4e0e in start_thread () from /lib64/libpthread.so.0 #17 0x00007ffff60f82cd in clone () from /lib64/libc.so.6 (gdb) disass $pc-32,$pc+32 Dump of assembler code from 0xcfaed8 to 0xcfaf18: 0x0000000000cfaed8 <uyvytoyuv420_mmxext+152>: mov %r12,%rax 0x0000000000cfaedb <uyvytoyuv420_mmxext+155>: jge 0xcfaf23 <uyvytoyuv420_mmxext+227> 0x0000000000cfaedd <uyvytoyuv420_mmxext+157>: mov -0x20(%rsp),%rax 0x0000000000cfaee2 <uyvytoyuv420_mmxext+162>: pcmpeqw %mm7,%mm7 0x0000000000cfaee5 <uyvytoyuv420_mmxext+165>: psrlw $0x8,%mm7 0x0000000000cfaee9 <uyvytoyuv420_mmxext+169>: movq -0x1e(%rdi,%rax,2),%mm0 0x0000000000cfaeee <uyvytoyuv420_mmxext+174>: movq -0x16(%rdi,%rax,2),%mm1 0x0000000000cfaef3 <uyvytoyuv420_mmxext+179>: movq -0xe(%rdi,%rax,2),%mm2 => 0x0000000000cfaef8 <uyvytoyuv420_mmxext+184>: movq -0x6(%rdi,%rax,2),%mm3 0x0000000000cfaefd <uyvytoyuv420_mmxext+189>: pand %mm7,%mm0 0x0000000000cfaf00 <uyvytoyuv420_mmxext+192>: pand %mm7,%mm1 0x0000000000cfaf03 <uyvytoyuv420_mmxext+195>: pand %mm7,%mm2 0x0000000000cfaf06 <uyvytoyuv420_mmxext+198>: pand %mm7,%mm3 0x0000000000cfaf09 <uyvytoyuv420_mmxext+201>: packuswb %mm1,%mm0 0x0000000000cfaf0c <uyvytoyuv420_mmxext+204>: packuswb %mm3,%mm2 0x0000000000cfaf0f <uyvytoyuv420_mmxext+207>: movntq %mm0,-0xf(%rcx,%rax,1) 0x0000000000cfaf14 <uyvytoyuv420_mmxext+212>: movntq %mm2,-0x7(%rcx,%rax,1) End of assembler dump. (gdb) info all-register rax 0xffffffffffffffff -1 rbx 0x7fffe4093e80 140737019199104 rcx 0x7fffe4078fa0 140737019088800 rdx 0x7fffe40aef00 140737019309824 rsi 0x7ffff37c6000 140737278402560 rdi 0x7ffff37c6001 140737278402561 rbp 0x7fffe40aef00 0x7fffe40aef00 rsp 0x7ffff27bc5c8 0x7ffff27bc5c8 r8 0x600 1536 r9 0x240 576 r10 0x7fffe4079000 140737019088896 r11 0x23f 575 r12 0xfffffffffffffd00 -768 r13 0x600 1536 r14 0x1 1 r15 0x180 384 rip 0xcfaef8 0xcfaef8 <uyvytoyuv420_mmxext+184> eflags 0x10286 [ PF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 st0 -nan(0x7e177f1080117e12) (raw 0xffff7e177f1080117e12) st1 -nan(0x80107f15801e7e1e) (raw 0xffff80107f15801e7e1e) st2 -nan(0x80187e147f107f10) (raw 0xffff80187e147f107f10) st3 -nan(0x13001700150019) (raw 0xffff0013001700150019) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 0 (raw 0x00000000000000000000) st7 -nan(0xff00ff00ff00ff) (raw 0xffff00ff00ff00ff00ff) fctrl 0x37f 895 fstat 0x0 0 ftag 0x95aa 38314 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop 0x0 0 mxcsr 0x1fa8 [ OE PE IM DM ZM OM UM PM ] ymm0 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x95, 0x98, 0x1, 0x0, 0x69, 0x4, 0x2, 0x0, 0x4b, 0x64, 0x0, 0x0, 0x1f, 0xd0, 0x0 <repeats 18 times>}, v16_int16 = {0x9895, 0x1, 0x469, 0x2, 0x644b, 0x0, 0xd01f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x19895, 0x20469, 0x644b, 0xd01f, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x2046900019895, 0xd01f0000644b, 0x0, 0x0}, v2_int128 = {0x0000d01f0000644b0002046900019895, 0x00000000000000000000000000000000}} ymm1 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x61, 0x75, 0x74, 0x6f, 0x0, 0x7f, 0x0, 0x0, 0xe0, 0x1a, 0x0, 0xe4, 0xff, 0x7f, 0x0 <repeats 18 times>}, v16_int16 = {0x7561, 0x6f74, 0x7f00, 0x0, 0x1ae0, 0xe400, 0x7fff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x6f747561, 0x7f00, 0xe4001ae0, 0x7fff, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x7f006f747561, 0x7fffe4001ae0, 0x0, 0x0}, v2_int128 = {0x00007fffe4001ae000007f006f747561, 0x00000000000000000000000000000000}} ymm2 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000000000000000000000, 0x00000000000000000000000000000000}} ymm3 {v8_float = {0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x1, 0x8000000000000000, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0x3f, 0x63, 0x5f, 0x76, 0x5f, 0x63, 0x68, 0x72, 0x5f, 0x0 <repeats 16 times>}, v16_int16 = {0x0, 0x0, 0x0, 0x3ff0, 0x5f63, 0x5f76, 0x6863, 0x5f72, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x0, 0x3ff00000, 0x5f765f63, 0x5f726863, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3ff0000000000000, 0x5f7268635f765f63, 0x0, 0x0}, v2_int128 = {0x5f7268635f765f633ff0000000000000, 0x00000000000000000000000000000000}} ymm4 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x8000000000000000, 0x0, 0x0}, v32_int8 = {0x73, 0x6d, 0x70, 0x74, 0x65, 0x31, 0x37, 0x30, 0x6d, 0x0, 0x49, 0x6e, 0x76, 0x61, 0x6c, 0x69, 0x0 <repeats 16 times>}, v16_int16 = {0x6d73, 0x7470, 0x3165, 0x3037, 0x6d, 0x6e49, 0x6176, 0x696c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x74706d73, 0x30373165, 0x6e49006d, 0x696c6176, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3037316574706d73, 0x696c61766e49006d, 0x0, 0x0}, v2_int128 = {0x696c61766e49006d3037316574706d73, 0x00000000000000000000000000000000}} ymm5 {v8_float = {0x3, 0x3, 0x3, 0x3, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x20, 0x20, 0x0, 0x0}, v32_int8 = {0x40 <repeats 16 times>, 0x0 <repeats 16 times>}, v16_int16 = {0x4040, 0x4040, 0x4040, 0x4040, 0x4040, 0x4040, 0x4040, 0x4040, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x40404040, 0x40404040, 0x40404040, 0x40404040, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x4040404040404040, 0x4040404040404040, 0x0, 0x0}, v2_int128 = {0x40404040404040404040404040404040, 0x00000000000000000000000000000000}} ymm6 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x8000000000000000, 0x8000000000000000, 0x0, 0x0}, v32_int8 = {0x5b <repeats 16 times>, 0x0 <repeats 16 times>}, v16_int16 = {0x5b5b, 0x5b5b, 0x5b5b, 0x5b5b, 0x5b5b, 0x5b5b, 0x5b5b, 0x5b5b, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x5b5b5b5b, 0x5b5b5b5b, 0x5b5b5b5b, 0x5b5b5b5b, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x5b5b5b5b5b5b5b5b, 0x5b5b5b5b5b5b5b5b, 0x0, 0x0}, v2_int128 = {0x5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b, 0x00000000000000000000000000000000}} ymm7 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x20 <repeats 16 times>, 0x0 <repeats 16 times>}, v16_int16 = {0x2020, 0x2020, 0x2020, 0x2020, 0x2020, 0x2020, 0x2020, 0x2020, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x20202020, 0x20202020, 0x20202020, 0x20202020, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x2020202020202020, 0x2020202020202020, 0x0, 0x0}, v2_int128 = {0x20202020202020202020202020202020, 0x00000000000000000000000000000000}} ymm8 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000000000000000000000, 0x00000000000000000000000000000000}} ymm9 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x8000000000000000, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0 <repeats 16 times>}, v16_int16 = {0x0, 0x0, 0xff, 0x0, 0x0, 0xffff, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0x0, 0xff, 0xffff0000, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xff00000000, 0xffffffffffff0000, 0x0, 0x0}, v2_int128 = {0xffffffffffff0000000000ff00000000, 0x00000000000000000000000000000000}} ymm10 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000000000000000000000, 0x00000000000000000000000000000000}} ymm11 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0, 0xff, 0xff, 0x0 <repeats 17 times>}, v16_int16 = {0x0, 0xff00, 0x0, 0x0, 0xff00, 0x0, 0xff00, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0xff000000, 0x0, 0xff00, 0xffff00, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xff000000, 0xffff000000ff00, 0x0, 0x0}, v2_int128 = {0x00ffff000000ff0000000000ff000000, 0x00000000000000000000000000000000}} ymm12 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4, 0x3c, 0x0 <repeats 24 times>}, v16_int16 = {0x0, 0x0, 0x0, 0x3cc4, 0x0 <repeats 12 times>}, v8_int32 = {0x0, 0x3cc40000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3cc4000000000000, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000003cc4000000000000, 0x00000000000000000000000000000000}} ymm13 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x80, 0x59, 0xbc, 0x0 <repeats 24 times>}, v16_int16 = {0x0, 0x0, 0x8000, 0xbc59, 0x0 <repeats 12 times>}, v8_int32 = {0x0, 0xbc598000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xbc59800000000000, 0x0, 0x0, 0x0}, v2_int128 = {0x0000000000000000bc59800000000000, 0x00000000000000000000000000000000}} ymm14 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x8e, 0x85, 0x83, 0xe8, 0xf0, 0x24, 0x53, 0x3c, 0x0 <repeats 24 times>}, v16_int16 = {0x858e, 0xe883, 0x24f0, 0x3c53, 0x0 <repeats 12 times>}, v8_int32 = {0xe883858e, 0x3c5324f0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x3c5324f0e883858e, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000003c5324f0e883858e, 0x00000000000000000000000000000000}} ymm15 {v8_float = {0x0, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x2d, 0x0, 0x0, 0x0}, v32_int8 = {0xc0, 0x9, 0xf2, 0x16, 0xb5, 0xdf, 0x46, 0x40, 0x0 <repeats 24 times>}, v16_int16 = {0x9c0, 0x16f2, 0xdfb5, 0x4046, 0x0 <repeats 12 times>}, v8_int32 = {0x16f209c0, 0x4046dfb5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x4046dfb516f209c0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000004046dfb516f209c0, 0x00000000000000000000000000000000}} }}} The following workaround avoids the crash: {{{ diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c index 96a272c..0a02dd1 100644 --- a/libavdevice/v4l2.c +++ b/libavdevice/v4l2.c @@ -531,7 +531,7 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt) } /* Image is at s->buff_start[buf.index] */ - if (avpriv_atomic_int_get(&s->buffers_queued) == FFMAX(s->buffers / 8, 1)) { + if (1 || avpriv_atomic_int_get(&s->buffers_queued) == FFMAX(s->buffers / 8, 1)) { /* when we start getting low on queued buffers, fall back on copying data */ res = av_new_packet(pkt, buf.bytesused); if (res < 0) { }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3410> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#3413(undetermined:new): invalid read in swscale when converting from rgb24 to yuv420p
by FFmpeg 22 Jun '14

22 Jun '14

#3413: invalid read in swscale when converting from rgb24 to yuv420p -------------------------------------+------------------------------------- Reporter: ubitux | Owner: Type: defect | Status: new Priority: normal | Component: Version: git- | undetermined master | Keywords: Blocked By: | avpicture_alloc Reproduced by developer: 0 | Blocking: | Analyzed by developer: 0 -------------------------------------+------------------------------------- {{{ #include <libavcodec/avcodec.h> #include <libswscale/swscale.h> #define W 320 #define H 240 int main() { AVPicture dst = {{0}}, src = {{0}}; struct SwsContext *sws = sws_getCachedContext(NULL, W, H, PIX_FMT_RGB24, W, H, PIX_FMT_YUV420P, 0, NULL, NULL, NULL); if (!sws) return 1; avpicture_alloc(&src, PIX_FMT_RGB24, W, H); avpicture_alloc(&dst, PIX_FMT_YUV420P, W, H); memset(src.data[0], 0, H * src.linesize[0]); if (sws_scale(sws, (const uint8_t**)src.data, src.linesize, 0, H, dst.data, dst.linesize) < 0) return 1; return 0; } }}} {{{ ☭ valgrind ./scale ==26516== Memcheck, a memory error detector ==26516== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26516== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==26516== Command: ./scale ==26516== ==26516== Invalid read of size 16 ==26516== at 0x442D47: ??? (input.asm:334) ==26516== by 0x40B5A8: swscale (swscale.c:254) ==26516== by 0x40D3E4: sws_scale (swscale.c:1101) ==26516== by 0x40A32A: main (scale.c:19) ==26516== Address 0x8f3dcd4 is 230,388 bytes inside a block of size 230,401 alloc'd ==26516== at 0x4C2ACC0: memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==26516== by 0x4C2ADD7: posix_memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==26516== by 0x452BF9: av_malloc (mem.c:94) ==26516== by 0x451586: av_image_alloc (imgutils.c:210) ==26516== by 0x40A3D5: avpicture_alloc (avpicture.c:57) ==26516== by 0x40A2AA: main (scale.c:16) ==26516== ==26516== ==26516== HEAP SUMMARY: ==26516== in use at exit: 409,728 bytes in 34 blocks ==26516== total heap usage: 46 allocs, 12 frees, 463,488 bytes allocated ==26516== ==26516== LEAK SUMMARY: ==26516== definitely lost: 375,906 bytes in 3 blocks ==26516== indirectly lost: 33,822 bytes in 31 blocks ==26516== possibly lost: 0 bytes in 0 blocks ==26516== still reachable: 0 bytes in 0 blocks ==26516== suppressed: 0 bytes in 0 blocks ==26516== Rerun with --leak-check=full to see details of leaked memory ==26516== ==26516== For counts of detected and suppressed errors, rerun with: -v ==26516== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 3) }}} This might be because avpicture_alloc() calls av_image_alloc() with an align of 1. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3413> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#3428(undetermined:new): WMV file has wrong length detected by ffprobe/ffmpeg
by FFmpeg 21 Jun '14

21 Jun '14

#3428: WMV file has wrong length detected by ffprobe/ffmpeg --------------------------------------+---------------------------------- Reporter: boose | 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: Other players report length correctly as 30:38, ffprobe/ffmpeg seem to think it is 21:36 How to reproduce: {{{ boose@Cid:~/ffmpeg-2.1.3-64bit-static$ ./ffprobe 08\ Christian\ Humanism.wmv ffprobe version 2.1.3- http://johnvansickle.com/ffmpeg/ Copyright (c) 2007-2013 the FFmpeg developers built on Jan 22 2014 19:50:14 with gcc 4.8 (Debian 4.8.2-14) configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable- libx264 --enable-libspeex --enable-libvorbis --enable-libvpx --enable- libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable- libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --disable-ffserver libavutil 52. 48.101 / 52. 48.101 libavcodec 55. 39.101 / 55. 39.101 libavformat 55. 19.104 / 55. 19.104 libavdevice 55. 5.100 / 55. 5.100 libavfilter 3. 90.100 / 3. 90.100 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 [asf @ 0x32cbd40] Estimating duration from bitrate, this may be inaccurate Input #0, asf, from '08 Christian Humanism.wmv': Metadata: [...] WM/EpisodeID : Lect.08 Christian Humanism WM/EpisodeNumber: 8 Duration: 00:21:36.74, start: 0.000000, bitrate: 2128 kb/s Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 128 kb/s Stream #0:1: Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 640x480, 2000 kb/s, SAR 1:1 DAR 4:3, 29.97 tbr, 1k tbn, 1k tbc Stream #0:2: Video: mjpeg, yuvj444p(pc), 419x563 [SAR 96:96 DAR 419:563], 90k tbr, 90k tbn, 90k tbc Metadata: title : comment : Other Stream #0:3: Video: mjpeg, yuvj444p(pc), 419x563 [SAR 96:96 DAR 419:563], 90k tbr, 90k tbn, 90k tbc Metadata: comment : Cover (front) boose@Cid:~/ffmpeg-2.1.3-64bit-static$ }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3428> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#3382(ffmpeg:new): Add severity level to ffmpeg log formatting
by FFmpeg 21 Jun '14

21 Jun '14

#3382: Add severity level to ffmpeg log formatting --------------------------------+--------------------------------------- Reporter: abc123 | Type: enhancement Status: new | Priority: normal Component: ffmpeg | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------+--------------------------------------- Summary of the bug: FFmpeg CLI only uses terminal colors to distinguish between different categories of logging messages. If console colors are disabled or stderr redirected, it becomes impossible to determine the severity of a log event. How to reproduce: {{{ % ffmpeg -i input ... output ffmpeg version built on ... [rawvideo @ 0x9f8c640] Encoder did not produce proper pts, making some up. }}} I propose changing the format string to produce something like this: [rawvideo @ 0x9f8c640] [WARNING] Encoder did not produce proper pts, making some up. Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3382> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#3400(avcodec:new): libavcodec: cavs decoder bug when decoding multi-sliced chinese avs streams
by FFmpeg 09 Jun '14

09 Jun '14

#3400: libavcodec: cavs decoder bug when decoding multi-sliced chinese avs streams -------------------------------------+------------------------------------- Reporter: coolfat | Type: defect Status: new | Priority: normal Component: avcodec | Version: Keywords: libavcodec | unspecified cavs | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 1 | -------------------------------------+------------------------------------- Summary of the bug: libavcodec: cavs decoder bug when decoding multi-sliced chinese avs streams How to reproduce: {{{ % ffmpeg -i akiyo_cif.avs akiyo_cif.yuv avconv version 9_beta3, Copyright (c) 2000-2012 the Libav developers built on Jan 15 2014 09:45:40 with gcc 4.3.3 (Ubuntu 4.3.3-5ubuntu4) Illegal intra prediction mode Last message repeated 13 times [cavs @ 0x9cf0ec0] illegal intra chroma pred mode Last message repeated 4 times [cavsvideo @ 0x9cef000] max_analyze_duration reached [cavsvideo @ 0x9cef000] Estimating duration from bitrate, this may be inaccurate Input #0, cavsvideo, from '/home/samba_share/hfxing/akiyo_cif.avs': Duration: N/A, bitrate: N/A Stream #0.0: Video: cavs, yuv420p, 352x288, 25 fps, 25 tbr, 25 tbn, 25 tbc File '/home/samba_share/hfxing/akiyo_cif.yuv' already exists. Overwrite ? [y/N] y Output #0, rawvideo, to '/home/samba_share/hfxing/akiyo_cif.yuv': Metadata: encoder : Lavf54.20.0 Stream #0.0: Video: rawvideo, yuv420p, 352x288, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (cavs -> rawvideo) Press ctrl-c to stop encoding Illegal intra prediction mode Last message repeated 13 times [cavs @ 0x9cf0ec0] illegal intra chroma pred mode Last message repeated 4 times [cavs @ 0x9cf0ec0] position out of block bounds at pic 6 MB(3,9) Illegal intra prediction mode [cavs @ 0x9cf0ec0] position out of block bounds at pic 6 MB(6,9) [cavs @ 0x9cf0ec0] position out of block bounds at pic 6 MB(8,12) .......... }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3400> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#3402(avcodec:new): dpx parser is more strict than the dpx decoder
by FFmpeg 29 May '14

29 May '14

#3402: dpx parser is more strict than the dpx decoder --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Keywords: dpx Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- http://thread.gmane.org/gmane.comp.video.ffmpeg.libav.user/12337/focus=12504 The dpx sample fate-suite/dpx/lighthouse_rgb48.dpx has an incorrect filesize written in the header, works fine with the lavc decoder, the lavc parser cuts the file. {{{ $ cat fate-suite/dpx/lighthouse_rgb48.dpx | ./ffmpeg -f image2pipe -vcodec dpx -i - out.png ffmpeg version N-60762-g3edc3b1 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 20 2014 09:30:22 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl 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 [dpx @ 0x2ad3b20] Overread buffer. Invalid header? Input #0, image2pipe, from 'pipe:': Duration: N/A, bitrate: N/A Stream #0:0: Video: dpx, rgb48be, 768x512, 25 tbr, 25 tbn, 25 tbc Output #0, image2, to 'out.png': Metadata: encoder : Lavf55.33.100 Stream #0:0: Video: png, rgb48be, 768x512, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (dpx -> png) [dpx @ 0x2ad3b20] Overread buffer. Invalid header? Error while decoding stream #0:0: Invalid data found when processing input pipe:: Input/output error frame= 0 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A video:0kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -inf% Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/3402> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1