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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 255 seconds]
mkver has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
Livio has quit [Ping timeout: 256 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<cone-043>
ffmpeg J. Dekker master:570052cd2a38: avcodec/aarch64/hevc: add luma deblock NEON
stevenliu has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<cone-043>
ffmpeg J. Dekker master:e4c0cdf8df96: avdevice: deprecate opengl outdev
<cone-043>
ffmpeg J. Dekker master:2b17a74df5fb: avdevice: deprecate sdl outdev
bjornw has joined #ffmpeg-devel
stevenliu_ has joined #ffmpeg-devel
stevenliu has quit [Read error: Connection reset by peer]
stevenliu_ has quit [Remote host closed the connection]
bjornw has quit [Quit: Client closed]
bjornw has joined #ffmpeg-devel
Livio has quit [Ping timeout: 260 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Guest38 has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
Poorvagaikar2003 has joined #ffmpeg-devel
Poorvagaikar2003 has quit [Ping timeout: 268 seconds]
rvalue has quit [Ping timeout: 264 seconds]
Livio has joined #ffmpeg-devel
<elenril>
\o/
Guest38 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
bjornw has quit [Ping timeout: 250 seconds]
bjornw has joined #ffmpeg-devel
stevenliu has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
bjornw has quit [Ping timeout: 250 seconds]
stevenliu_ has joined #ffmpeg-devel
<kierank>
jdek: god tier
<haasn>
so does that mean we now have an established precedent for deleting old, broken, unmaintained code?
stevenliu has quit [Ping timeout: 268 seconds]
<kierank>
do sonic next!
<haasn>
jamrial: uh yeah, *none* of the frame side data types have corresponding entries in ffprobe.xsd
<haasn>
this file is more than out of date
<jamrial>
haasn: ok, then don't bother i guess
<jamrial>
i assumed it was up to date
<jamrial>
what is it for then?
<haasn>
I mean I could add all
<haasn>
but to be honest I'm not sure who needs it or how to test my additions or what it's even useful for
<haasn>
clearly the source code is documentation /s
<elenril>
ffprobe sure could use a proper maintainer
<elenril>
I never really understood how its syntax is supposed to work
<haasn>
in this xsd side data is just treated as opaque
<JEEB>
the xsd is supposed to be utilized to verify the output XML schema, no?
<jdek>
kierank: ok
<JEEB>
haasn: E_NOT_SURPRISING
<haasn>
there's some reference to "packetSideDatumType" which is supposed to be a key/value pair but I don't see such values being output anywhere in ffprobe
<JEEB>
try outputting -of xml for a bit and see if it just has a key and value things everywhere?
cone-043 has quit [Quit: transmission timeout]
<haasn>
hmm I think this xsd only corresponds to the structure imposed by writer_print_section_header / writer_print_section_footer
<haasn>
with the actual attributes on each element being implicit
<haasn>
but even that seems very out-of-date, with some things not mapped at all, e.g. SECTION_ID_PROGRAM_STREAM_DISPOSITION
<JEEB>
yea
<JEEB>
it probably is very rarely updated
<JEEB>
since nobody notices it
<JEEB>
it's not tested automagically and all
<haasn>
it would be easier to add if there was an established precedent for how to extend this by new frame side data types but given that they're _all_ currently not implemented..
<haasn>
huh
MisterMinister has quit [Ping timeout: 246 seconds]
<haasn>
somehow print_int() et al translate to <side_datum key="foo" value="bar"> in this file
<haasn>
curious
<haasn>
and using <components> etc. somehow breaks that
<haasn>
ofc <components> doesn't exist in this xsd at all
<haasn>
oh, right, I was the one who added that
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
Livio has quit [Ping timeout: 260 seconds]
stevenliu has joined #ffmpeg-devel
<haasn>
/mem/ffprobe.xml:2: element ffprobe: Schemas validity error : Element 'ffprobe': No matching global declaration available for the validation root.
<haasn>
uh oh
stevenliu_ has quit [Ping timeout: 264 seconds]
<BBB>
removing sonic isn't exactly new
<BBB>
jdek: did you check previous discussions re: that subject?
<BBB>
[FFmpeg-devel] [PATCH] Remove Sonic experimental audio codec
Livio has joined #ffmpeg-devel
stevenliu has quit [Remote host closed the connection]
<jdek>
BBB: why was wavpack removed without a replacement encoder
<BBB>
dunno
stevenliu has joined #ffmpeg-devel
<BBB>
I'm not saying the patch is a bad idea
<BBB>
I'm just suggesting you read the discussion to prevent a repeat outcome
<BBB>
(if you hadn't yet)
<BBB>
I don't care about sonic, I don't use it but like the hedgehog game. the movie sucked
<BBB>
but since it's still there, supposedly someone else blocked removal in 2011
stevenliu_ has joined #ffmpeg-devel
<haasn>
jamrial: well, I added what I could to the xsd (turns out it's orthogonal to my other series) but I can't verify it because no matter what I get errors from xmllint :')
<jamrial>
there was no need, but cool anyway :p
stevenliu has quit [Ping timeout: 272 seconds]
<jdek>
BBB: sure, thanks for the heads up anyway. At some point leaving unused and untested code 'just because' can no longer be justified, IMO at least. We'll see the response this time around I guess
<mkver>
Can we also finally deprecate lowres (for those codecs that do not really contain lower resolution layers (like jpeg2000) already)?
<elenril>
mkver: were there any arguments against?
<mkver>
The lowres-removal from libav has been reverted in lavc because users supposedly want it (to simplify creating thumbnails for preview).
<Lynne>
just send a patch to remove it, no one will disagree
<Lynne>
err, actually nevermind, better deprecate it if you want to
<ePirat>
mkver, would that mean breaking having low-res but faster j2k decoding?
<Lynne>
^^that
<kierank>
I think lowres if properly tested is useful
<mkver>
j2k would not be affected; there would just be a lowres option for it instead of the generic option.
<kierank>
and there are people that use it
<mkver>
kierank: Then why have you never implemented lowres for the mpeg4 studio profile?
<kierank>
because trying to understand the tangled mess of mpeg4/h263 code is painful enough
<ePirat>
mkver, ok because iirc that was useful to be able to play DCPs on not super powerful hw
<elenril>
embrace the MpegEncContext
<jdek>
should we leave codec ids as-is, even for dead codecs? doesn't seem like they should be deprecated
<mkver>
Because removing them is an API break and therefore needs a proper deprecation.
Guest38 has joined #ffmpeg-devel
stevenliu has joined #ffmpeg-devel
stevenliu_ has quit [Ping timeout: 264 seconds]
<jdek>
Im asking if they should even be deprecated at all
<jdek>
i.e. should we just leave them in
<jdek>
seems useful to be able to tell a user that a sample is expected to be dead codec #x even if we cant decode it anymore
<jdek>
otherwise sure, I'll just deprecate the codec id
<mkver>
Ok, leave the id as-is.
<jdek>
ok
stevenliu_ has joined #ffmpeg-devel
stevenliu has quit [Ping timeout: 260 seconds]
stevenliu has joined #ffmpeg-devel
stevenliu_ has quit [Ping timeout: 246 seconds]
Guest38 has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg-devel
stevenliu has quit [Ping timeout: 246 seconds]
<Lynne>
JEEB: could you relink the xhe-aac testsamples?
<Traneptora>
did they really define this in a global header
<mkver>
Yes.
<Traneptora>
figures
<BtbN>
That doesn't look like a public header on first glance
<JEEB>
mkver: got reminded of why I added the configure define as I tried to undo it: the FATE test I add requires that functionality.
<mkver>
Yes, that seems like a legit reason.
Teukka has quit [Read error: Connection reset by peer]
<JEEB>
I got as far as unapplying and `git checkout HEAD~1 -- configure`, and then started scrolling the diff to see if I missed anything :D
BBB has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
BBB has joined #ffmpeg-devel
<BtbN>
Opinions on backporting the memory-alignment patch? It does not seem to have caused catastrophic mayhem on fata for master, and the ub exists in a ton of versions, potentially all of them.
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<JEEB>
jamrial: btw in which cases would you have an avbufferref as-is? in general I think of two cases regarding them in connection with AVFrameSideData: you either just want to create a thing for a new side data in whatever size it's supposed to be (in which case you want to create the side data with a buffer already allocated, or you just want to handle an existing side data entry
<jamrial>
BtbN: wait for 7.0 to be tagged and people testing it
stevenliu_ has quit [Read error: Connection reset by peer]
<jamrial>
JEEB: you can do cll = av_content_light_metadata_alloc(&size); av_frame_side_data_add(&sd, ..., cll, size);
<jamrial>
you can also get such side data from a packet or stream
<jamrial>
err, that signature above is wrong. av_frame_side_data_add() would take an avbufferref, so av_buffer_create in the middle of that
<jamrial>
of course, it could very well just take data+size
<jamrial>
but yeah, you can alloc the usual frame side data types in standalone form, and you can get them from packets or stream's codecpar
<JEEB>
that was actaully a bit funny where you had to give the size where often the side data was of specific size
<JEEB>
so you'd expect a "plz just give me a side data of this type"
<JEEB>
kinda of an API call to be possible
<JEEB>
esp. felt like that with the tests where I just wanted a valid side data entry :D
<jamrial>
there's some side data types where the size can vary a lot, like AVVideoEncParams and the iamf related ones
<JEEB>
"if the struct size is not supposed to be part of the ABI, then why am I having to add sizeof" >:|
<JEEB>
yea, that I know
<JEEB>
there are just some which are known structs
<jamrial>
well, that's why av_content_light_metadata_alloc() and co give you the size :p
<JEEB>
┐(´д｀)┌
<jamrial>
but yes, there's sources other than already existing frame side data such buffers may come from, so the add function need to take a data+size or avbufferref input argument
<JEEB>
first thing that came to my mind if the API couldn't be changed to just utilize a specific size as a request to check a lookup thing where the size function could just give you the right thing w/o manually having to call
<JEEB>
as it just seems like unnecessary complexity with a bunch of cases
Livio has quit [Ping timeout: 246 seconds]
<JEEB>
jamrial: also you still need to have more arguments because AVFrameSideData has metadata
<JEEB>
unless we are talking about different functions
<JEEB>
yea, side_data_from_sd
<JEEB>
the internal add_side_data_to_set_from_buf is something I just refactored out of existing logic, and I don't require it to be public in this patch set
<JEEB>
and side_data_new takes type and size
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<JEEB>
so either I'm confused or the thing you're talking about is separate from what I add for my needs in this patch set
<Lynne>
no choice, have to make xhe-aac a different file and have state + hooks into the main aac decoder at init/decode
<Lynne>
there's nothing shared, other than data structures, and a few of the data structures are not adequate
<devinheitmuell-1>
JEEB: Any chance any of your refactoring will result in supporting multiple pieces of side data with the same type? This has been a problem in the past with KLV stuff.
<JEEB>
AVFrameSideData was like that already
<devinheitmuell-1>
If you manually enumerated the side data fields you could access the data, but the regular getter functions would only return the first instance. Also, it doesn’t work with AVPacketSideData (and I needed similar behavior with both in order to output unregistered SEI data via decklink).
<JEEB>
one could add an iterative function, but my patch set doesn't require that yet
<jamrial>
JEEB: metadata can be copied manually
<jamrial>
my point is, if you introduce a function to add a new side data entry, make it take a buffer of some sort and not an existing side data entry
<jamrial>
because the latter is too restricting
<jamrial>
if i want to add a side data of type frame_cll to an array from a packet that gives me a side data of type packet_cll, with the former signature i can, but not with the latter
<devinheitmuell-1>
There are cases where a side data entry has multiple instances (such as 708 captions), but that model only really works when the size for each entry is the same.
<JEEB>
then that would be two functions I'd say, one for the side data bufref and metadata copy, and another for that :P
<jamrial>
but why would you add two helpers when one can work for both scenarios?
<JEEB>
because why would I want to manually handle the metadata dict?
<jamrial>
it's a single av_dict_copy after the side_data_add() call
<jamrial>
if you want to add both helpers then that's ok. i just know that some people prefer to keep the symbols to a minimum
<JEEB>
sure, and in which case the function without users will most likely get the comment
<JEEB>
it's just a function that the patch set itself had no use for, which is why add_side_data_to_set_from_buf was only refactored and not made public
Livio has joined #ffmpeg-devel
* microchip_
farts
<microchip_>
excuse me
kurufu has quit [Ping timeout: 255 seconds]
kurufu has joined #ffmpeg-devel
<Sean_McG>
damn microchip_, what was in the food?! *holds nose*
<microchip_>
:D
<microchip_>
beans!
mkver has quit [Ping timeout: 246 seconds]
compnn has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]