michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
minimal has quit [Quit: Leaving]
<compn>
i dont understand film grain filter
<compn>
makes no sense to me
cone-141 has quit [Quit: transmission timeout]
System_Error has quit [Ping timeout: 264 seconds]
Teukka has quit [Ping timeout: 248 seconds]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 272 seconds]
System_Error has joined #ffmpeg-devel
jamrial has quit []
secondcreek has joined #ffmpeg-devel
<fflogger>
[newticket] SubJunk: Ticket #11594 ([avcodec] Hardcoding subtitles broken with libx265 since 20241205) created https://trac.ffmpeg.org/ticket/11594
CounterPillow has quit [Quit: Bye.]
<Marth64>
I find it helpful sometimes as a facade to mask other quality issues but not often
CounterPillow has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<softworkz>
mkver+jamrial: Regarding your idea about removing my new function avfilter_link_get_hw_frames_ctx()...
<softworkz>
1. I've seen this coming
<softworkz>
2. Please note that AVFilterLink is not only public itself for a long time, but also through another function and the AVFilterContext structure.
<softworkz>
3. The comment you were referring to is outdated instead
softworkz has quit [Quit: Leaving]
usagi_mimi has joined #ffmpeg-devel
mkver has quit [Ping timeout: 268 seconds]
halloy8931 has joined #ffmpeg-devel
halloy8931 has quit [Client Quit]
bwu25 has joined #ffmpeg-devel
bwu25 has quit [Client Quit]
bwu25 has joined #ffmpeg-devel
softworkz has joined #ffmpeg-devel
bwu25 has quit [Client Quit]
bwu25 has joined #ffmpeg-devel
bwu25 has quit [Client Quit]
<softworkz>
The comment is outdated not only because it's publicly exposed in multiple ways - there's even a private counterpart (FilterLinkInternal) meanwhile to which those things have been moved that should not be publicly accessed, so I would rather suggest to remove that comment
<frankplow>
I recall someone (maybe Lynne?) talking about transposes of arbitrary rectangular blocks in SIMD a little while ago and saying the best approach is storing to stack and then doing strided loads. Could someone point me to an example of this?
<Lynne>
I don't think it was me, maybe it was Gramner?
<Lynne>
though it sounds like a pretty good way of doing it
<Lynne>
depends on the block size though, if you can get away with shuffles, its better than waiting for decades for the painfully slow gather instructions
<Lynne>
we have routines in x86inc.asm to transpose blocks, you should look to see if you can reuse them
<frankplow>
Yeah I think there will probably be faster ways to do it, but I've spent quite a while trying to do it in the registers with no luck. There's quite a range of block sizes and some are quite silly (e.g. 2x64).
<frankplow>
The TRANSPOSE_* routines in x86util.asm look to be mostly for square blocks
<Lynne>
you should use jump tables to have specific routines to handle different block sizes
<Lynne>
e.g. square ones use TRANSPOSE_, where possible rectangular ones use shuffles, else gathers
<frankplow>
Yeah that was my plan. The extreme aspect ratio rectangular blocks are pretty rare, so performance isn't so critical for them.
<Lynne>
eh, so far anyway
<Lynne>
when custom encode ASICs come along, I think 64x2 will be more popular since they're easy on the hardware
<Gramner>
for transposes just use a bunch of shuffles. it doesn't really matter whether it's a square or rectanglular block
<Gramner>
assuming you already have the input in registers that is
<michaelni>
it should be a matter of listing the wrong extensions used or we can also change extension picky default to disabled and document it
<sfan5>
if it's disabled by default, why have it at all?
<kasper93>
Ideally, ffmpeg could mark unsafe demuxers (xbin and others) as unusable (unsafe) from HLS (or similar), rather than blocking everything based on file extensions.
<kasper93>
mpv uses "origin tracking", so local files can't be referenced from network originated playlist. Of course there is also a case of accessing localhost, but this is not covered by extentions picky anyway. And for that mpv uses unsafe protocol list that are not allowed to be accessed in safe context.
<Lynne>
michaelni: libavformat/hls.c, detected format %s extension %s mismatches allowed extensions in url
<Lynne>
gets triggered on youtube dash livestreams
<Lynne>
aac is allowed, but a mismatch is not allowed
<JEEB>
I think I raised my concerns regarding the extension checking once during the FOSDEM call, and then later on the ML. given the nature of the thing (random HTTP URLs generated by automated systems or otherwise), you can limit *formats* (demuxers) that get utilized, but you cannot effectively start limiting extensions
<michaelni>
kasper93, ticket 11435 is unreadable
<haasn>
help, I'm being blocked by my inability to figure out how to let users opt in to the new swscale code :(
<haasn>
I wanted -sws_flags experimental but somebody managed to already make that the name of a scaling mode
<JEEB>
even if the original people who reported the CVE thought that would be the best way forward
<JEEB>
haasn: ouch
<haasn>
I don't want it on by default until we have coverage of all platforms
<kasper93>
`-sws_flags next` lol
<haasn>
-sws_flags experimental_code works I guess
<haasn>
but is a bit long and ugly
<haasn>
I guess I'll go with that..
<JEEB>
neo/new/neue core (at least it's not -ng のヮの)
<haasn>
or, for the maximum level of trolling, I just rug-pull the semantics of "experimental" with no deprecation period :^)
<haasn>
who even uses a scaler called "expiremental" in production
<haasn>
who even calls a scaler that
<compn>
haasn, -sws_flags other /s
<JEEB>
haasn: yea depending on what it was currently mapped to, I wouldn't be against just replacing its meaning >_>
<fflogger>
[editedticket] oromit: Ticket #11298 ([undetermined] AMD VAAPI HEVC encoding a 1080p video results in a 1920x1088 one) updated https://trac.ffmpeg.org/ticket/11298#comment:4
<fflogger>
[editedticket] jamrial: Ticket #11298 ([undetermined] AMD VAAPI HEVC encoding a 1080p video results in a 1920x1088 one) updated https://trac.ffmpeg.org/ticket/11298#comment:5
Sean_McG has joined #ffmpeg-devel
<Sean_McG>
hey folks, just a heads-up that since a few days ago I unsubscribed from the ML. If you need me for something, don't hesitate to email me directly.
<toots5446>
I'm working on the checking the vorbis side against the file that was brought up.
Sean_McG has quit [Quit: leaving]
<cone-461>
ffmpeg Pavel Koshevoy release/7.1:24de8a98cfb3: avformat/mpegts: update stream info when PMT ES stream_type changes
<cone-461>
ffmpeg Pavel Koshevoy release/6.1:8723e8369947: avformat/mpegts: update stream info when PMT ES stream_type changes
<ramiro>
haasn: I still have some work to do cleaning up the functionality that I added to the memcpy backend and to the shuffle solver, but you can probably start with the following commits from https://github.com/ramiropolla/ffmpeg/tree/swscale6-asmjit-neon: 4d6a2423, 3ccb5578, 74303464, 37d80d94, 1a82f632
<Lynne>
toots5446: could you push all the commits you'd like to have pushed to a branch somewhere, so I can pull+push?
HarshK23 has quit [Quit: Connection closed for inactivity]
<ramiro>
haasn: valgrind is not happy with the x86 shuffle solver. even rgb24->bgr24 fails: valgrind ./libswscale/tests/swscale -unscaled 1 -v 100 -src rgb24 -dst bgr24
<ramiro>
I'm not a big fan of the over-reading and over-writing. also not a big fan of the misalignment that causes. in rgb24->bgr24 the block_size is 5, which works on 15 bytes at a time, so the src/dst pointers are not aligned most of the time.
<ramiro>
what I did with neon is to always process a multiple of the vector size. in the worst case I need 10 tbl instructions and need to write 128 bytes per chunk, but it works and it's still faster than the alternatives.
<haasn>
ramiro: you have to overread / overwrite internally even if you process a multiple of the vector size
<haasn>
The misaligned vectors shouldn’t be visible outside the implementation
<haasn>
Where they’re unavoidable
<haasn>
I guess I see your point about the API being cleaner though
<haasn>
Anyway I’ll look into the valgrind issues tomorrow