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
abdu has joined #ffmpeg-devel
thilo_ has quit [Ping timeout: 265 seconds]
thilo_ has joined #ffmpeg-devel
Xaldafax has quit [Quit: Bye...]
k777__ has quit [Remote host closed the connection]
DVedaa has quit [Read error: Connection reset by peer]
DVedaa has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 272 seconds]
rit has quit [Remote host closed the connection]
rit has joined #ffmpeg-devel
aljazmc has quit [Quit: Leaving]
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
thilo_ has quit [Quit: WeeChat 2.8]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Anthony_ZO1 has joined #ffmpeg-devel
Anthony_ZO has quit [Ping timeout: 245 seconds]
Anthony_ZO1 is now known as Anthony_ZO
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<averne>
Hello, what is the expected behavior of hwaccels upon resolution changes? (if any) Decoders don't seem to reinitialize the hwaccel, so my current code accepts those iff the new resolution fits in the starting dimensions, and I return an error otherwise
<Lynne>
frame_params should be called through get_format
<Lynne>
h264 in particular calls get_format every single frame
<Lynne>
you should remake the hwframes ctx there
<averne>
I see, I didn't realize that would get called outside decoder initialization. Seems like an easy footgun if you put intensive code there
<fflogger>
[newticket] elem: Ticket #11539 ([ffmpeg] ffmpeg hangs when using gdigrab with show_region on Windows) created https://trac.ffmpeg.org/ticket/11539
System_Error has quit [Remote host closed the connection]
<fflogger>
[newticket] fmnijk: Ticket #11541 ([avcodec] All NVENC encoders change bt709 color space to bt470bg when pixel format is not specified) created https://trac.ffmpeg.org/ticket/11541
minimal has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<haasn>
ramiro: some more bikeshedding: decided to collapse all the "simple" ops into a single union SwsConst { AVRational q; AVRational q4[4]; unsigned u; }
jarxxd has quit [Ping timeout: 245 seconds]
<haasn>
also decided to split SWS_OP_CLAMP into explicit _MIN and _MAX ops
<ramiro>
haasn: I currently have a check that, if float->integer conversion is done after a clamp, I can omit the max(val, 0) op, since the conversion itself will convert negative to 0. how do you check when min and max should be called?
<haasn>
min and max are checked separately against the possible input value range
<haasn>
not sure I understood the question; previously we always emitted a clamp when a max(val, 0) op was needed
<haasn>
now we conditionally emit it only if the input can actually go negative
<ramiro>
ah, ok. that does sound like an improvement
<ramiro>
I guess it will be simpler to just skip an operation in my case, instead of having to special case and emit only half an operation
<ramiro>
because even if it can go negative, I can skip that because the conversion will take care of it.
<fflogger>
[editedticket] Balling: Ticket #11541 ([avcodec] All NVENC encoders change bt709 color space to bt470bg when pixel format is not specified) updated https://trac.ffmpeg.org/ticket/11541#comment:4
<fflogger>
[editedticket] fmnijk: Ticket #11541 ([avcodec] All NVENC encoders change bt709 color space to bt470bg when pixel format is not specified) updated https://trac.ffmpeg.org/ticket/11541#comment:5
<haasn>
ramiro: for the loop, I think I want to give SwsFuncEntry a signature like (const SwsImg *in, const SwsImg *out, int y, int h, int x, int w)
<haasn>
and have the entry function take care of looping over the entire range
<haasn>
with some constraints like h/w always being aligned to the SwsOpChain alignment requirements
<haasn>
op_pass_run would still take care of fixing the mispadded/misaligned case, but the "fast path" would condense down to a single call
<haasn>
then the first entry point can be an asm function that e.g. sets up the loop variables inside pinned/saved registers
<haasn>
so that the read/write kernels can directly use/bump them
kasper93 has quit [Quit: kasper93]
abdu has quit [Quit: Client closed]
kasper93 has joined #ffmpeg-devel
josephseed has joined #ffmpeg-devel
amogh has joined #ffmpeg-devel
josephseed has quit [Remote host closed the connection]
josephseed has joined #ffmpeg-devel
josephseed has quit [Remote host closed the connection]
abdu has joined #ffmpeg-devel
josephseed has joined #ffmpeg-devel
josephseed has quit [Remote host closed the connection]
amogh has quit [Ping timeout: 244 seconds]
amogh has joined #ffmpeg-devel
amogh_ has joined #ffmpeg-devel
<amogh_>
Hello! I just noticed that you guys have qualification tasks to be completed for filling the GSoC application. So what is the deadline for completing the same?
<ramiro>
haasn: I liked the simplicity of having all the data in SwsOpExec. it was easy to read the data from pointer+offset, so I didn't have to deal with different calling conventions. but I think asmjit itself will take care of that, so it should be good.
abdu has quit [Ping timeout: 240 seconds]
<amogh_>
Should it also be completed by 8th April or can it be done after that?
termos is now known as termos__
<ramiro>
haasn: the entire chain will consist of hand-written assembly from your x86 backend, right? to pin the registers, will you just document the registers that shouldn't be used inside the other functions besides read/write?
<haasn>
yeah, I already do this for the data registers so I might as well do it for the address registers as well
<haasn>
I mean I can use saved registers for it
<haasn>
and keep temorary registers for inner functions
termos__ is now known as termos
termos is now known as termos__
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 248 seconds]
<ramiro>
haasn: I'm also curious to see how you will deal with vertically subsampled data, with regards to the vector registers. we will need to have data from two lines, which should double the vector registers used.
<ramiro>
the same thing goes for bilinear/bicubic filtering. how will you manage the multiple lines of data?
rvalue- is now known as rvalue
<haasn>
my strategy for dealing with subsampled data so far has been to not worry about it :)
IndecisiveTurtle has joined #ffmpeg-devel
<haasn>
well, worst case scenario we just ignore half the lanes for chroma data
___nick___ has quit [Ping timeout: 244 seconds]
<ramiro>
haasn: one step at a time, I guess :). sure, you can worry about subsampled data later, but what about filtering? what's the strategy for vertical filters?
<haasn>
I mean, I don't think we need a special strategy for filtering because it's always the first step, right?
<haasn>
so as far as the rest of the "pipeline" is concerned, everything is as normal
<haasn>
I guess the problem is if you want to filter multiple planes at once
<haasn>
since you may run out of vector registers
<haasn>
worst case we just filter one plane at a time
<ramiro>
haasn: hmm... and how is the upscaling/downscaling done?
abdu has joined #ffmpeg-devel
<haasn>
wdym?
<ramiro>
haasn: the actual process of scaling the image. from what I understood, this new architecture tries to keep data in cache for faster operation. so we would be outputting data as soon as we read it, instead of having multiple passes over the entire image like the current swscale.
<ramiro>
haasn: oh, that's actually point 1 in "Future considerations and limitations" on your swscale-v2.txt: "It does not handle scaling at all. I am not yet entirely sure on how I want to handle scaling".
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
IndecisiveTurtle has quit [Quit: IndecisiveTurtle]
<jamrial>
michaelni: there's a leak after the metadata id3v2 patches
<jamrial>
cover-art-aiff-id3v2-remux, cover-art-wma-id3 and id3v2-utf16-bom trigger it
<fflogger>
[editedticket] MasterQuestionable: Ticket #11541 ([avfilter] Better warning for silently skipped color primaries meddling?) updated https://trac.ffmpeg.org/ticket/11541#comment:6
<jamrial>
probably related to the new flag
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<haasn>
ramiro: I was thinking we'd use a small ring buffer for scaling, as is the case with contemporary designs
<haasn>
run the prepass outputting into the ring buffer, run the scaling kernel on the ring buffer followed by the postpass
<haasn>
will require a memory roundtrip but that's the status quo as well