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
<fflogger>
[editedticket] socram: Ticket #11493 ([ffmpeg] ffmpeg causes mkv corruption when remuxing existing MKV with WEBVTT (.vtt) subtitles that have empty cue blocks) updated https://trac.ffmpeg.org/ticket/11493#comment:2
_whitelogger has joined #ffmpeg-devel
_whitelogger has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 265 seconds]
prathamd_ has quit [Ping timeout: 276 seconds]
AtleoS has quit [Quit: AtleoS]
jamrial has quit []
_whitelogger has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
bwu25 has joined #ffmpeg-devel
bwu25 has quit [Client Quit]
bwu25 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
bwu25 has quit [Quit: bwu25]
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
TheVibeCoder has joined #ffmpeg-devel
<TheVibeCoder>
FFmpeg is full of bugs, switch to Rust projects immediately, yesterday was super time for switch, today is also good time.
zulleyy3 has quit [Ping timeout: 244 seconds]
zulleyy3 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
DVedaa has quit [Read error: Connection reset by peer]
DVedaa has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
<fflogger>
[newticket] TheTroll: Ticket #11597 ([avfilter] FFmpeg output is stuck if using split with fps filter) created https://trac.ffmpeg.org/ticket/11597
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Guest92 has quit [Quit: Client closed]
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
TheVibeCoder has quit [Quit: Client closed]
prathamd_ has joined #ffmpeg-devel
prathamd_ has quit [Client Quit]
<haasn>
ramiro: do you have a branch with your swscale fixes (from ML) that, presumably, fix all of the legacy swscale conversion bugs in tests/libswscale?
cone-374 has joined #ffmpeg-devel
<cone-374>
ffmpeg Lynne master:ebbc7ff65067: ffv1enc_vulkan: merge all encoder variants into one file
<cone-374>
ffmpeg Lynne master:a4078abd739a: vulkan/ffv1: synchronize get_pred implementations between encoder and decoder
<cone-374>
ffmpeg Lynne master:7c0a8c07ce75: ffv1enc_vulkan: unify EC code between setup and encode
<cone-374>
ffmpeg Lynne master:69f83bafd1fa: ffv1enc_vulkan: get rid of temporary data for the setup shader
<cone-374>
ffmpeg Lynne master:52595025c5aa: ffv1enc_vulkan: minor EC optimizations
<cone-374>
ffmpeg Lynne master:7c3c5c805270: hwcontext_vulkan: correct image transfer usage flags
<cone-374>
ffmpeg Lynne master:eabb62813e74: hwcontext_vulkan: only try exporting DMABUF memory on !WIN32 and only for DMABUF tiling
realies9 has quit [Quit: ~]
realies9 has joined #ffmpeg-devel
<haasn>
to those who were interested: nuscale C only vs legacy C only: Overall speedup=3.418x faster, min=0.162x max=103.685x
<ramiro>
haasn: those fixes are on my swscale6-asmjit-neon branch (commit messages that start with [upstream])
<haasn>
ah
<ramiro>
my branches usually have commit messages that are not very descriptive. because obviously I will remember every single detail about them when I finally want to upstream them and it won't take me half an hour to write a proper commit message :P
Guest92 has joined #ffmpeg-devel
<ramiro>
haasn: what are the worst converters in the new C code? if it's the lut-based yuv2rgb it should be fine to ignore the difference
Guest92 has quit [Client Quit]
<haasn>
gray -> yuv seems like a usual offender
<haasn>
I didn't save the whole output of the test run
<haasn>
maybe we should modify swscale.c to start keeping track of outliers and print the worst ones at the end
<haasn>
I think that already would have saved me time
<haasn>
btw, I was trying to test with valgrind but for some reason even rgb24 -> bgr24 doesn't pass
<haasn>
it also constantly complains about printf() depending on uninitialized values even if I explicitly try initializing everything
<haasn>
something is definitely going on
<fflogger>
[newticket] evgene_123: Ticket #11598 ([ffmpeg] `gdigrab` Screen Capture Causes Cursor Flickering and Focus Loss on Windows (Multi-Monitor)) created https://trac.ffmpeg.org/ticket/11598
<ramiro>
I keep my results in log files for each run. I changed the formatting and alignment of the output so that I can easily see the backend that was used, and awk it into a csv. then I sort by speedup and have a closer look at the slowest ones
<ramiro>
also I'd like to be able to run just the new code and get the timings for that. most of the time is spent running legacy code, which won't change between runs
<fflogger>
[newticket] evgene_123: Ticket #11599 ([ffmpeg] `gdigrab` Screen Capture Causes Cursor Flickering and Focus Loss on Windows (Multi-Monitor)) created https://trac.ffmpeg.org/ticket/11599
<ramiro>
haasn: I suspect gray -> yuv may benefit from working the planes independently (2 are just memsets)
<haasn>
definitely
<haasn>
somehow valgrind thinks all my image planes are uninitialized unless I compile with --disable-asm
<ramiro>
about valgrind, yes, there are still a few issues. some memcpy where both src and dst point to the same place. I haven't investigated how it got there though.
<haasn>
well, not just thinks, somehow they *are* uninitialized (SSIM goes to 0)
<ramiro>
what I found the oddest about running under valgrind is that the tests fail. so there's something very very fishy about it.
<haasn>
ramiro: solved the dither memleak, op_list_remove_at() didn't uninit the removed op
<haasn>
with the C code only, valgrind passes
<haasn>
you're right that it's only the shuffle solver causing problems though
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 276 seconds]
<haasn>
is it possible that valgrind doesn't like the fact that we read into the (uninitialized) image stride, perform a pshufb, and then write back into the stride?
<haasn>
maybe it can't track that the stride part of the input doesn't bleed into the non-stride part
<haasn>
(or maybe it _does_ bleed)
rvalue- is now known as rvalue
mkver has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
<haasn>
ramiro: solved the packed shuffle issues
<haasn>
turns out I had an imul between "dec yendd" and "jg .loop"
<haasn>
which overwrote the flag
<haasn>
no idea why only when valgrind was enabled
<haasn>
maybe it changed some cpu settings
<ramiro>
haasn: too aggressive manual instruction reordering?
<haasn>
no, I think it was just a mistake :)
<haasn>
normally I try to reorder things so that the inc/dec and the jump are adjacent
<haasn>
because iirc the CPU can decode those as a single uop
<Gramner>
indeed. usually referred to as "macro-op fusion". not just decoding either, a fused cmp+branch is also executed and retired as one op
<haasn>
valgrind passes now :)
<linkmauve>
For debugging purpose, is it possible to make ffmpeg do absolutly everything on a single thread?
<cone-374>
ffmpeg Zhao Zhili master:4f7bc62c6644: avformat/allformats: Move avisynth and dvdvideo under external libraries group
<cone-374>
ffmpeg Zhao Zhili master:124977664101: Makefile: Remove postproc from ALLFFLIBS
<cone-374>
ffmpeg Shiyou Yin master:f41403877921: configure: identify loong64 for loongarch
<ramiro>
linkmauve: I normally use "taskset -c 0" for that
<ramiro>
(or -c 4 on my rk3588 to pick an out-of-order core)
<fflogger>
[newticket] rmotrescu: Ticket #11600 ([undetermined] Ffprobe/Ffmpeg with libfdk-aac doesn't recognize AAC-HE(v2) livestreams) created https://trac.ffmpeg.org/ticket/11600
<ramiro>
Gramner: I believe this is also the case on aarch64 (macro-op fusion), but I'm not quite sure how to test this. it's too small to make a noticeable difference in my loops
<linkmauve>
My very first image, running ffmpeg with its Vulkan H.264 decoder (I get the same output with Gstreamer), using my Vulkan driver, which uses V4L2 stateless, to then dump to a file and exit(0). :)
<ramiro>
haasn: why does yuva444p9le->yuva444p10le need dither but yuva444p9le->yuva444p12le doesn't?
<haasn>
ramiro: 12 bits is considered above the visual threshold of perception
<haasn>
see the logic in fmt_dither() in format.c
<thardin>
do we also dither when going from say 1-bit to 8-bit?
<ramiro>
haasn: in that same conversion (yuva444p9le->yuva444p10le), dithering affects all planes. but if dst is yuv444p10le instead (no alpha), no dithering is applied. should dithering be applied differently when there is alpha or not?
<haasn>
no, strictly speaking it should not, but we don't currently have a way to signal dithering only for some planes
<haasn>
it shouldn't change the result though since adding dithering to a lossless result won't change the output
<haasn>
since the dither matrix is strictly less than 1
<haasn>
so this is just an optimization and not a fundamental error, and one we will optimize for free once we split independent planes
<ramiro>
haasn: got it. thanks
<ramiro>
haasn: it's weird the way we treat alpha in x2bgr10le. it's only 2 bits, but we add 0.5 when dithering. I'd never heard of this pixel format, but I'm not quite sure those 2 bits should be treated as alpha.
<haasn>
what destination format?
<ramiro>
x2bgr10le is the destination (src gbrap14le in my specific case but any other with alpha could work)
<ramiro>
it doesn't even have AV_PIX_FMT_FLAG_ALPHA in pixdesc.c
<haasn>
well, internally we don't really care what we write to those two bits since we assume they may contain garbage
<jannau>
x2bgr10le as in DRM_FORMAT_XBGR2101010 is used as 10 bit RGB format. the X vs. A signifies that the two bits are ignored
<haasn>
it's true that our pipeline could do a better job at marking them as unused though
<haasn>
maybe we should add something like an execution mask to all ops, to be able to e.g. only apply an op to some components
<haasn>
and then we could mark those two bits as not part of the SWS_OP_PACK, so the rest of the pipeline can optimize away any ops affecting them
<ramiro>
jannau: thanks!
<jannau>
there is also DRM_FORMAT_ABGR2101010 but I doubt anyone use alpha there for anything but for cut-outs to show underlays
<ramiro>
haasn: I think I got to a point with asmjit (and memops) where the only conversions that are slower (less than 0.95) are the x2-related ones, and ones that will be simplified once we split independent planes. the slowdowns come from converting to float to multiply by a power of 2 (when we could have just shifted instead), and applying dithering that doesn't change the result.
<haasn>
ramiro: which exact case are you hitting where we fail to optimize a pot2 mult into a shift?
<ramiro>
haasn: yuva444p9le->yuva444p10le. the alpha plane has a non-power-of-2 multiplication, so all planes go through f32 and linear
<haasn>
oh, still that one
<haasn>
yes, right
<ramiro>
if planes are treated independently, only alpha won't be a memop
<ramiro>
well, I also added lshift to my memops, which makes it not really a memop.
<cone-164>
ffmpeg Lynne master:842fa198e979: hwcontext_vulkan: fix build with old Vulkan header versions
<Lynne>
VK_KHR_shader_subgroup_rotate should be supported within the version of the headers we support, so there shouldn't be a need for checks in this case
<fflogger>
[editedticket] Balling: Ticket #11298 ([undetermined] AMD VAAPI HEVC encoding a 1080p video results in a 1920x1088 one) updated https://trac.ffmpeg.org/ticket/11298#comment:7
<BtbN>
Is it "legal" for a decoder to EAGAIN an EOF packet?
<mkver>
Doesn't make any sense. What decoder?
<BtbN>
Apparently not, causes an assertion in ffmpeg_dec.c
<BtbN>
Why does it not make sense? the EOF packet causes the decoder to flush, and if the output buffer is all full, it can't flush
<BtbN>
so what's it supposed to do, buffer the EOF request?
<mkver>
I misread: I thought by "decoder" one of the internal decoders (i.e. the return value of one of the internal decode callbacks), not the return code of avcodec_send_packet().
<mkver>
Or are we talking about avcodec_receive_frame()? First you say "on packet", then you mention an assert in ffmpeg_dec.c depending upon the avcodec_receive_frame() return value.
<mkver>
Is this a regression since b18aaf209f007e67ac4490ba5647ea139d1a6dcb? Can you open a proper ticket?
<BtbN>
No idea if it's a regression. I'd like to make cuvid EAGAIN an EOF request, since its output buffer is full at that time. But can't, since it causes an assertion
<kepstin>
the eof is just supposed to start the flush process, right? afterwards, the user expects to call receive_frame until they get all frames and the decoder returns eof.
<BtbN>
Well, in the case of cuvid, passing on the EOF to the underlying decoder makes it instantly barf out a ton of frames
<BtbN>
Somehow it outputs more frames at once than should be possible though, so I'm looking into wtf is going on
<BtbN>
like, it's configured with 8 decode surfaces
<BtbN>
but on EOF, it outputs 9 at once
<BtbN>
that should not be possible
<kepstin>
fwiw, all the example code for the ffmpeg decode apis appear to expect avcodec_sent_packet(ctx, NULL); to always work unless there's an error that would require aborting the decode.
<kepstin>
at least, they seem to rely on the case where if you call receive_frame() and get EAGAIN, then calling send_packet() immediately after must not return EAGAIN.
<BtbN>
What's happening is that the max_display_delay is set to 4
<BtbN>
so cuviddec.c makes sure to keep at a minimum 4 buffer-slots free, for those 4 frames to appear at any time
<BtbN>
but on the flush packet, cuviddec dumps out a lot more than 4
Guest46 has joined #ffmpeg-devel
Guest46 has quit [Client Quit]
<kepstin>
to the best of my understanding, it should be ok for send_packet with NULL to return EAGAIN only if it happens 1) after a previous call to send_packet with no intermediate receive_frame calls, or 2) after a receive_frame call which did not return EAGAIN.
<BtbN>
hm, I guess on a flush, it just dumps out everything it got with no regard for its own buffer limits
<BtbN>
so I will have to somehow withhold actually flushing the underlying decoder until the output queue is fully empty
<kepstin>
yeah, i guess in that case you'd want flushing the ffmpeg "decoder" to just set a flag, and have logic so that in the following calls to recieve_frame it'll flush the underlying decoder at an appropriate time.
<BtbN>
This gets fun when it dumps out more frames at once than it even HAS surfaces available