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.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<thardin>
mov.c is literally the largest source file in lavf >_<
ssfl has quit [Remote host closed the connection]
<thardin>
I think what I might do is create a default segment tree consisting of just one entry, with the usual AVIndexEntry* inside. demuxers that want finite-length segments can override the default "tree"
<thardin>
having to always call av_tree_find() is perhaps a bit awkward, when we know the size of the tree is one. but AVTreeNode is opaque so
<haasn>
Lynne: I think mesa's implementation of VkDrmFormatModifierProperties2EXT for llvmpipe may be buggy
<haasn>
it seems to report all properties as {0}, which coincidentally also makes the debug layers complain
<haasn>
or maybe it only happens under certain circumstances
<haasn>
it's strange
<Lynne>
yeah, the ecosystem's recent support for udmas broke a lot
<thardin>
mov fragments can overlap? aaaa
<JEEB>
they should not...
<JEEB>
each track is *supposed* to be continuous and you'd expect fragments to also follow that
<thardin>
// The end of this new fragment may overlap in time with the start
<thardin>
// of the next fragment in index_entries. Mark the samples in the next
<thardin>
// fragment that overlap with AVINDEX_DISCARD_FRAME
<thardin>
also when random accessing a mov there's no way to know this
<thardin>
unless of course the previous fragment header is parsed to find this out. but then you also have to parse the header before that. and so on
<JEEB>
I recommend sticking "14496-12 pdf 2015" into your favourite search engine
<JEEB>
that is the last freely available version of ISOBMFF
<thardin>
I have it downloaded
<JEEB>
ok
<thardin>
but yeah if the spec says that's not allowed then we should angrily reject files that do so
<thardin>
disciplina disciplina
<JEEB>
there could be something dumb in relation to track timescales vs movie timescales, but that wouldn't be something to do discard frame about, just similar handling to crappy time base containers so that inexact stuff gets fixed up
<thardin>
I'm making some progress at least. using AVTree makes it possible to simplify the code
<JEEB>
yea, mov I've also had ideas of how to step by step simplify it
<JEEB>
such as adding generic templating for box and fullbox parsing
<JEEB>
so not each fullbox function would be trying to handle things slightly differently
<thardin>
I've said many times we should really have a parsing framework rather than the shotgun parsing that permeates the codebase
<thardin>
with lazy eval stuff like fragmented files could be handled much more nicely
<thardin>
also the way it just makes up timestamps in case of EOF is cursed
<thardin>
luckily moving to a fragmented index means dealing with EOF is much simpler. that index fragment just becomes shorter. no need to move entries around
Xe has quit [Remote host closed the connection]
<thardin>
come to think of it, it might just turn out that overlapping samples get tossed out automagically as a result of the fragment lookup logic
<thardin>
gotta go. but mov_read_trun() is looking a lot cleaner
Xe has joined #ffmpeg-devel
<Lynne>
I wonder if its possible to somehow use VP9 in MP4 and include film grain data in
<JEEB>
the first part is just fine, the film grain I'm not so sure about since I'm not sure VP9 bitstream had a generic metadata packet type that they added with AV1 for example.
<Lynne>
haasn: apparently host image copy is also incompatible with DRM modifier backed VkImages
<haasn>
Lynne: in practice or in theory?
<haasn>
also, mesa doesn't seem to support it
<haasn>
at least on amd, I get hostImageCopy = false
<Lynne>
its fairly newly added to mesa
<haasn>
this is on git master
<Lynne>
in practice
<Lynne>
the issue is that the images are required to be non-block compressed
<Lynne>
and modifiers these days often result in compressed images
<Lynne>
and its currently not possible to correlate whether a modifier is compressed or not (and there's no feedback to let you know this in vulkan either)
<Lynne>
there's talk to hook up optimalDeviceAccess to let you know this but nothing yet
<haasn>
Lynne: seems only anv has it
<haasn>
not radv
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<fflogger>
[newticket] ayosec: Ticket #11617 ([avcodec] heap-use-after-free in libavcodec/libaomenc.c found by AddressSanitizer) created https://trac.ffmpeg.org/ticket/11617
Arcitec has joined #ffmpeg-devel
sepro has quit [Quit: Bye!]
sepro has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
microlappy has quit [Quit: Konversation terminated!]
cone-112 has joined #ffmpeg-devel
<cone-112>
ffmpeg Andreas Rheinhardt master:1b5a291dcc24: avcodec/dovi_rpuenc: Use av_unreachable() instead of av_assert0(0)
<cone-112>
ffmpeg Andreas Rheinhardt master:8d45dc858ecf: avcodec/dovi_rpuenc: Avoid intermediate codec par in ff_dovi_configure()
<cone-112>
ffmpeg Andreas Rheinhardt master:0adfe158292f: avcodec/dovi_rpuenc: Use av_cold for ff_dovi_configure init functions
<cone-112>
ffmpeg Andreas Rheinhardt master:27c5e4b39afb: avcodec/libaomenc: Increase code locality
<fflogger>
[editedticket] mkver: Ticket #11617 ([avcodec] heap-use-after-free in libavcodec/libaomenc.c found by AddressSanitizer) updated https://trac.ffmpeg.org/ticket/11617#comment:1
av500 has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
E81l7HT8T7sF9JdA has joined #ffmpeg-devel
E81l7HT8T7sF9JdA has quit [Quit: Leaving]
cone-427 has joined #ffmpeg-devel
<cone-427>
ffmpeg Romain Beauxis master:ba3d4c2ba2b8: libavformat/oggdec.{c, h}: Add new_extradata, use it to pass extradata to the next decoded packet.