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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Warcop has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
qeed_ has quit [Quit: qeed_]
qeed has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 240 seconds]
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
arch1t3cht7 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 246 seconds]
arch1t3cht7 is now known as arch1t3cht
cone-287 has quit [Quit: transmission timeout]
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
<Lynne> JEEB: implemented complex stereo prediction in my repo if you want to test it
MisterMinister has quit [Ping timeout: 272 seconds]
cone-759 has joined #ffmpeg-devel
<cone-759> ffmpeg Brad Smith release/6.0:ce298111177f: avutil/thread: add support for setting thread name on *bsd and solaris
<cone-759> ffmpeg Marton Balint release/6.0:9dbeb1d5d0f4: avutil/thread: fix pthread_setname_np parameters for NetBSD and Apple
mkver has joined #ffmpeg-devel
<cone-759> ffmpeg Brad Smith release/6.1:66f2cf8958ed: avutil/thread: add support for setting thread name on *bsd and solaris
<cone-759> ffmpeg Marton Balint release/6.1:2aad37688ced: avutil/thread: fix pthread_setname_np parameters for NetBSD and Apple
<courmisch> BBB: for correctness it certainly makes sense to validate all branches, and random inputs utterly fail. But the point was about benchmarks, not correctness
<courmisch> BBB: specifically, there is only MMX there and it seems slower than scalar
<cone-759> ffmpeg Rémi Denis-Courmont master:4ad5b9c8db73: lavc/startcode: add R-V Zbb startcode_find_candidate
<cone-759> ffmpeg Rémi Denis-Courmont master:fa47299516d0: lavc/startcode: add R-V V startcode_find_candidate
<cone-759> ffmpeg Rémi Denis-Courmont master:cbe51ebf9305: lavc/vp8dsp: fix .irp use with LLVM as
<cone-759> ffmpeg Rémi Denis-Courmont master:8cea66a73c52: lavc/vp9_intra: fix .irp use with LLVM as
Livio has joined #ffmpeg-devel
<cone-759> ffmpeg Rémi Denis-Courmont master:259c63913782: lavc/vp9_intra: fix another .irp use with LLVM as
Livio has quit [Ping timeout: 260 seconds]
Livio has joined #ffmpeg-devel
bencoh_ is now known as bencoh
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<courmisch> uh, why is fate-source failing now
<courmisch> ah license header
<courmisch> geez
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
<cone-759> ffmpeg Andreas Rheinhardt master:876a25027c59: avcodec/mlpdec: Set AV_FRAME_FLAG_KEY explicitly
<cone-759> ffmpeg Andreas Rheinhardt master:41fc62f2e87c: avcodec/codec_desc, jvdec: JV is not intra-only
<cone-759> ffmpeg Andreas Rheinhardt master:eee88ba0dc67: avcodec/decode: Set KEY flag+pict_type generically for intra-only codecs
<cone-759> ffmpeg Andreas Rheinhardt master:df3cdf4c75b8: avcodec: Remove redundant setting of AV_FRAME_FLAG_KEY, AV_PICTURE_TYPE_I
<cone-759> ffmpeg Andreas Rheinhardt master:2a00d68c09ea: avcodec/yop: Add missing AV_CODEC_CAP_DR1
<cone-759> ffmpeg Andreas Rheinhardt master:95937d631631: avcodec/codec_desc: Mark AVRN, TGQ, PhotoCD, VBN as intra-only
<cone-759> ffmpeg Andreas Rheinhardt master:a7e506fcd844: avcodec/vc1_parser: Check init_get_bits8()
ccawley2011 has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
Livio has quit [Quit: leaving]
cubicibo has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 250 seconds]
Guest1116 has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 240 seconds]
rvalue- is now known as rvalue
<BBB> courmisch: but you understand the point about random input typically not filtering and therefore branch prediction making c faster than it would be for typical video input, right?
<BBB> courmisch: I agree that mmx should be more than a bit faster and I'm not really familiar with the h263 mmx code (who is :D) so I won't comment on that further... you may well be right that the code may be meh, or maybe the auto-vec is doing a good enough job here for the c code on x86-64?
<BBB> (mmx is deprecated and slow anyway on modern platforms)
<BBB> I'm trying to resist getting nerd-sniped into re-doing the h263mmx-deblock code in sse2. I know what you're doing. GOTTA RESIST! SO DIFFICULT
<courmisch> BBB: right but that's basically saying the C code is impossible to bench
<courmisch> (which may be true)
<courmisch> also whoever thougt it a good idea to divide toward zero by a power of two
jamrial has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-759 has quit [Quit: transmission timeout]
auri has quit [Quit: No Ping reply in 180 seconds.]
auri has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<BBB> courmisch: no, no, it's not impossible to bench
<BBB> courmisch: but the input data needs to be "tailored random"
<BBB> instead of random()
<BBB> there's examples of that in vp9, dav1d, and probably a few more
<BBB> I'm not saying you have to do this, don't get me wrong
<BBB> just that if you want the bench data to mean anything, this is one way to get there
<BBB> I'm happy with random data, it's better than nothing :)
Krowl has joined #ffmpeg-devel
beastd has quit [Quit: KVIrc 5.2.2 Quasar http://www.kvirc.net/]
<courmisch> BBB: to bench it accurately you would have to match the "true" distribution of each branch for some definition of truth
<courmisch> the H.263 loop filter is cursed
<courmisch> with comments for all the people who won't be reviewing it
<j-b> good, RPR patches :)
cone-684 has joined #ffmpeg-devel
<cone-684> ffmpeg Rémi Denis-Courmont master:ee1526c05fdf: lavu/riscv: add assembler macros for adjusting vector LMUL
<cone-684> ffmpeg Rémi Denis-Courmont master:233066e85adb: lavc/flacdsp: optimise RVV vector type for lpc32
<cone-684> ffmpeg Rémi Denis-Courmont master:6ab4b92e82ea: lavc/flacdsp: optimise RVV vector type for lpc16
<cone-684> ffmpeg Rémi Denis-Courmont master:463c573e6b64: lavc/huffyuvdsp: optimise RVV vtype for add_hfyu_left_pred_bgr32
<courmisch> Relatively Positive Response patches? Role Play Relationship patches?
<courmisch> Rassemblement Pour la France patches?
<Lynne> have to say its been nice developing with clang's asan always on
<courmisch> say that when your project decided to switch to Qt6 and QML
* courmisch not giving any names
<j-b> courmisch: Reference Picture Resampling I think
<courmisch> is it normal practice to move functions to DSP before there is even one optimisation?
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<Lynne> yes, to keep stuff clean
Krowl has quit [Read error: Connection reset by peer]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<pengvado> BBB: auto-vec isn't the answer, ffmpeg's default cflags include -fno-tree-vectorize
<courmisch> the assembler developers cartel is preventing compilers from taking their lunch!
<Lynne> USAC v2 sent to the ML
<Lynne> you can now listen to the only internet radio which provides UHD radio!
kurosu has joined #ffmpeg-devel
<mkver> Lynne: Why do you include +#include "libavcodec/opusdsp.h" in aacdec_usac.h and why outside of the header inclusion guards?
<Lynne> ah, leftover from my WIP speech coding work
<Lynne> fixed locally
<Lynne> and fixed in my gh repo
AbleBacon has joined #ffmpeg-devel
<BBB> so RPR is scalable references in vp9/av1?
<BBB> courmisch: if it's something you plan to do anyway, might as well write it like that from the start. but everyone has their own preference there, I guess
<BBB> I typically do split in dsp right from the start when I know it'll be simd'ed at some point anyway
<BBB> "the assembler developers cartel is preventing compilers from taking their lunch!" should go on our twitter account :D
<courmisch> BBB: you want the FTC on you so badly?
<frankplow> BBB: Yeah I think they're similar, though I'm not too familiar with AV1's. RPR allows you to change resolutions without an intra frame.
<frankplow> And without an SPS
<BBB> right
<BBB> good to see that in the main profile and not an extension
<BBB> that's where h264/hevc went wrong, it means nobody implements it and so it's useless
<courmisch> VVC replacing AVC any day now
<BBB> call me when it has happened
<courmisch> oh, you were planning for it during your lifetime?
<BBB> :-p
<BBB> poor frankplow maybe not quite used to ffdevsarcasm
<frankplow> I mean VVC not being hot on AVC's heels isn't exactly hyperbole
<frankplow> There seems to be lots of interest in China though
<courmisch> just remember not to invent H.267 and break the law of physics
<courmisch> (yes this is an anime reference)
<jkqxz> I thought AVS3 was China-ersatz-VVC?
<Lynne> ^^
<Lynne> I thought most of the VVC market was india
<courmisch> surely there's AVS4 in the work
<courmisch> can't leave all those engineers empty handed
<Lynne> tencent are literally everywhere
<Lynne> they don't just bet on one codec, they bet on all
<jkqxz> It's the right strategy if you don't care about the IP part and just want stuff to work!
cubicibo has joined #ffmpeg-devel
<frankplow> My impression is that AVS3 is more used for broadcasting and large-scale distribution domestically. Interest in VVC is more from companies exporting from China
<frankplow> If you look at the latest JVET meeting and compare it to a few years a go, the proportion of input documents from Chinese companies has gone up quite a lot by the looks of it
<frankplow> ago*
Krowl has joined #ffmpeg-devel
<frankplow> Maybe that's more reflective of a lack of interest from Western companies though
Livio has joined #ffmpeg-devel
chainik1 has quit [Quit: (╯°□°)╯︵ ┻━┻]
chainik1 has joined #ffmpeg-devel
chainik1 is now known as chainik
beastd has joined #ffmpeg-devel
cone-684 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<ePirat> jkqxz, are you familiar with the ffmpeg hwdec API?
Livio has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 250 seconds]
mkver has quit [Ping timeout: 264 seconds]
<jkqxz> ePirat: Yes, I have used it on occasion.
<ePirat> jkqxz, how much of a bad idea would it be to add a callback to send a proper AVPacket to a hwdec instead of just arbitrary data?
<ePirat> it would simplify having a bsf I need in the videotoolbox hwdec…
<ePirat> and Videotoolbox expects full packets anyway
<Lynne> to which one? start/slice/end callbacks?
<Lynne> or just making a new one
<Lynne> in general, when a hwaccel API needs full packets, they get assembled from all slices given
<Lynne> you kinda have to do this because all of them expect scancodes for each slice which you have to insert manually
<ePirat> probably just a new one… instead of the start/slice/end ones which do not seem to make much sense for VT when I anyway need a full packet
<Lynne> nvdec has a shortcut when all slices are in the same buffer, you should take a look at it
<ePirat> ok thats clearly beyond my understanding
<ePirat> (I have no idea how most typical hwdecs work, VT is rather different)
<ePirat> I just need proper AVPacket for a bsf in VT and do not want to have to packetize all over again in VT…
<jkqxz> My understanding is that videotoolbox is really an offload decoder which doesn't do reordering, so we have it hacked into a hwaccel form?
<ePirat> yeah
<ePirat> that does seem to be the case
___nick___ has quit [Ping timeout: 240 seconds]
<ePirat> jkqxz, I need the vp9_superframe bsf for VT to work properly for VP9
<jkqxz> It has been said in the past that extracting the reordering bit (which is notably very easy for e.g. AV1) and then having it as a standalone decoder might make more sense.
<Lynne> hwaccels generally, if not exclusively, operate on slices or collections of slices, rather than packets
<Lynne> anything else, like something that does parsing, is a decoder, not a hwaccel
<jkqxz> VP9 should have trivial ordering as well? So maybe just make a decoder instead.
<ePirat> jkqxz, mkver pointed out that fallback to sw wouldnt work anymore then though
<Lynne> yup
<Lynne> it should be up to user applications to manage that
<ePirat> also IIUC it would be quite a big API break for the users?
<Lynne> no?
<Lynne> users just have to request that decoder
<JEEB> of course the fun bit is that almost no-one then integrates metadata etc stuff from various decoders, so in that sense hwaccels mean that you get whatever metadata is exposed by the avcodec decoder by default
<ePirat> Lynne, but like in case of ffmeg cli, for vp9 doing ' -hwaccel videotoolbox' would stop working then, no?
<Lynne> is it even working now?
<JEEB> also huh, videotoolbox vp9 has been around for quite a while. has it been broken? :D
<JEEB> it clearly worked with various samples before
<ePirat> Lynne, yes
<ePirat> JEEB, it works with some samples, with others it deadlocks VT
<JEEB> since it got tested before merge as far as I can tell
<JEEB> ah
<ePirat> this has been a known issue
<Lynne> well, rip, it's a hacky way of implementing it
<ePirat> for years now
<galad> on apple silicon or only on intel macos?
<Lynne> should have been a decoder from the start if it takes packets
<ePirat> galad, both
<jkqxz> It only works if the stream does not contain reordered frames?
<JEEB> all of VT formats have been hwaccels
<JEEB> so in that sense VP9 getting added like that as well isn't surprising
<ePirat> jkqxz, it is related to whatever superframes are in VP9
<ePirat> I do not really understand the details tbh
<galad> I never saw any issue on apple silicon, but maybe I didn't test enough samples
<ePirat> galad, can give you a sample
<galad> thanks
odrling has quit [Remote host closed the connection]
<ePirat> ffmpeg -threads 1 -v debug -hwaccel videotoolbox -i test-vp9-long.webm -f null /dev/null
<ePirat> hangs at first frame
odrling has joined #ffmpeg-devel
<JEEB> and yea, how I've seen one of the big problems with not having a hwaccel ends up being that generally different metadata parsed from the bit stream then needs to be separately looked up from the decoder API you're utilizing, which then also ends up causing differences in behavior (and in most cases just because no-one adds any mapping from the decoder API to avcodec API)
<JEEB> so I can definitely see why hwaccels get utilized for hwdec APIs
<ePirat> I wonder if we could make the API work instead of shoving it in a decoder of its own…
<ePirat> though it does seem tricky…
<ePirat> galad, which Apple Silicon CPU do you have?
<jkqxz> Hmm, those are just invisible frames, not reordering.
<galad> M1 and M2
<jkqxz> Feeding the superframe to videotoolbox would require ugly change elsewhere in the decoder, because the hwaccel structure is all about decoding single frames and then separately dealing with when (or if) to shown them.
<jkqxz> E.g. show-existing-frame cases would need to do something quite different, because the earlier output frame wouldn't be visible to the hwaccel logic.
<ePirat> jkqxz, if I had packets I could use the vp9_superframe bsf though?
<ePirat> like, inside of VT
<jkqxz> How would you keep track of the first frame decoded of two inside a superframe in order to later show it?
<ePirat> Ah yeah I guess that would be broken
<jkqxz> (Since presumably it would only return you the second, the one to show immediately.)
<ePirat> I have no idea tbh, I have no sample to test this with where I know what the expected output would be…
<ePirat> but fwiw not deadlocking would be better even if the result is still wrong…
mkver has joined #ffmpeg-devel
<galad> it doesn't hang on the m1
<ePirat> maybe they fixed it there by now with an update
<ePirat> it definitely did when I tested a year or so back
<galad> could be, I test only recently, I suppose it's the same issue as https://trac.ffmpeg.org/ticket/9599 or something else?
<ePirat> yep same issue it seems
<ePirat> galad , indeed just tested again on M1, its fixed there
<ePirat> neat
<ePirat> so my bug report to them wasnt for nothing :D
kurosu has joined #ffmpeg-devel
<ePirat> JEEB, what metadata would it be in case of VP9?
<JEEB> color stuff at least, I think HDR metadata is mostly container bound with VP9
IndecisiveTurtle has joined #ffmpeg-devel
cubicibo has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 264 seconds]
cone-418 has joined #ffmpeg-devel
<cone-418> ffmpeg Michael Niedermayer master:63feed1519c5: avcodec/vp8: Forward return of ff_vpx_init_range_decoder()
<cone-418> ffmpeg Michael Niedermayer master:1b991e77b9b1: avcodec/vp3: Replace check by assert
<cone-418> ffmpeg Andrea Mastroberti master:90ce54804a66: avfilter/smartblur: Added alpha layer support
<cone-418> ffmpeg Michael Niedermayer master:dd5379db5d83: avcodec/vble: Check av_image_get_buffer_size() for failure
<cone-418> ffmpeg Michael Niedermayer master:4a8506c794d9: avcodec/vvc/dec: Check init_get_bits8() for failure
<cone-418> ffmpeg Michael Niedermayer master:6a9302739f5b: avcodec/vqcdec: Check init_get_bits8() for failure
<cone-418> ffmpeg Michael Niedermayer master:4c725df059dd: avcodec/mpeg12dec: Use 64bit in bit computation
<cone-418> ffmpeg Michael Niedermayer master:8fc649b931a3: avcodec/mpeg4videodec: assert impossible wrap points
<cone-418> ffmpeg Michael Niedermayer master:b6b2b01025e0: avcodec/mpegvideo_enc: Fix potential overflow in RD
<cone-418> ffmpeg Michael Niedermayer master:e35fe3d8b9e3: avcodec/mscc & mwsc: Check loop counts before use
cubicibo has quit [Quit: Client closed]
<cone-418> ffmpeg Andreas Rheinhardt master:d7fdd502d602: tests/ref/fate/source: Add exceptions for riscv startcode files
mkver has quit [Ping timeout: 264 seconds]
<BtbN> How does a demuxer return multiple packets per read_packet call?
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<BtbN> The only obvious way I see would be to cache them internally, and then dump out that cache before reading any further. But that seems quite messy
<jamrial> BtbN: ff_buffer_packet?
<jamrial> i added that to split iamf in mp4
<BtbN> The function has no doxy. What does it do?
<jamrial> BtbN: buffers packets that ff_read_packet() then returns in order
<BtbN> hmmm, bit complicated, but should work. I'd have to return the _first_ packet, and buffer up all the others.
<BtbN> Or am I reading it wrong? When ff_read_packet calls ->read_packet(), it's already past the point where it checks the buffer. So the read_packet function needs to return the package it reads first last.
<BtbN> Oh, I might actually be reading it wrong