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
<ramiro>
haasn: good idea about memdup'ing the SwsOpsList. if a backend fails to compile, but has already done some optimizations, we don't lose the original list. it's easy for me now since neon still has a 1:1 mapping to the optimized list that it receives, but if we get more aggressive optimizations per backend that change the list, it'd be easier to roll back.
<ramiro>
I haven't checked your changes for the last couple of days. I thought there was enough to implement the asmjit backend already. once I get that mostly working I'll rebase on your work and check if what has changed has no downsides.
<ramiro>
haasn: good idea to keep SWS_ACCURATE_RND int only and speed things up. but does anyone actually use it?
<ramiro>
it seems to me like that kind of optimization that was a good idea 20 years ago, but that nowadays is probably not used that much. hevc decoding certainly takes much longer than converting a frame using accurate rounding or not.
<ramiro>
hmmmmm. but actually I would very much be happier with an unscaled pixel format conversion not having to go through f32 :D
<ramiro>
haasn: what multiple functions were you thinking of compile() returning? I was thinking about input/output alignment and when width == linesize
<averne>
I'm investigating a corruption on ITU sample MR8_BT_B. NVDEC hardware engine wants the LongTermPicNum value which is taken from H264Picture::pic_id, except the snippet above ends up changing it, which makes the decoding blow up
tufei has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<averne>
Checking the relevant spec section (8.2.4.3.2 Modification process of reference picture lists for long-term reference pictures), the code doesn't seem to match at all, it should be pretty similar to cases 0-1 above except operating on long refs
<averne>
So I'm a bit struggling to understand what it's trying to achieve
<compnn>
mindfreeze, does the sample decode ok or no?
<compnn>
mindfreeze, and by ok, i mean bitexact to some other reference decoder...
<Lynne>
averne: -1 == missing
<Lynne>
I'm surprised you found a sample with LTR
<Lynne>
no one used them
<compnn>
averne, probably ping michaelni about that one. sounds like a rare sample...
<compnn>
h264 is full of features no one ever used
<JEEB>
if it's an ITU sample it's probably one of the reference suite ones
<compnn>
oh yea
<averne>
compnn: it does decode fine on ffmpeg's sw decoder
<compnn>
oh nvdec on LTR
<compnn>
i see i see
<averne>
yep
<averne>
Well, nvdec (cuvid) decodes it fine because it doesn't use pic_id. Instead it uses the position of the ref within the long_ref array. It happens to work out fine here, but breaks on other samples
<JEEB>
this is the listing of the test vector suites
<averne>
I'm working on my own hwaccel here, which also based on NVDEC but at a lower level. Basically I'm bypassing cuvid and programming the engine directly
<JEEB>
yea, the tegra stuff (switch etc)
<averne>
Kind of, originally this was targetting only tegra but recently I got it working on desktop cards too
<JEEB>
also that sounds like one of the old test vectors :D
<JEEB>
the link I posted has the currently in force ones
<JEEB>
apparently in 2016 they last updated them
<compnn>
JEEB coming in with the 'your samples are outdated' :D
<cone-075>
ffmpeg Shreesh Adiga master:26f2f03e0de2: swscale/x86/rgb2rgb: optimize AVX2 version of uyvytoyuv422
<mindfreeze>
compnn: yes, I can decode totoally fine with ffmpeg and also with old ffmpeg version which was libopenjpeg.
<mindfreeze>
The key confusion is, the input sample is regular RGB input (10bit) but ffmpeg reads as yuv420p10le which sounds strange to me as input is not 420
<mindfreeze>
OpenJPEG can read and process this too
<compnn>
and what mediainfo is using to decode/sniff it
<JEEB>
compnn: it's a possibility, so since I saw "draft_conformance" in the URL it's worth a check if the sample is still there in the current ones
<JEEB>
it might have been updated, or otherwise. but even if it was no longer there, depending on the person's needs they could still of course attempt to figure out why it no work with their HW decoder. those two things are separate.
<JEEB>
it's just generally worth checking if you're utilizing the latest test suite
<compnn>
fully agree
<averne>
JEEB: I downloaded the newer suite just to make sure, MR8_BT_B is still present and bit-identical to the one I was working with
<JEEB>
nice
<averne>
So, michaelni if you have some insight I'm interested
<JEEB>
and I guess it isn't actually utilizing long-term refs?
<averne>
JEEB: it is using LTR, 2 of them actually
<averne>
I *think* it makes sense, will post on the ML
<averne>
At the very least it doesn't regress the software decoder
<averne>
With this, my hwaccel passes 37 more tests on that conformance suite than the nvdec hwaccel on my RTX3050, and 8 more than vaapi on my RX6700XT :)
<Lynne>
you know there's work already done on nvk?
<Lynne>
you could take a look at it
<averne>
Lynne: I'm aware, I've helped Daniel quite a bit actually
<Lynne>
ah, I haven't seen you often on #nouveau
<Lynne>
how does it handle LTR or did they also not have the pleasure of never caring about LTR?
<averne>
which is either long_term_pic_idx or framenum
IndecisiveTurtle has joined #ffmpeg-devel
<frankplow>
averne: Yeah I just meant something which used nvidia's parser.
abdu has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11363 ([avcodec] MediaCodec de/encoders no more work since Android 15 (No output buffer available)) updated https://trac.ffmpeg.org/ticket/11363#comment:10