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

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 11 Feb '18

11 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by tmm1): Correct, the sample from #4544 does not contain SSR. I thought it was the same as this issue but I was mistaken. That bug has since been resolved. The VasHD.mpg sample I provided above was captured in Singapore, where most of the OTA channels have aac tracks that ffmpeg reports as being SSR. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 11 Feb '18

11 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by cehoyos): Even more so as you have already confirmed a year ago that the sample does not contain SSR audio... -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 11 Feb '18

11 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by cehoyos): Why do you think that the sample from ticket #4544 contains SSR audio? Even more so as apparently no real-world sample exist. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 11 Feb '18

11 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by tmm1): Here's another sample: https://s3.amazonaws.com/tmm1/VasHD.mpg -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 10 Feb '18

10 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by cehoyos): I suspect none of the samples here are actually SSR, samples are in http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_20… /mpeg4audio-conformance/compressedMp4/ and show `Audio object type 3 is not implemented` as error message. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1693(avcodec:new): AAC Scalable Sample Rate (SSR)
by FFmpeg 10 Feb '18

10 Feb '18

#1693: AAC Scalable Sample Rate (SSR) ------------------------------------+----------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by tmm1): According to https://lists.libav.org/pipermail/ffmpeg- devel/2008-July/049282.html, there was an implementation of SSR that never made it to master: The code for LTP and SSR is still in the Summer of Code repository for anyone who is interested in working on either of those features in the future. And according to https://en.wikipedia.org/wiki/MPEG-4_Part_3#AAC-SSR: MPEG-4 AAC-SSR is very similar to ATRAC and ATRAC-3. So the existing atrac and atrac3 decoders might be useful as well. The SoC repo mentioned is available via: svn co svn://svn.mplayerhq.hu/soc cd aac The SSR implementation is behind a -DAAC_SSR compile flag, and disabled by default with the following comment: AAC SSR (Scalable Sample Rate) is currently not working, and therefore not compiled in. SSR files play without crashing but produce audible artifacts that seem to be related to EIGHT_SHORT_SEQUENCE windows. It seems mostly complete, though it will definitely take some work to port the changes over to master. -- Ticket URL: <https://trac.ffmpeg.org/ticket/1693#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#6999(avfilter:new): Filter "aphasemeter" not working in latest FFmpeg version
by FFmpeg 09 Feb '18

09 Feb '18

#6999: Filter "aphasemeter" not working in latest FFmpeg version -------------------------------------+------------------------------------- Reporter: BlackScreen | Type: defect Status: new | Priority: normal Component: avfilter | Version: git- Keywords: aphasemeter | master filter | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: The filter "aphasemeter" is not working. How to reproduce: {{{ ffmpeg -hide_banner -i "Test.wav" -filter_complex "[0:a] aphasemeter=s=hd720:rate=50:mpc=cyan, format=yuv420p [v]" -map "[v]" -map 0:a -r 50 -vcodec libx264 -s 1280x720 -pix_fmt yuv420p -preset slow -crf 20 -profile:v main -level 4.0 -acodec aac -ab 192k -ac 2 "Test_Phase.mp4" }}} ffmpeg version N-89925-gd4967c04e0 built with gcc 7.3.0 (Rev1, Built by MSYS2 project) -- Ticket URL: <https://trac.ffmpeg.org/ticket/6999> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#6626(undetermined:new): ff_vdpau_common_init writes past the end of av_alloc_vdpaucontext memory
by FFmpeg 08 Feb '18

08 Feb '18

#6626: ff_vdpau_common_init writes past the end of av_alloc_vdpaucontext memory -------------------------------------+------------------------------------- Reporter: aaronp24 | 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:''' libavcodec writes past the end of data it allocated, when mplayer calls `ff_vdpau_common_init()` without calling `av_vdpau_bind_context()` '''How to reproduce:''' {{{ % valgrind mplayer -vc ffh264vdpau <any H.264 video> ffmpeg version 1:3.3.3-2 from Arch Linux }}} '''Details:''' I'm looking into a bug where `mplayer -vc ffh264vdpau` causes libavcodec to write past the end of an allocation and corrupt data in the vdpau driver. According to Valgrind, {{{ VO: [vdpau] 1280x536 => 1280x536 H.264 VDPAU acceleration ==19159== Invalid write of size 1 ==19159== at 0xAF0326F: ff_vdpau_common_init (vdpau.c:145) ==19159== by 0xAEA9B89: setup_hwaccel (utils.c:1100) ==19159== by 0xAEA9B89: ff_get_format (utils.c:1165) ==19159== by 0xAB4C365: get_pixel_format.isra.6 (h264_slice.c:864) ==19159== by 0xAB4D1D2: h264_init_ps (h264_slice.c:1102) ==19159== by 0xAB4D1D2: h264_field_start.isra.7 (h264_slice.c:1385) ==19159== by 0xAB520B7: ff_h264_queue_decode_slice (h264_slice.c:2091) ==19159== by 0xAB55BBE: decode_nal_units (h264dec.c:674) ==19159== by 0xAB55BBE: h264_decode_frame (h264dec.c:1016) ==19159== by 0xAEA58AD: avcodec_decode_video2 (utils.c:2275) ==19159== by 0x334BB2: ??? (in /usr/bin/mplayer) ==19159== by 0x262000: ??? (in /usr/bin/mplayer) ==19159== by 0x1B2A57: ??? (in /usr/bin/mplayer) ==19159== by 0x1B4A8D: ??? (in /usr/bin/mplayer) ==19159== by 0x1B8A06: ??? (in /usr/bin/mplayer) ==19159== Address 0x2701c8c8 is 16 bytes after a block of size 760 alloc'd ==19159== at 0x4C2E2A6: memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==19159== by 0x4C2E3E2: posix_memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==19159== by 0xBF640FB: av_malloc (mem.c:87) ==19159== by 0xBF642C9: av_mallocz (mem.c:224) ==19159== by 0x332D7C: ??? (in /usr/bin/mplayer) ==19159== by 0x333CEA: ??? (in /usr/bin/mplayer) ==19159== by 0x333F1A: ??? (in /usr/bin/mplayer) ==19159== by 0x335656: ??? (in /usr/bin/mplayer) ==19159== by 0xAEA9AF1: ff_get_format (utils.c:1140) ==19159== by 0xAB4C365: get_pixel_format.isra.6 (h264_slice.c:864) ==19159== by 0xAB4D1D2: h264_init_ps (h264_slice.c:1102) ==19159== by 0xAB4D1D2: h264_field_start.isra.7 (h264_slice.c:1385) ==19159== by 0xAB520B7: ff_h264_queue_decode_slice (h264_slice.c:2091) }}} I tracked down the problem to mplayer doing this: {{{ avctx->hwaccel_context = vdpc = av_alloc_vdpaucontext(); }}} where `av_alloc_vdpaucontext()` does this: {{{ return av_mallocz(sizeof(AVVDPAUContext)); }}} However, `ff_vdpau_common_init()` casts the `hwaccel_context` pointer to a `VDPAUHWContext*`, which is a larger structure that contains an `AVVDPAUContext` as its first element. When this function tries to write the `reset` field, it writes past the end of the data allocated by `av_alloc_vdpaucontext()`. {{{ hwctx->reset = 0; }}} It looks like there is code in `av_vdpau_bind_context()` to reallocate this structure to the larger size: {{{ VDPAUHWContext *hwctx; if (av_reallocp(&avctx->hwaccel_context, sizeof(*hwctx))) return AVERROR(ENOMEM); }}} However, mplayer doesn't call this function, so the realloc never happens. According to the git history, there used to be a call to `av_vdpau_bind_context()` from `vdpau_alloc()` (called from `vdpau_init()`) but Mark Thompson removed that code in commit e462ace84b92e54d2a5fa651d6469aefe0f1efbf. What is the proper fix here? Should mplayer be calling `av_vdpau_bind_context()`, or should `av_alloc_vdpaucontext()` be allocating enough space up front? -- Ticket URL: <https://trac.ffmpeg.org/ticket/6626> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#7010(undetermined:new): Error writing trailer of icecast://source:password@server broken pipe
by FFmpeg 07 Feb '18

07 Feb '18

#7010: Error writing trailer of icecast://source:password@server broken pipe -------------------------------------+------------------------------------- Reporter: Aporie | 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 launching the server from the script, it works for a while and after a moment (~30h) it crashes with the following error. How to reproduce: {{{ ./ffmpeg -f concat -safe 0 -i stream/stream_list.txt 2> stream/log.txt \ -acodec libopus -b:a 64k \ -vcodec libvpx -b:v 500K -f webm -crf 25 -framerate 30 -g 5 -keyint_min 5 -vf scale=640:360 -maxrate 5000k -bufsize 6M -content_type video/webm \ -loop 365 \ icecast://source:password@server/live.webm & ffmpeg version 3.4-static built on centos-release-6-9.el6.12.3.x86_64 }}} Getting the following error : Error writing trailer of icecast://source:password@server:8000/live.webm: Broken pipe frame=2384595 fps= 13 q=0.0 Lsize= 6392545kB time=30:56:18.81 bitrate= 470.2kbits/s dup=0 drop=400436 speed=0.605x video:5736635kB audio:699652kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Exiting normally, received signal 15. -- Ticket URL: <https://trac.ffmpeg.org/ticket/7010> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#7009(ffmpeg:new): RTMP handshake problem
by FFmpeg 07 Feb '18

07 Feb '18

#7009: RTMP handshake problem --------------------------------+-------------------------------------- Reporter: gyk | Type: defect 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: When FFmpeg connects to RTMP server via digest ("complex") handshake, FFmpeg takes inconsistent ways at the step of sending C2: If it is a publisher, it sends C2 as an echo of S1, OTOH if it's a subscriber, it creates a new packet of C2 consisting of 1504B random-data and 32B signature. In my option the latter one is the expected behavior, while the formal one is only correct in the context of simple handshake. The code shows that publishing and subscribing fall into different branches from this line: https://github.com/FFmpeg/FFmpeg/blob/release/3.4/libavformat/rtmpproto.c#L…. And RTMP publishing feature was introduced in https://github.com/FFmpeg/FFmpeg/commit/6bf22e18d1357f11048902e2c5ac9f814cd…. Although the official RTMP specification obviously lacks a section on digest handshaking, I have checked several open source implementations like nginx-rtmp, Red5 and SRS, and they all take the random-data-and- signature way. -- Ticket URL: <https://trac.ffmpeg.org/ticket/7009> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1