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]
<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: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 :)
<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
<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
<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.