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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
DauntlessOne47 has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
DauntlessOne4 has quit [Ping timeout: 276 seconds]
DauntlessOne47 is now known as DauntlessOne4
Kei_N has joined #ffmpeg-devel
DauntlessOne4 has quit [Ping timeout: 244 seconds]
<thardin>
also NLE stuff do not belong in demuxers
<thardin>
actual NLE libraries like melt should deal with that stuff
<JEEB>
virtual time lines wee
<wbs>
mov_build_index? that's the whole logic for the whole demuxer, in one single function :-)
<compnn>
isnt mov.c the largest demuxer ?
<JEEB>
I would not be surprised
<Marth64>
mov is big
<wbs>
it also inherently has got much more freedom in how it decides to return data; sorted by timestamps? or sorted by disk position of the actual samples?
<JEEB>
you could shave various bits off by just standardizing on a function definition macro for boxes and fullboxes etc. but still there's probably way too much logic there which may have been required for some possibly non-comformant samples. or conformant for which the proper implementation was not done and instead some breadcrumbs utilized to get a good enough result
<JEEB>
yup
<JEEB>
many other demuxers don't give such luxurious choices to API clients
<JEEB>
Marth64: also the fact that it's all of QTFF (mov), MP4, 3GPP file format, ISMV in one
<Marth64>
probably not a better way to do that check
<thardin>
vc1-wmapro.ism just happens to be the file I'm currently struggling with
ccawley2011 has quit [Ping timeout: 252 seconds]
<thardin>
I see mov.c does discard indices on switching root (moof). but the logic isn't quite right
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011 has quit [Ping timeout: 246 seconds]
<thardin>
now we're getting somewhere. but I fear I'll have to rebuild the index on every new fragment, which would probably be O(N²)
<thardin>
might just be mov_read_trun() that can't handle reading fragments in a random order
tguillem has joined #ffmpeg-devel
tguillem has quit [Changing host]
tguillem has joined #ffmpeg-devel
<thardin>
FFStream could use support for index table segments rather than just a flat index
<thardin>
a sufficiently generic solution could be used for looking up fragments also, using timestamps as guesses and then either a linear or binary search, as mxfdec currently does for converting EditUnits to absolute offsets
<michaelni>
<haasn> michaelni: can I merge trivial fixes to swscale after nobody replied on ML? <-- yes of course
<BtbN>
"So this is fixing the non-broken and footgun..?" what?
<haasn>
translation: somebody is upset that I touched code that wasn't broken
<haasn>
setting aside the fact that swscale is horrifically broken
<haasn>
and in this case the change served a purpose, which was to restructure code so that I could use av_opt_copy instead, due to the presence of new fields
<Marth64>
i think eia608 could benefit from a AVCodecParser
<Marth64>
that can encapsulate all of the clustered a53 conversion logic in mpeg12dec and any repeated utility functions
<Marth64>
hmm
cone-635 has quit [Quit: transmission timeout]
Everything has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
philipl has quit [Ping timeout: 245 seconds]
Everything has quit [Ping timeout: 252 seconds]
Everything has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
<Marth64>
yes
<Marth64>
i think its feasible to try
<JEEB>
Marth64: not sure new parsers should be written since that interface doesn't let you drop data etc :s I think CBS was supposed to be the new thing to do similar things
<JEEB>
although I might be wrong
<Marth64>
oh np...is CBS basically new API for parser type of work?
<JEEB>
yea, coded bit stream framework
<JEEB>
utilized in bitstream filters as well as I think the VVC decoder I think?
<JEEB>
see libavcodec/cbs.h
<Marth64>
ty I'll check it out
Everything has quit [Ping timeout: 265 seconds]
<JEEB>
alternatively it's just bit stream filters that was talked about in parser context
<jannau>
reproduction with ffmpeg/valgrind requires comenting "+ 16 + STRIDE_ALIGN - 1" in update_frame_pool()
<jannau>
I don't see that .get_buffer2() is requesting this over allocation so it's hard to blame that on the user
<fflogger>
[newticket] adspringer: Ticket #11359 ([ffmpeg] unsharp filter luma sharpening not working for 10 bit pixel format (yuv422p10le and others)) created https://trac.ffmpeg.org/ticket/11359