June 2021 - FFmpeg-trac - lists.ffmpeg.org

#9021(avformat:new): mkv: DATE_RELEASED should behave as TDRL tag in ID3
by FFmpeg 01 Jun '21

01 Jun '21

#9021: mkv: DATE_RELEASED should behave as TDRL tag in ID3 -----------------------------------+-------------------------------------- Reporter: malaterre | Type: defect Status: new | Priority: normal Component: avformat | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+-------------------------------------- Summary of the bug: How to reproduce: {{{ $ wget 'https://github.com/Matroska-Org/matroska-test- files/raw/8adb681ec6bac497f69757e6ae4935dbf21945b2/test_files/test1.mkv' $ ffmpeg -i test1.mkv test1.mp4 }}} The output file `test1.mp4` should contains an ID3 TDRL tag with value `2010`. Matroska documentation: * https://www.matroska.org/technical/tagging.html#temporal-information ref: {{{ $ ffmpeg -version ffmpeg version N-100132-g53b4550bdd Copyright (c) 2000-2020 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --prefix=/home/mathieu/ffmpeg_build --pkg-config- flags=--static --extra-cflags=-I/home/mathieu/ffmpeg_build/include --extra-ldflags=-L/home/mathieu/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/mathieu/bin --enable-gpl --enable-gnutls --enable- libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable- libmp3lame --enable-libopus --disable-libsvtav1 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree libavutil 56. 61.100 / 56. 61.100 libavcodec 58.114.100 / 58.114.100 libavformat 58. 64.100 / 58. 64.100 libavdevice 58. 11.103 / 58. 11.103 libavfilter 7. 91.100 / 7. 91.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 libpostproc 55. 8.100 / 55. 8.100 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9021> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#9237(undetermined:new): HLS dont make chunks from some UDP streams
by FFmpeg 01 Jun '21

01 Jun '21

#9237: HLS dont make chunks from some UDP streams -------------------------------------+------------------------------------- Reporter: krs_vital | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- file for example (saved from UDP stream): https://mycloud.g-service.ru:4430/s/4ts4krK2VS9Lh81 ffmpeg version N-102493-g7ce0f24 Copyright (c) 2000-2021 the FFmpeg developers command: ffmpeg -re -i ./Lider.ts -sn -dn -c:v copy -c:a aac -hls_allow_cache 0 -hls_list_size 6 -hls_time 6 -hls_flags delete_segments+omit_endlist -map 0 -ignore_unknown -strftime 1 -hls_segment_filename /var/db/stream_Lider.ts /var/db/Lider.m3u8 cat /var/db/Lider.m3u8 #EXTM3U #EXT-X-VERSION:3 #EXT-X-ALLOW-CACHE:NO #EXT-X-TARGETDURATION:28 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:27.720000, /ts/Lider/stream_Lider.ts P.S: +split_by_time option don't take any results -- Ticket URL: <https://trac.ffmpeg.org/ticket/9237> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#6279(ffmpeg:new): can't request rgb24 (uvc over dshow, unknown compression type)
by FFmpeg 01 Jun '21

01 Jun '21

#6279: can't request rgb24 (uvc over dshow, unknown compression type) --------------------------------+-------------------------------------- Reporter: Djfe | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------+-------------------------------------- ffmpeg doesn't seem to know some of the color space id's that dshow uses. In particular the rgb24 color space: "[dshow @ 0000000000756320] unknown compression type 0xE436EB7D min s=1920x1080 fps=15 max s=1920x1080 fps=59.9999" (I provided a log output, containing more similar lines) A quick google search for the id (0xE436EB7D) in question reveals, that it represents rgb24: https://github.com/opencv/opencv/blob/master/modules/videoio/test/test_four… I bet ffmpeg doesn't know the other RGB GUIDs either, but I can't verify it, since my device only supports outputting in those two color spaces. I'm unsure if it is allowed to simply take the information from the linked opencv file (regarding the opencv license (vs LGPL)) though. But it would be nice if other GUIDs apart from rgb could be "imported" into ffmpeg's knowledge as well. But now to the interesting part: is it enough if ffmpeg knows, that the data is of color space rgb24, or not? until someone finds the time: I'm looking forward to rgb24 support for uvc over dshow :) (maybe that will give you some motivation ^^) The reason being, that I'm recording to qtrle (lossless, but only rgb color space). Asking the grabber to give me rgb avoids unneccessary color space conversion on both sides. PS: I'm unsure if the type of this bug report is a defect or an enhancement, feel free to correct it, if you think it isn't a defect ;) -- Ticket URL: <https://trac.ffmpeg.org/ticket/6279> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6