October 2022 - FFmpeg-trac - lists.ffmpeg.org

#9954(ffmpeg:new): Can't decode Bink 2 videos
by FFmpeg 03 Oct '22

03 Oct '22

#9954: Can't decode Bink 2 videos ---------------------------------+--------------------------------------- Reporter: biast12 | Type: enhancement Status: new | Priority: normal Component: ffmpeg | Version: unspecified Keywords: Bink2 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+--------------------------------------- Summary of the bug: It doesn't wanna decode Bink 2 videos How to reproduce: {{{ ffmpeg -i 1.bik -c:v libvpx -b:v 1M -c:a libvorbis -f webm output.wbm }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9954> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 19

Re: [FFmpeg-trac] #959(avcodec:closed): Media 100 codec support.
by FFmpeg 03 Oct '22

03 Oct '22

#959: Media 100 codec support. -------------------------------------+----------------------------------- Reporter: Galane | Owner: (none) Type: enhancement | Status: closed Priority: wish | Component: avcodec Version: git-master | Resolution: fixed Keywords: mjpeg | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Changes (by Carl Eugen Hoyos): * keywords: dtPA dtnt dtmt => mjpeg * component: undetermined => avcodec Comment: Fixed in 4b6b75c7526e644e3516a79f0379b2e2f75a054d and the subsequent commit. -- Ticket URL: <https://trac.ffmpeg.org/ticket/959#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #1726(undetermined:closed): Mono TrueHD file no longer decodes (and was not lossless)
by FFmpeg 02 Oct '22

02 Oct '22

#1726: Mono TrueHD file no longer decodes (and was not lossless) -------------------------------------+------------------------------------- Reporter: Carl Eugen | Owner: (none) Hoyos | Type: defect | Status: closed Priority: important | Component: | undetermined Version: git-master | Resolution: fixed Keywords: thd | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Oh and also cosmetic, but ffmpeg -h encoder=truehd should print Supported channel layouts: '''mono''' stereo 5.0 5.1 like ffmpeg -h encoder=opus -- Ticket URL: <https://trac.ffmpeg.org/ticket/1726#comment:16> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#9197(undetermined:new): DNG - aspect ratio suddely changes mid-clip
by FFmpeg 02 Oct '22

02 Oct '22

#9197: DNG - aspect ratio suddely changes mid-clip -------------------------------------+------------------------------------- Reporter: Eugene | 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: In a DNG (image2) -> H.264 (libx264) transcode, the output aspect ratio and frame alignment suddenly changes around frame 12 First 12 frames (as expected, but off color): [[Image(https://i.imgur.com/83Fs2Ya.png)]] Frames 13 onwards (layout distorted): [[Image(https://i.imgur.com/tvD8K2N.png)]] How to reproduce: Simple repro (25 frames, all identical): https://www.dropbox.com/s/556rltwsukogc4q/ffmpeg-repro.tgz?dl=0 {{{ffmpeg -stats -f image2 -start_number 0 -i D001_C001_20200907_R0%04d.dng -f mp4 -vcodec libx264 -y -s 1280x720 -pix_fmt yuv420p out.mp4}}} Tested with ffmpeg 4.2, 4.4 and 4.5-dev (git-2021-03-20-c361fa9), also the same result with a different output encoder and format. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9197> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#5294(trac:new): "Forgot password" should require EITHER email or username, not both
by FFmpeg 01 Oct '22

01 Oct '22

#5294: "Forgot password" should require EITHER email or username, not both ---------------------------------+--------------------------------------- Reporter: teo8976 | Type: defect Status: new | Priority: normal Component: trac | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+--------------------------------------- At https://trac.ffmpeg.org/reset_password you are required to enter your username AND password. That's retarded. If you forget your username, you are fucked. If you remember your username but are not sure which email you used, you are fucked. Decent sites either let you enter whichever you want, or they only require the email (the former option is obviously better). -- Ticket URL: <https://trac.ffmpeg.org/ticket/5294> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#9953(avfilter:new): Issues playing some files in 5.1.x (regression for yuv444p videos on x86 architecture?)
by FFmpeg 01 Oct '22

01 Oct '22

#9953: Issues playing some files in 5.1.x (regression for yuv444p videos on x86 architecture?) -------------------------------------+------------------------------------- Reporter: Leon Styhre | Type: defect Status: new | Priority: important Component: avfilter | Version: | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Hi! It seems as if there was a regression introduced in the 5.1.x release as some files won't play properly when using avfilter_graph_create_filter() on x86 processors. I don't have conclusive information of exactly when this happens, but it seems as if it's possibly only affecting yuv444p files as yuv420p works fine according to my testing. I've seen the problem on Linux, Windows and macOS x86. macOS M1/ARM works fine though. You can find the relevant code for my application here: https://gitlab.com/es-de/emulationstation-de/-/blob/master/es- core/src/components/VideoFFmpegComponent.cpp The problematic function is VideoFFmpegComponent::setupVideoFilters() where the video width seems to trigger the issue. When using FFmpeg 4.4, or 5.0.1 it works fine but with 5.1.1 and 5.1.2 the video output is garbled. If I manually add 16 pixels to the video width for the problematic videos and pass that to avfilter_graph_create_filter(), then the rendering will look almost correct but a bit blurry as I guess something is slightly off with the channel alignment? Here is one problematic video file that you can test with: https://es-de.org/temp/grdians.mp4 Here's an example image of the problem: https://es-de.org/temp/video_issues.png And here's what it looks like with the workaround applied: https://es-de.org/temp/video_workaround.png Note that these are just screenshots from a virtual machine so not direct output from the application, it's just meant as an illustration of the problem. As the problem occurs on macOS x86 and not on macOS M1/ARM I guess this is somehow restricted to the x86 architecture? I also tried building FFmpeg from the master branch (last commit b0c7352cd494c88d33f032be60b5e1c4e8b092a0) and it's the same problem as in the stable releases. This is a pretty serious issues as it makes some files unplayable. The workaround mentioned above is not a feasible solution for my application as I'm not sure under what circumstances the issue occurs and there are some adverse side effects as well. Thanks in advance! -- Ticket URL: <https://trac.ffmpeg.org/ticket/9953> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

Re: [FFmpeg-trac] #959(undetermined:closed): Media 100 codec support.
by FFmpeg 01 Oct '22

01 Oct '22

#959: Media 100 codec support. -------------------------------------+------------------------------------- Reporter: Galane | Owner: (none) Type: enhancement | Status: closed Priority: wish | Component: | undetermined Version: git-master | Resolution: fixed Keywords: dtPA dtnt | Blocked By: dtmt | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Elon Musk): * status: open => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/959#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#9336(undetermined:new): -cpu-used 9 does not work with libaom's realtime mode
by FFmpeg 01 Oct '22

01 Oct '22

#9336: -cpu-used 9 does not work with libaom's realtime mode -------------------------------------+------------------------------------- Reporter: veikk0 | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: libaom | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: FFmpeg exits with an error message when attempting to invoke libaom's realtime mode with -cpu-used 9. Speed 9 was added to libaom some time ago. It's only valid for realtime mode, however. Note that #9335 affects running libaom in realtime mode, and it may or may not prevent successfully using realtime mode even if this issue is fixed. Error message: {{{ [libaom-av1 encoder @ 0x55af2e7b3f40] Value 9.000000 for parameter 'cpu- used' out of range [0 - 8] [libaom-av1 encoder @ 0x55af2e7b3f40] Error setting option cpu-used to value 9. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height }}} How to reproduce: {{{ ffmpeg -i input.mp4 -an -c:v libaom-av1 -cpu-used 9 -usage realtime -b:v 0 -crf 40 -y cpu9.mp4 }}} Version and build information: {{{ ffmpeg version N-102971-g13ec6624b3 built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9336> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#9952(undetermined:new): Imbedded build of ffmpeg in mplayer fails
by FFmpeg 01 Oct '22

01 Oct '22

#9952: Imbedded build of ffmpeg in mplayer fails -------------------------------------+------------------------------------- Reporter: George R. | Type: defect Goffe | Status: new | Priority: important Component: | Version: undetermined | unspecified Keywords: HAVE_LASX' | Blocked By: undeclared | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug:Mplayer uses and imbeds ffmpeg in it's build directory. This build of ffmpeg is failing (see below). How to reproduce: {{{ % ffmpeg -i input ... output ffmpeg version built on ... }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9952> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1