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
michaelni has quit [Ping timeout: 260 seconds]
Traneptora has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
michaelni has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 268 seconds]
<durandal_1707>
YT: Wikipedia: The New World Order is a conspiracy theory that hypothesizes a secretly emerging totalitarian world government.
___nick___ has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
world government? something that rules over everything?
Wenbin_Chen_ has quit [Remote host closed the connection]
<Lynne>
they'll take one look at us in ffmpeg then surrender immediately
Wenbin_Chen has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<durandal_1707>
stupidity rules over everytyhing
mkver has joined #ffmpeg-devel
jdek has joined #ffmpeg-devel
<cone-838>
ffmpeg James Almer master:eee3b7e2fb06: avformat/mov: zero initialize the index ranges buffer
ccawley2011 has quit [Read error: Connection reset by peer]
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
<Traneptora>
can we create an AVPacket in an encoder from an existing (already-alloced) buffer without an memcpy?
<Traneptora>
libjxlenc.c calls ff_get_encode_buffer followed by memcpy, and ideally I'd like to avoid the memcpy if possible
<Traneptora>
it does have codec cap dr1 but I don't feel too strongly about that being necessary
cworley has joined #ffmpeg-devel
<Lynne>
yes
<Lynne>
don't call ff_alloc_packet or similar, just set the avpacket fields directly
<Lynne>
with an avbuffer created via av_buffer_create you can specify a custom free function
<Traneptora>
in this case the buffer is alloced with av_malloc (and then later resized with av_realloc)
<Traneptora>
so I don't need a custom free function
<Traneptora>
should I just create an AvBufferRef via av_buffer_ref_new_from_data or whatever it's called?
<BtbN>
Do you plan to re-use the same buffer for multiple packets?
<BtbN>
Cause if so: How do you expect that to work out? You got no idea when your caller is done with the previous one, making it safe to modify the buffer again.
<Traneptora>
atm it alloc's one buffer on the first frame sent as a kind of 'working space' and then memcpy's into the avpacket when the packet is complete
<Traneptora>
if another AVFrame is sent to the encoder, it just sets bytes_written to 0 and re-uses the same buffer
<BtbN>
That sounds more like an internal working buffer to me, how does that relate to how the output packet gets allocated?
<Traneptora>
it prevents me from having to malloc a working buffer every frame, but it does incur a memcpy each frame. I don't know which is generally a preferable situation
<Lynne>
Traneptora: you can use av_buffer_default_free as the custom free callback
<Lynne>
it just calls av_free()
<Traneptora>
BtbN: the output packet is allocated via ff_encode_get_buffer
<Traneptora>
and then memcpy'd over from the working buffer
<BtbN>
But wasn't your question how to avoid that?
<Traneptora>
Yea, the consequences of avoiding it would be allocating a new working buffer every frame
<Traneptora>
I don't know if I actually want to do that
<BtbN>
Given the user can use a custom allocator, an internal working buffer and copying out of that sounds much better to me
<Traneptora>
so the current behavior is better than allocating a working buffer each frame and then handing it off to the packet?
<BtbN>
most definitely
<Traneptora>
I see, so there's nothing that needs to be done
<BtbN>
If the user just re-uses the same packet again and again, you'd have zero allocations
<Traneptora>
makes sense as well considering that the external library doesn't have a way to tell you how much space it needs, just that it needs more space
<Traneptora>
so I start with 4096 and double it until it fits
<BtbN>
wat?
<BtbN>
That sounds wrong on so many levels
<Traneptora>
ye, libjxl can error out with NEED_MORE_OUTPUT but the function can't tell you how much more it actually needs
<BtbN>
What is their intended approach there?
<Traneptora>
atm I malloc loop with realloc until it fits
<BtbN>
exponential increase sounds like a DoS waiting to happen
<Traneptora>
well not quite, this is an encoder
<Traneptora>
so worst case scenario is random data, which is inflated slightly
<BtbN>
not random, but specifically crafted to make it go mad
<Traneptora>
the library already uses like 10x the memory of an uncompressed image
<Traneptora>
so it's relatively speaking not the problem
<Traneptora>
libjxl encoder's unbelievable memory usage is what drove me to write my own low-memory encoder
<BtbN>
The whole library is such a clusterfuck, I considered removing it from my builds
uau_ is now known as uau
<Traneptora>
oh they broke the API last week too and when I pointed it out they were like, "can you patch ffmpeg to work with the new one"
<Traneptora>
> not random, but specifically crafted to make it go mad
<Traneptora>
if you specifically craft a bitstream to cause the encoder memory to balloon it will end up crashing the library long before it crashes ffmpeg due to the malloc loop
<Lynne>
have they not heard of ABI/API stability?
<Traneptora>
they have, but they don't have fate tests for this kind of thing
<Lynne>
whatever garbage bin they sit next to drinking beer, it's the same one that the glslang team uses
<Traneptora>
it's the kind of google stuff where they include everything as a submodule in tree on clone
<Traneptora>
same as glslang
<durandal_1707>
you all are on FFlabs paylist
<Traneptora>
if only
<cone-838>
ffmpeg Stefano Sabatini master:f8b14d8bee16: lavf/dashenc: sort options by name