December 2019 - FFmpeg-trac - lists.ffmpeg.org

#8408(undetermined:new): -vf unsharp=6 on a jpg file causes a segfault with ffmpeg and ffplay
by FFmpeg 03 Dec '19

03 Dec '19

#8408: -vf unsharp=6 on a jpg file causes a segfault with ffmpeg and ffplay -------------------------------------+------------------------------------- Reporter: tjackson | 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: ffmpeg and ffplay crash with -vf unsharp=6 How to reproduce: {{{ % ffmpeg -i test.jpg -vf unsharp=6 test.png % ffplay -vf unsharp=6 test.jpg ffmpeg version git-2019-11-30-e5db2e9 built on Sun 01 Dec 2019 01:08:08 AM MST }}} I was somewhat blindly playing with the unsharp filter and I found a reproducible crash. I rebuilt my SDL with debug symbols but there might be some stuff missing with ffmpeg_g. I'll attach gdb logs of the crash with ffplay_g and ffmpeg_g. I'd prefer not to attach the image, but here's some ffprobe output: Input #0, image2, from '/home/tod/Pictures/bz5057-01-600x891.jpg': Duration: 00:00:00.04, start: 0.000000, bitrate: 73946 kb/s Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 600x891 [SAR 1:1 DAR 200:297], 25 tbr, 25 tbn, 25 tbc I can test whatever you like. Thanks, Tod -- Ticket URL: <https://trac.ffmpeg.org/ticket/8408> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

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

03 Dec '19

#3356: feature request: Segment HLS streams on SCTE 35 markers -------------------------------------+------------------------------------- Reporter: adamscybot | Owner: Type: enhancement | Status: open Priority: wish | Component: | undetermined Version: git-master | Resolution: Keywords: hls bounty | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Brainiarc7): Replying to [comment:21 jamesdarcy]: > I am very interested in the solution for this issue and would be willing to add an additional bounty on this issue for AUD $300. > > I will want to be able to use this from within an existing c++ that uses ffmpeg libraries. I imagine that that is not an issue. > > James I'll top this up with 600 AUD. Getting the HLS and DASH muxers to signal the appropriate SCTE35 CUEs, as shown in this example would be a good start: https://docs.aws.amazon.com/mediaconvert/latest/ug/sample-manifest-scte-35 -enhanced-ad-markers.html How can one open a bounty on this? -- Ticket URL: <https://trac.ffmpeg.org/ticket/3356#comment:32> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#7949(undetermined:new): libopus ocl=downmix fails
by FFmpeg 03 Dec '19

03 Dec '19

#7949: libopus ocl=downmix fails -------------------------------------+------------------------------------- Reporter: omniplex | Type: | enhancement Status: new | Priority: normal Component: | Version: 4.1 undetermined | Keywords: OPUS | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: unlike libtheora the libopus default [http://ffmpeg.org/ffmpeg-codecs.html#libopus -mapping_family -1] does not permit [https://ffmpeg.org/ffmpeg-utils.html#channel-layout-syntax ocl=downmix]. How to reproduce: {{{ % ffmpeg -i input -vn -filter:a aresample=48000:resampler=soxr:precision=28:ocl=downmix:cheby=1:matrix_encoding=dolby:tsf=s32p -c:a libopus -b:a 25KiB output ffmpeg version 4.1.3 built with gcc 8.3.1 (GCC) 20190414 }}} The same command with [http://ffmpeg.org/ffmpeg-codecs.html#libopus -mapping_family 255] works. Maybe it is only me, but I expected [https://ffmpeg.org/ffmpeg-utils.html #channel-layout-syntax ocl=downmix] to work for ordinary MP3 stereo input while upgrading a script from VP8/libtheora to VP9/libopus. It's no bug, but had a [https://en.wikipedia.org/wiki/Principle_of_least_astonishment high astonishment factor]. -- Ticket URL: <https://trac.ffmpeg.org/ticket/7949> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#6538(ffmpeg:new): Issue with RTMP:// streams
by FFmpeg 02 Dec '19

02 Dec '19

#6538: Issue with RTMP:// streams --------------------------------+--------------------------------------- Reporter: max79 | Type: defect Status: new | Priority: critical Component: ffmpeg | Version: unspecified Keywords: rtmp | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------+--------------------------------------- Problem with "LAV Splitter Source[v0.70.2]", after metadata change playback stop for all RTMP://-streams. Example: rtmp://wse.planeta-online.tv:1935/live/channel_13 -- Ticket URL: <https://trac.ffmpeg.org/ticket/6538> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#6654(undetermined:new): AAC-file stay on pause through LAVSplitterSource right after start.
by FFmpeg 02 Dec '19

02 Dec '19

#6654: AAC-file stay on pause through LAVSplitterSource right after start. -------------------------------------+------------------------------------- Reporter: max79 | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Example: [https://www.dropbox.com/s/iyr9tsr8pfx056z/sample.aac?dl=0] -- Ticket URL: <https://trac.ffmpeg.org/ticket/6654> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#7724(ffmpeg:new): [FFmpeg-vaapi] HEVC 4K/FHD to AVC 4K/FHD transcoding failed
by FFmpeg 02 Dec '19

02 Dec '19

#7724: [FFmpeg-vaapi] HEVC 4K/FHD to AVC 4K/FHD transcoding failed -------------------------------------+------------------------------------- Reporter: andreyor | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git- Keywords: ffmpeg- | master vaapi | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- How to reproduce: {{{ ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i <crowd_run_3840x2160_500_50.2160p30_500_40M.265> -frames 500 -c:v h264_vaapi -b:v 25000k -minrate:v 25000k -maxrate:v 25000k -compression_level 4 -g 256 -bf 2 0001_4K02_1_0.h264 }}} ffmpeg version N-93001-g87c165c237 Output: {{{ [hevc @ 0x55c5541d4180] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, hevc, from '/msdk/MEDIASDK_STREAMS/_System_Validation/performance/set001/crowd_run_3840x2160_500_50.2160p30_500_40M.265': Duration: N/A, bitrate: N/A Stream #0:0: Video: hevc (Main), yuv420p(tv), 3840x2160, 30 fps, 30 tbr, 1200k tbn, 30 tbc Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_vaapi)) Press [q] to stop, [?] for help frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' Error reinitializing filters! Failed to inject frame into filter network: Function not implemented Error while processing the decoded data for stream #0:0 Conversion failed! }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/7724> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

Re: [FFmpeg-trac] #2786(avformat:reopened): last packet of TTA stream in Matroska isn't decoded correctly
by FFmpeg 02 Dec '19

02 Dec '19

#2786: last packet of TTA stream in Matroska isn't decoded correctly ------------------------------------+------------------------------------ Reporter: jamal | Owner: Type: defect | Status: reopened Priority: normal | Component: avformat Version: git-master | Resolution: Keywords: mkv tta | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+------------------------------------ Comment (by mkver): When I remux inside.tta with MKVToolNix, the TimestampScale is by default choosen so small that one can represent the timestamps sample-accurately. In this case the md5 is correct and no decoding error exists. mkvmerge stores the information about the length twice in the file: Once in Info and once in a BlockDuration element (the last frame is written as BlockGroup, not as SimpleBlock). It is the duration in the Info element (that gets included in the extradata) that matters. The BlockDuration element gets exported, but it seems to be ignored by the decoder. Which is a shame because the duration in Info is not per-track, so one automatically has a problem when the file contains more than one track. -- Ticket URL: <https://trac.ffmpeg.org/ticket/2786#comment:13> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0