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
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
zenmov has quit [Ping timeout: 260 seconds]
zenmov has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
System_Error has joined #ffmpeg-devel
zenmov has quit [Read error: Connection reset by peer]
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht0 is now known as arch1t3cht
iive has quit [Quit: They came for me...]
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
cone-093 has joined #ffmpeg-devel
<cone-093>
ffmpeg Scott Theisen master:78c4d6c136e1: libavcodec/mpeg12dec.c: support DVB CC format 0x0502 in user_data
Traneptora has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
cone-093 has quit [Quit: transmission timeout]
MisterMinister has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
haihao has quit [Ping timeout: 252 seconds]
haihao has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 276 seconds]
Traneptora has joined #ffmpeg-devel
zenmov has quit [Remote host closed the connection]
zenmov has joined #ffmpeg-devel
<nevcairiel>
Marth64: have there been any updates on the new BDMV support? I'm kinda interested in deploying that .. sometime, so I don't need to basically reinvent that :D
<Marth64>
nevcairiel: yes, i will send the first version patch this week. had been away from physical drive for a while so i could not prioritize it.
<nevcairiel>
sounds good
<Marth64>
and just wanted to get dvd better
cone-445 has joined #ffmpeg-devel
<cone-445>
ffmpeg Brad Smith release/7.1:ac4c725944d9: libavutil/ppc: Include the hardware feature flags like the other archs
<cone-445>
ffmpeg Sean McGovern release/7.1:0c641ee6610e: libavutil/ppc: defines involving bit shifts should be unsigned
<cone-445>
ffmpeg Brad Smith release/7.1:64e2864cb983: libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv
zenmov has quit [Ping timeout: 260 seconds]
zenmov has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
zenmov has quit [Remote host closed the connection]
zenmov has joined #ffmpeg-devel
zenmov has quit [Ping timeout: 265 seconds]
zenmov has joined #ffmpeg-devel
zenmov has quit [Client Quit]
zenmov has joined #ffmpeg-devel
zenmov has quit [Client Quit]
zenmov has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
zenmov has quit [Remote host closed the connection]
zenmov has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 248 seconds]
cone-445 has quit [Quit: transmission timeout]
rvalue- is now known as rvalue
zenmov has quit [Ping timeout: 252 seconds]
putacho has joined #ffmpeg-devel
zenmov has joined #ffmpeg-devel
putacho has quit [Client Quit]
putacho has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 244 seconds]
putacho has quit [Quit: There is no spoon!]
putacho has joined #ffmpeg-devel
<another|>
hmm... how does libpostproc compare to libplacebo?
<another|>
They seem to do similar things IIUC
<elenril>
do they?
<elenril>
wasn't libpostproc like a deblock filter for mpeg[24]
<another|>
I don't know. I'm skimming the code.
<elenril>
I remember playing with it a little like 20 years ago, back when extra-blurry xvid-encoded anime was a thing
<elenril>
and concluding it was not useful
<another|>
so far it seems to be a collection of a bunch of deblock, dering and deinterlace filters
<another|>
which to my knowledge is all stuff that libplacebo does as well but better and more
<elenril>
oh, I thought libplacebo only does things like HDR
<JEEB>
I don't think it generally does postproc
<JEEB>
it has a whole custom shader system tho
<JEEB>
there you can implement whatever your heart desires
<JEEB>
time to bisect this ffmpeg ~10% perf loss
<another|>
a quick glance at placebo tells me it does scaling, tone mapping, color management, film grain, debanding, deinterlacing and dithering
<JEEB>
yup
<JEEB>
deint I didn't recall out of the box, but indeed it might have received a yadif-like
<another|>
so isn't that a superset of postproc?
<JEEB>
I don't think it has a deblock nor something based on the coded bitstream values (feel free to tell if postproc doesn't do that, I just recall it did that)
<ePirat>
also postproc is CPU, no?
<another|>
ePirat: seems so, yes
zenmov has quit [Ping timeout: 248 seconds]
zenmov has joined #ffmpeg-devel
<haasn>
BBB: do you know if there is some integer 3DLUT code anywhere that I could steal?
<haasn>
I see vf_lut3d but it's for float LUTs only
<haasn>
maybe somebody can give me some feedback about this whole problem in general
<haasn>
I am trying to build a color management layer for swscale
<haasn>
internally it has two components, a I->I tone mapping trasnform (can be computed exactly or stored in a small LUT), and a comlex IPT->IPT 3DLUT (has to be precomputed and stored as LUT)
<haasn>
for maximum 3DLUT efficiency, we generate and store it with polar coordinates, so ICh->IPT instead of IPT->IPT. This gives the best decorrelation of axes
<haasn>
and consequently the smallest 3dLUT, at also makes calculating the 3DLUT more efficient
<haasn>
so to transform colors from e.g. RGB to RGB, we need to roughly speaking:
<haasn>
1. apply EOTF (which is per-channel in all cases except HLG and XYZ. XYZ can be treated as a special case, but for HLG we cannot treat this as a 1DLUT. I could add a special case for HLG though)
<haasn>
2. apply 3x3 matrix (RGB -> LMS) on linear light data, so ideally needing 32 bits of precision if we want 12/14 bit content to survive
<haasn>
3. apply PQ function to each channel (this is awkward to do on integer math, either needing a giant LUT or some kind of quasilogarithmic indexing)
<haasn>
4. apply another 3x3 matrix
<haasn>
then finally we can apply the I->I EETF
<haasn>
and then we would need to somehow move from IPT to polar coordinates which afaict cannot be easily done on integer math
<haasn>
but ofc we could switch to an IPT->IPT 3DLUT at the cost of speed and accuracy
<haasn>
5. do steps 4-1 in reverse
<haasn>
this is a lot of steps involving at least 4 matrix multiplications, 8 look-up tables, and a lot of special cases and headaches
<haasn>
and all of it pretty challenging to do on integer math, especially given that we already have float code written for everything
<haasn>
I was thinking that it makes more sense to precompute a single RGB->RGB 3DLUT from all of the above
<haasn>
but it's challenging to get enough precision here to use on 12/14 bit input data
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: For some reason, didn't get your reply had to check irc logs. Adding a -1 to BUF_BITS - pb.bit_left solves the issue I think but doesnt fix my case
<haasn>
without also totally destroying performance from potentially having to recompute this 3DLUT every single frame (for dynamic tone mapping)
<IndecisiveTurtle>
But let me add a check and printf if it actually happens
<JEEB>
haasn: yea that's the problem with LUTs, great for static stuff since you only have the calculation overhead once
<haasn>
another idea could be to just have three different LUTs: 1. RGB->ICh 3DLUT, 2. I->I EETF, 3. ICh->RGB 3DLUT
<haasn>
that way we can independently recompute the EETF
<haasn>
at the cost of needing to apply two 3DLUTs instead of just 1
<haasn>
maybe that's the best overall approach
<haasn>
1 and 3 would be static
<haasn>
2 dynamic
<haasn>
yeah I think I like the idea best now having written it out
<haasn>
thanks, rubber duck
<JEEB>
:)
Lypheo5 has joined #ffmpeg-devel
bcheng_ has joined #ffmpeg-devel
drv_ has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
<IndecisiveTurtle>
Nope doesnt seem to trigger this at leat on my end, but probably good idea to handle it
<Lynne>
thanks
<Lynne>
could you try enabling the unaligned writer?
<Lynne>
just in case
Traneptora has quit [*.net *.split]
Kei_N has quit [*.net *.split]
paulk has quit [*.net *.split]
BradleyS has quit [*.net *.split]
bcheng has quit [*.net *.split]
Lypheo has quit [*.net *.split]
MetaNova has quit [*.net *.split]
Coinflipper has quit [*.net *.split]
drv has quit [*.net *.split]
okx has quit [*.net *.split]
pheo has quit [*.net *.split]
bcheng_ is now known as bcheng
Lypheo5 is now known as Lypheo
<IndecisiveTurtle>
Sure
<IndecisiveTurtle>
Btw to make put_bits works I changed BUF_TYPE from u64 to u32vec2 to allow for alignment = 4. I hope this wont break ffv1
Traneptora has joined #ffmpeg-devel
Kei_N has joined #ffmpeg-devel
okx has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
pheo has joined #ffmpeg-devel
Coinflipper has joined #ffmpeg-devel
BradleyS has joined #ffmpeg-devel
MetaNova has joined #ffmpeg-devel
rvalue- is now known as rvalue
mkver has joined #ffmpeg-devel
<IndecisiveTurtle>
Some thing after adding #define PB_UNALIGNED to common
<IndecisiveTurtle>
*Same
<Lynne>
no, that should be all
zenmov has quit [Ping timeout: 260 seconds]
<IndecisiveTurtle>
I think the issue with the common one is that is always increments buf by BUF_BYTES
<IndecisiveTurtle>
Like if the bitstream only has 10 bits written, it will align them up to 16 bits and write to 2 bytes but increment a while 8 bytes
<IndecisiveTurtle>
*whole 8 bytes
<Lynne>
but put_bits only writes if the buffer is full
<IndecisiveTurtle>
Yeah making it add to_write instead of BUF_BYTES seems to fix it
<IndecisiveTurtle>
Lynne: Yes but flush_put_bits iirc is for byte-aligning the current written bitstream. In my file I implemented in similar way to put_bits where it aligns buf_bits but only writes when its full, in common it writes some bytes and always increments by full buffer
<Lynne>
oh
<Lynne>
yeah, I forgot about that
<Lynne>
could you send a patch once you're happy with it?
<IndecisiveTurtle>
Yeah np, will send all the common changes I have in separate patch
<IndecisiveTurtle>
How can I test the ffv1 vulkan encoder to make sure it still works?
<Lynne>
-c:v ffv1_vulkan instead of -c:v vc2_vulkan?
<Lynne>
also better insert a format=bgr0 filter in front of hwupload
<Lynne>
oh and use -coder rice
<IndecisiveTurtle>
Thanks
rvalue has quit [Ping timeout: 265 seconds]
rvalue has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
<ePirat>
haasn, jamrial, is it expected that ff_dovi_configure frees sidedata?
<ePirat>
it calls avcodec_parameters_to_context which calls av_packet_side_data_free
<ePirat>
so we have a heap use after free in at least aomenc
<jamrial>
yeah, it shouldn't
<ePirat>
actually I guess the bug is in avcodec_parameters_to_context?
<ePirat>
as If I were to call params_from_context and then params_to_context, it would lead to the same issue of sidedata getting freed, IIUC…
<ePirat>
which seems like quite the API footgun…
<ePirat>
Ah no…
<ePirat>
it frees and reallocates side data…
<ePirat>
so the pointer handed out by ff_encode_add_cpb_side_data becomes invalid…
<jamrial>
ePirat: just move the call to ff_dovi_configure() above the cpb one
<ePirat>
I mean yeah thats the fix for this instance, but tbh this API behaviour is… not great…
<elenril>
ff_dovi_configure() should probably not be doing that
<elenril>
it should just replace the single side data instance it modifies
IndecisiveTurtle has quit [Quit: IndecisiveTurtle]
Krowl has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
<jamrial>
elenril: sent a patch for that
<elenril>
have it open right now
<elenril>
also on the topic of mov demuxer, don't you feel it's getting out of hand?
<elenril>
11k lines
mkver has quit [Ping timeout: 255 seconds]
Krowl has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
<jamrial>
it's a complex format :p
<jamrial>
but i have a patch to merge stts and ctts arrays into one, which should remove some duplication
^Neo_ has joined #ffmpeg-devel
haihao has quit [Ping timeout: 272 seconds]
System_Error has joined #ffmpeg-devel
<elenril>
it could benefit from some more structure
<JEEB>
also both the reader and writer could be made shorter by adding helper functions/macros that handle either Box or FullBox
<elenril>
and/or splitting into more files
<JEEB>
and some things possibly could be split
<JEEB>
I just saw a bunch of functions duplicating FullBox parsing
^Neo has quit [Ping timeout: 276 seconds]
haihao has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<Marth64>
iirc there is some dvd subtitle palette conversion stuff in mov that i think can be removed use dvdclut.h
<Marth64>
i'll have to look again
<JEEB>
hacky dvdsub thing which has the palette in extradata I guess
<JEEB>
does matroska do similar?
<Marth64>
i think it was just mov but i will check
<Marth64>
we have yuv->rgb in dvdclut.h so that one can be axed
<Marth64>
then the other way i can move it there probably
<elenril>
random unrelated fun fact: 'с' in cyrillic corresponds to latin 's'
<haasn>
help why does copilot want to autocomplete "Signed-off-by: Paul B Mahol" into my commit message
<elenril>
lmao
<elenril>
stop stealing paul's code
<JEEB>
lol
<JEEB>
haasn: thank you for giving my first post-dayjob laugh of the day
<Marth64>
which IDE / editor are you using giving ai auto complete in C?
<JEEB>
vscode
<JEEB>
it's an MS product so of course it has integration
<Marth64>
huh. i might just have it disabled then
<JEEB>
although I think noawadays jetbrains also has it
<JEEB>
of course with jetbrains you need to set it up
<Marth64>
i do use jetbrains and its lovely but for ff i use vscode
<JEEB>
yea
<JEEB>
I also utilize VSCode-based thing for FFmpeg dev now
<Marth64>
it is good editor
<JEEB>
least bad open sauce editor at this point :V as much as I dislike it being based on a browser engine
<Marth64>
true
<Marth64>
really, sublime is only missing a sidebar outline viewer (showing methods, fields, etc,) or i would be using it
<Marth64>
there is also geany but it seems to hate my smb shares
<Marth64>
skipping all the exposing properties stuff
<Marth64>
eg. Stream #0:0: Video: h264 (High), yuv420p(tv, progressive), 528x480 [SAR 1707:1405 DAR 18777:14050], Closed Captions, SAR 17200:14157 DAR 1720:1287, 59.94 fps, 59.94 tbr, 1k tbn (default)
<elenril>
I guess
<Marth64>
it just makes me sad to see it there but broken
<Marth64>
probably instead of exposing the field in ffprobe (which doesn't work) it can be deprecated and user can check side data
<elenril>
probably, but I didn't look at it closely enough to have a strong opinion
<Marth64>
i'll rework the set to be (1) the single patch above (2) deprecate the broke field
<Marth64>
and see what happens
<elenril>
AVCodecContext.properties?
<elenril>
it has more flags than just that, doesn't it?
<Marth64>
i would not deprecate that
<Marth64>
just the field in ffprobe - closed_captions
<Marth64>
as it stands the value is always 0 because ffprobe doesn't copy the internal properties and we don't want to expose a way for it to per the comments in patch set above
<Marth64>
so its effectively dead field
<elenril>
ah
<elenril>
I don't object, but others might
<Marth64>
ideally it would work but i can't find a clean way without creating and exposing a avcodec_copy_properties() or similar
<Marth64>
but it doesn't work at all today
<elenril>
AV_DISPOSITION_CAPTIONS?
<Marth64>
how to set from avcodec though?
<elenril>
why from avcodec?
<elenril>
avformat would export it based on the avcodec field
<Marth64>
i would have to modify all demuxers that supports codecs with CC to add the disposition no?
<Marth64>
or do it somewhere more centralized hmm
<Marth64>
"modify all demuxers that supports codecs with CC to add the disposition" <- which does not sound pleasant
<elenril>
maybe I don't understand the problem
<elenril>
can't you do it from avformat_find_stream_info()?
<elenril>
typically you wouldn't want to do it in a demuxer because a demuxer cannot do stream analysis
<Marth64>
avformat_find_stream_info() is a possibility i think
<Marth64>
the user facing problem: ffprobe -show_streams something_with_eia608.mpg ---> closed_captions=0 always, as ffprobe cannot not see the internal AVCodecContext properties when setting up and copying the codec contexts
<Marth64>
so closed_captions field is dead code
<Marth64>
i am not opposed to AV_DISPOSITION_CAPTIONS disposition on the video stream and calling it a day, then the field goes away. probably you are right i can set it in find_stream_info() but will have to look
<Marth64>
this broke somewhere after 4.4.x
<elenril>
ffprobe could in principle print closed_captions based on the disposition value
<elenril>
if I was maintaining it, my policy would be that it should be printing actual media properties and abstract away libav* api details
<elenril>
but I'm not, so...
<Marth64>
then would it hurt to have a AV_DISPOSITION_CAPTIONS_EIA608? i could see a user tagging a video stream AV_DISPOSITION_CAPTIONS if it had burned captions
<Marth64>
then closed_captions=0/1 is truly for eia608
<Marth64>
i personally want to kill the field since side data can be checked but if there's desire to keep it the above route has potential
<elenril>
AV_DISPOSITION_CAPTIONS is currently only defined for subtitle streams
<elenril>
you can propose a new definition for video
<Marth64>
i will play with it
<Marth64>
thx
<elenril>
or you could argue for a new one, I'm probably not the best person to have an opinion
<elenril>
I expect Marton and/or Devin might be more informed
<Marth64>
i will write a message to ML with any applicable proof of concept
<Marth64>
the goal for me is to fix or remove the broken field somehow
<Lynne>
does avctx->thread_count == 0 mean for decoders?
Krowl has quit [Quit: Krowl]
<Lynne>
oh, 0 means auto and the variable gets set automatically, neat
mkver has quit [Ping timeout: 276 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
cone-021 has joined #ffmpeg-devel
<cone-021>
ffmpeg Lynne master:a5e6860a890b: vulkan_decode: fix counting for parallelism
<cone-021>
ffmpeg Lynne master:187fd52864e6: vulkan: fix use of atomics for the current context index
<cone-021>
ffmpeg Lynne master:41f65b7326ea: vulkan_decode: ensure there's at least one context per decode thread
mkver has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
<Marth64>
there, -31 lines in mov
thardin has quit [Ping timeout: 255 seconds]
Krowl has quit [Read error: Connection reset by peer]
thardin has joined #ffmpeg-devel
<Marth64>
elenril: it worked ... will send proof of concept
MrZeus__ has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
cone-021 has quit [Quit: transmission timeout]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11322 ([avformat] ffmpeg stops with exit code 0 during input of hls http stream) updated https://trac.ffmpeg.org/ticket/11322#comment:1
<haasn>
I know it doesn't look like much but you are staring at complete success
<haasn>
I get a 1:1 match between swscale gamut mapping and libplacebo
<haasn>
could not be happier :)
<JEEB>
good job :)
<psykose>
looks pretty
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11168 ([undetermined] When converting an image sequence and wav file to a prores mov using apad and shortest ffmpeg generates random leanth audio streams resulting in larger than expected files.) updated https://trac.ffmpeg.org/ticket/11168#comment:2
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11061 ([ffmpeg] FFmpeg hangs when using apad filter along with shortest flag) updated https://trac.ffmpeg.org/ticket/11061#comment:5
<fflogger>
[editedticket] Timo Rothenpieler <timo@rothenpieler.org>: Ticket #11131 ([ffmpeg] Nvenc b_ref_mode middle does not write max_num_reorder_frames == 2 in SPS) updated https://trac.ffmpeg.org/ticket/11131#comment:9
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11248 ([ffmpeg] mapping of optional streams selected by language broken) updated https://trac.ffmpeg.org/ticket/11248#comment:5
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11168 ([undetermined] When converting an image sequence and wav file to a prores mov using apad and shortest ffmpeg generates random leanth audio streams resulting in larger than expected files.) updated https://trac.ffmpeg.org/ticket/11168#comment:3
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11061 ([ffmpeg] FFmpeg hangs when using apad filter along with shortest flag) updated https://trac.ffmpeg.org/ticket/11061#comment:6
<fflogger>
[editedticket] Timo Rothenpieler <timo@rothenpieler.org>: Ticket #11131 ([ffmpeg] Nvenc b_ref_mode middle does not write max_num_reorder_frames == 2 in SPS) updated https://trac.ffmpeg.org/ticket/11131#comment:10
<fflogger>
[editedticket] Anton Khirnov <anton@khirnov.net>: Ticket #11248 ([ffmpeg] mapping of optional streams selected by language broken) updated https://trac.ffmpeg.org/ticket/11248#comment:6
<ePirat>
haasn, nice
<haasn>
on a side note why does ffmpeg produce such awfully compressed jpgs out of the box
<JEEB>
module defaults probably
<AMM>
Intentionally bad defaults to teach users to always explicitly set them?
<JEEB>
or just not overriding a global default that might be OK for *some* encoder
Marth64 has joined #ffmpeg-devel
<Marth64>
updating tests after adding new disposition is painful
<BtbN>
Hopefully the commit-verb-interpreter works now
<BtbN>
It so far only worked if the git commiter matched perfectly to an account on trac, otherwise it failed with a permission error
realies has quit [Ping timeout: 252 seconds]
<Compn>
haasn, patch welcome ?
rvalue has quit [Read error: Connection reset by peer]