ChanServ changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.1.1 is released
jdek has quit [Ping timeout: 245 seconds]
MyTDT has quit [Remote host closed the connection]
<gamer191>
I'm very confused how CVE-2023-6602 part ii (https://bugzilla.redhat.com/show_bug.cgi?id=2334338 and ctrl+f "II. HLS Force TTY Demuxer") is a vulnerability. When ffmpeg processes m3u8 files itare supposed to
<gamer191>
(sorry, didn't mean to click send yet)
microchip_ has quit [Ping timeout: 252 seconds]
gamer191 has quit [Quit: Client closed]
gamer191 has joined #ffmpeg
<gamer191>
Try 2:
<gamer191>
I'm very confused how CVE-2023-6602 part ii (https://bugzilla.redhat.com/show_bug.cgi?id=2334338 and ctrl+f "II. HLS Force TTY Demuxer") is a vulnerability. When ffmpeg processes m3u8 files it's supposed to fetch local resources that are linked in the m3u8 file. I believe there's already protection to prevent file:// URLs being abused by online
<gamer191>
m3u8 files. Also, as stated in the vulnerability, only files with a media extension will be fetched. As far as I can tell, the only possible effect of this vulnerability would be that metadata would also be accessible in the output file, but afaik ffmpeg isn't intended to be a metadata sanitizer. So I'm really confused why FFmpeg has chosen to act
<gamer191>
(if irc cuts out again, I'll look at the irc logs to see replies)
superded has joined #ffmpeg
MyTDT has joined #ffmpeg
<JEEB>
gamer191: because the person handling CVEs decided to act on that CVE. after the initial versions of it getting merged broke a bunch of stuff I noted that the stuff could be handled in other ways. In the end my complaints just led to more and more special cases being added to fix things that did not apply to the original author's expectations
<JEEB>
and then since it was marked as a CVE fix it got back-ported to at least one release, so now that's there as well
MyTDT has quit [Ping timeout: 260 seconds]
<gamer191>
JEEB do you agree that it's not a real security issue?
<JEEB>
I don't recall it well enough any more, but the way it was handled just broke way too much :P (and still has stuff broken since there's a very strict limiter in place)
<gamer191>
(I'm closing irc, but I'll read the logs later)
abdu has joined #ffmpeg
gamer191 has quit [Quit: Client closed]
chiselfuse has quit [Ping timeout: 264 seconds]
System_Error has quit [Ping timeout: 264 seconds]
de-facto has quit [Ping timeout: 264 seconds]
ice2 has joined #ffmpeg
paulk has quit [Ping timeout: 252 seconds]
microchip_ has joined #ffmpeg
paulk has joined #ffmpeg
paulk has quit [Changing host]
paulk has joined #ffmpeg
Traneptora has joined #ffmpeg
jmcantrell has joined #ffmpeg
<drew>
I'm trying to do something stupid mostly just for experimentation. I am trying to change the framerate to 1fps and scale the video with ffmpeg -i in.mkv -r 1 -c:v libx264 -vf "resize=-1:480" -c:a libopus -b:a 20k out.mkv
<drew>
but I got repeated warnings about [matroska @ 0x562c95798100] Starting new cluster due to timestampte= 356.1kbits/s dup=0 drop=7623 speed=4.15x while encoding and I got a warning in mpv when I played the file:
<drew>
Audio/Video desynchronisation detected! Possible reasons include too slow hardware, temporary CPU spikes, broken drivers, and broken files. Audio position will not match to the video (see A-V status field). Consider trying `--profile=fast` and/or `--hwdec=auto-safe` as they may help.
<drew>
but when I played the file, it looks like I got mostly what I was going for (though the audio came out as 192kbps instead of 20kbps)
<kepstin>
huh. the scale filter isn't safe to use with "-reinit_filter 0"? I'm getting segfaults on some video inputs :/
Traneptora has quit [Quit: Quit]
microlappy has joined #ffmpeg
CHR0N0S has joined #ffmpeg
gioele has joined #ffmpeg
Traneptora has joined #ffmpeg
microlappy has quit [Quit: Konversation terminated!]
microlappy has joined #ffmpeg
microlappy has quit [Client Quit]
odrling has quit [Remote host closed the connection]
<gioele>
hi, if I use `ffmpeg -i "[URL with the M3U at https://paste.debian.net/1364957/ ]" -codec copy foo.mp4`, the generated foo.mp4 will only include the first audio stream ("Deu"). Is there a way to tell ffmpeg to include both audio streams?
odrling has joined #ffmpeg
abdu31 has joined #ffmpeg
<JEEB>
gioele: see the documentation around `-map` option. for example what `-map 0:a` means ;)
abdu15 has joined #ffmpeg
abdu has quit [Ping timeout: 240 seconds]
<gioele>
JEEB: thanks
abdu31 has quit [Ping timeout: 240 seconds]
<JEEB>
of course as soon as manual stream selection is added, all required streams need to be manually selected by mapping :)
linkmauve has joined #ffmpeg
<linkmauve>
Hi, I’m writing a video-only Vulkan driver, and I’m at the step ffmpeg tells me:
<linkmauve>
[AVHWDeviceContext @ 0xaaaafa194620] compute queue family is required, but marked as missing in the context!
Traneptora has quit [Ping timeout: 276 seconds]
<linkmauve>
Does it really need compute in order to decode videos, or would it be possible to change ffmpeg so that it would fallback on the CPU or on another Vulkan driver for whatever it currently uses compute for?
<linkmauve>
I assume it’d be scaling, YUV→RGB conversion, stuff like that.
<JEEB>
would not be surprised that the default flags are just for whatever various components in FFmpeg are utilizing indeed
<JEEB>
not sure if it's like with d3d11 where various flags for swap chain etc can be overridden by the API client
<JEEB>
OK, looking at the version of hwcontext_vulkan.c I have these things are hard-coded under FF_API_VULKAN_FIXED_QUEUES
<JEEB>
so it seems like that logic is deprecated but still there for now?
<linkmauve>
I’m not at the point where I can handle swap chains just yet, for now I’m stubbing most calls and figuring out what ffmpeg and Gstreamer use so I can start implementing them along.
<linkmauve>
I guess I’ll remove the compute queue request and see where it takes me. :)
<JEEB>
linkmauve: I think you might just be able to go to libavutil/version.h and change the define for testing purposes to 0
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg
Guest17 has joined #ffmpeg
<Guest17>
Hi, I try to convert a corrupted file, which is played to the end by ffplay, but ffmpeg truncates it to 7 seconds no matter what options I tried (`-fflags +discardoutput`, `-err_detect ignore_err`, `-max_error_rate 1`). Why? The file: https://0x0.st/8jpF.mp4
lavaball has quit [Remote host closed the connection]
Sketch has quit [Ping timeout: 268 seconds]
JaFriend has joined #ffmpeg
Sketch has joined #ffmpeg
EmleyMoor has quit [Quit: Gateway shutdown]
EmleyMoor has joined #ffmpeg
Sketch has quit [Ping timeout: 246 seconds]
MyTDT_ has joined #ffmpeg
<grib>
try "+discardcorrupt" instead of "+discardoutput"
Sketch has joined #ffmpeg
MyTDT_ has quit [Ping timeout: 268 seconds]
<grib>
Guest17: I don't think discardoutput is a real flag
JanC has joined #ffmpeg
JaFriend29 has joined #ffmpeg
<Guest17>
grib: yes, it was +discardcorrupt.
Sketch has quit [Remote host closed the connection]
<Guest17>
I messed it when retyping into the chat.
<Guest17>
grib: the fact ffplay manages to play it and ffmpeg doesn't is the weirdest part. Perhaps it's something related to stream length detection?
flotwig has joined #ffmpeg
flotwig has quit [Changing host]
flotwig has joined #ffmpeg
<Guest17>
I would actually just record it with ffplay it it was possible (screen capturing would work, but meh).
<Guest17>
Interesting, if I attempt to convert it to mp3, it aborts at `ffmpeg: psymodel.c:576: calc_energy: Assertion `el >= 0' failed. `.
<Guest17>
Ookay, it works with wav, this is why it also works with ffplay probably. So I would just need to convert it into some intermediate raw format.
Sketch has joined #ffmpeg
golemz has joined #ffmpeg
<grib>
interesting! i would have thought codec copy would have been enough, but maybe not.
<grib>
"ffprobe -show_entries packet=dts,size -print_format compact" showed the OK packets were mostly small but the corrupt one is waaaaay bigger
<Guest17>
Yeah, DTS are uneven, so ffplay just ignores them, I suppose? And ffmpeg just ends the file when it reaches zero DTS? It exists with zero status, most wierdly, so it doesn't even seem to think it's some "error".