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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
thilo has quit [Ping timeout: 276 seconds]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht8 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht8 is now known as arch1t3cht
feiw2 has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
feiw1 has quit [Ping timeout: 255 seconds]
mkver has quit [Ping timeout: 252 seconds]
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
cone-004 has quit [Quit: transmission timeout]
Martchus has joined #ffmpeg-devel
tufei__ has quit [Quit: Leaving]
Martchus_ has quit [Ping timeout: 276 seconds]
jamrial has quit []
tufei has joined #ffmpeg-devel
marcj has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
marcj has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
psykose_ has joined #ffmpeg-devel
psykose has quit [Ping timeout: 248 seconds]
psykose_ is now known as psykose
System_Error has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<JEEB> huh, did not earlier notice that various RDDs like RDD 36 (Prores bitstream syntax & decoding process) were available @ https://pub.smpte.org/doc/
AbleBacon has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
<kurosu> I remember a few years back having to decipher/guess some DNXHD bitstream syntax. Like a flag (interlacing or RGB, can't remember) appearing in what used to be a quantizer... Not sure what document that would be anymore (ST2xx?)
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
<kurosu> Right, alpha was unsupported in ffmpeg
<Lynne> hacked this up to play and rip youtube vp9 streams - https://github.com/cyanreg/ytdash
<Lynne> what's funny is that all tools which exist for h264 stream rips/viewing would probably break atm, since they only check for video/mp4 mime, and always insert cargo-culted annexb inverse bsfs
<Lynne> *would probably break atm if youtube started encoding streams with av1
NotWarcop has joined #ffmpeg-devel
<nevcairiel> most people probably use youtube-dl or yt-dlp which seem to handle other codecs fine
Warcop has quit [Ping timeout: 276 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<Lynne> yup, though every 6 hours there's a cut with yt-dlp
<Lynne> and the quality of h264 is sometimes absurd (1080p30 at 300kbps), while vp9 has much more bits
<Lynne> my only guess is they somehow copied their shitty RC system from libvpx for their ASICs and made it worse
Krowl has joined #ffmpeg-devel
<kurosu> There's YT premium IIRC to offer higher-quality 1080p. Not sure if yt-dlp is able to expose both versions if and when they exist
<JEEB> I think they do
<JEEB> at one point you could receive the premium stuff without login
<Lynne> the "premium" streams yt-dlp exposes are just mp4 dash remuxes of vp9 for iphones, the size difference comes from the huge overhead between webm and fragmented mp4
<Lynne> I'm guessing yt-dlp is wrong and there are real premium streams for registered users
<Lynne> or I'm hoping so, because otherwise it's a waste
Livio has joined #ffmpeg-devel
<kurosu> well, if there are high bitrate vp9 streams (let's dare saying within 30% of the premium h264), then the only benefit is for antique mobiles that don't have a vp9 hw decoder. It would, indeed, be a waste
Krowl has quit [Read error: Connection reset by peer]
<elenril> Lynne: one idea that's been floating around is per-context logging (callback+opaque), which requires valid objects passed to av_log()
<Lynne> elenril: what do you think of creating an AVClass struct locally on stack when logging?
<elenril> it would not be embedded in a real context and so it's invalid
<elenril> unless your context is also on stack
<Lynne> is a context only having an AVClass * not valid?
<elenril> the whole point of having classes and contexts is to allow external callers to interact with the context without seeing the internals
<Lynne> I don't want to let external callers interact with the context, there's nothing in there for them to interact with
<elenril> a custom logging callback, as I said above
<elenril> your change would make adding it harder
<elenril> also, why are you so sure you won't want to add avoptions eventually
<Lynne> how so? if having an AVClass on stack is an issue, I don't mind allocating it and freeing it when I'm done with it, since its only happening during init time
<elenril> no, the issue is it invalidates the whole point of having a logging context
<Lynne> I don't forsee adding avoptions, and I'd be against adding any avoptions that explicitly modify the output, so I'm happy to just delay that what-if to a future version of me
<elenril> which is that the caller can do something with it from their logging callback
<Lynne> like what?
<elenril> 10:55:13 @elenril | a custom logging callback, as I said above
<Lynne> they can only reliably do something pretictable like setting an option if our error messages were fixed, and they're not
<Lynne> oh, as in, modify the avclass of the context itself to add a specific callback for only this specific context?
<elenril> the idea is that avclass would contain an offset to a field where the caller could write callback+opaque
<elenril> then I have per-context logging
<Lynne> okay, but av_tx only prints anything upon init-time, so having a local context in av_tx_init would still allow them to set a custom logging callback what would persist for the entirety of that function, and therefore all the logging av_tx will ever do
<elenril> then there's no opportunity for the caller to any logging setup
<elenril> which is kinda evil
<Lynne> yeah, I realized that just now
<Lynne> alright then, fair enough, I'll do it properly
<elenril> you could also replace av_log() with ff_dlog() and pretend there's no problem
<Lynne> it would allow for debugging, and I did leave provisions for supporting external transforms, like the OSX-provided ones
<Lynne> so an option could be added to switch between them later
<Lynne> I'll consider a dlog too if I don't feel like doing it properly, but I see value in doing that currently
Krowl has joined #ffmpeg-devel
<courmisch> okay so err, how about -ffinite-math-only ?
<JEEB> with a first look does not sound too bad
ccawley2011 has joined #ffmpeg-devel
<courmisch> for FFMIN to be equivalent to fmin(f), I need no-signed-zeros (which is already enabled) and finite-math-only
<courmisch> this affects Arm, Loong and especially RV
<courmisch> wbs: ?
ccawley2011 has quit [Read error: Connection reset by peer]
omegatron has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
dionisis has quit [Ping timeout: 244 seconds]
Livio has quit [Ping timeout: 248 seconds]
APic has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
MetaNova has quit [Remote host closed the connection]
MetaNova has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cone-676 has joined #ffmpeg-devel
<cone-676> ffmpeg Zhao Zhili master:d07da7539d54: avcodec/videotoolboxenc: Fix bitrate doesn't work as expected
<cone-676> ffmpeg Zhao Zhili master:f4e0f4023010: avcodec/videotoolboxenc: Set default bitrate to zero
<cone-676> ffmpeg Zhao Zhili master:719e46f54c0f: avcodec/videotoolboxenc: Fix variable type of AV_OPT_TYPE_BOOL
<wbs> courmisch: what's the question - whether we should add -ffinite-math-only? dunno, maybe? I guess that's more of a question towards those that are familiar with our float codecs
<cone-676> ffmpeg Zhao Zhili release/7.0:a83c1a3db97f: avcodec/videotoolboxenc: Fix bitrate doesn't work as expected
<cone-676> ffmpeg Zhao Zhili release/6.1:a339afbe3c2f: avcodec/videotoolboxenc: Fix bitrate doesn't work as expected
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<kurosu> Isn't ffmpeg main purpose to process audio or videos of NaN cats? Maybe I misunderstood or misheard something in that statement
Krowl has joined #ffmpeg-devel
cone-676 has quit [Quit: transmission timeout]
<Marth64> Sean_McG: as a fellow retro computing fan, willing to help if I can based on the parameters. feel free to ping me
<Marth64> i am in NTSC world if that help
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 248 seconds]
Krowl has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
* courmisch dons bullet-proof vest
AbleBacon has joined #ffmpeg-devel
<Marth64> lolol
dionisis has joined #ffmpeg-devel
<Sean_McG> Sebastinas: I don't have anything concrete (re: the ppc64{,el} stuff), but I might have some cycle to look at it soon.
<Sean_McG> "NaN cats", lol!
<Sean_McG> Sebastinas: makes me wonder if some of the other workarounds are also stale at this point -- I know any of the custom Alpha stuff can be dumped since I/we dropped it... oh wait, did that make it in to 7.0 or was it afterwards?
<Sean_McG> hmmm it was after, nevermind :)
<Sebastinas> Sean_McG: I don't care up anything that is not an release architecture. That's the job of the porters.
<Sebastinas> I only touch those bits when somebody sends a patch
<Sean_McG> fair enough :)
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
Livio has joined #ffmpeg-devel
Sean_McG has quit [Quit: leaving]
Krowl has quit [Read error: Connection reset by peer]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 265 seconds]
Traneptora has joined #ffmpeg-devel
rvalue- is now known as rvalue
Livio has quit [Ping timeout: 260 seconds]
Livio has joined #ffmpeg-devel
<kurosu> courmisch: I'm being pedantic but fabsf would use andss (scalar)
<courmisch> kurosu: godbolt disagrees
<kurosu> Ok, color me surprised
<kurosu> The instruction would then be pointless
<courmisch> a useless x86 instruction, saw nobody ever
<courmisch> anyway, back to watching the same thing as another billion people
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle> Lynne: Got a strange problem. Solved some out of bounds writes and some incorrect logic in encode shader. When I print the avpkt buffer after exec_wait() it seems sane to me, has header a bunch of data and 0xfff padding at the end of each slice. But the .vc2 file itself is filled with zeroes and some 0xfff padding.
<IndecisiveTurtle> I thought it might be related to the vk buffer pool, so I hacked together some code to use the old ff_get_encode_buffer then get a temp vk buffer and copy result to avpkt
<IndecisiveTurtle> But still the same
<IndecisiveTurtle> It's like the data is not getting written to file at all
<IndecisiveTurtle> I'm still using disable_multiplane=1 so image is not filled with zeros if that matters in some way
Krowl has joined #ffmpeg-devel
<Lynne> IndecisiveTurtle: did you invalidate the mapped buffer?
<IndecisiveTurtle> Hm no I should try that
<IndecisiveTurtle> Ok I did a quick test by asking for VK_MEMORY_PROPERTY_HOST_COHERENT_BIT and it worked? Not sure why
<IndecisiveTurtle> Strange that it was able to read it before though
<IndecisiveTurtle> Should I keep the coherent one or better do explicit vkInvalidateMappedMemoryRanges?
<IndecisiveTurtle> Sad still doesn't decode properly. But I think I'm close. Need to see why diracdec receives avkpt with size = 0
Krowl has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 252 seconds]
MrZeus has joined #ffmpeg-devel
Livio has quit [Ping timeout: 260 seconds]
ramiro has quit [Ping timeout: 265 seconds]
ramiro has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
lexano has quit [Ping timeout: 272 seconds]