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: 256 seconds]
rvalue has joined #ffmpeg-devel
<mkver>
jamrial: Nicolas Haas?
<jamrial>
ugh, sorry haasn. didn't meant to get your name wrong
Guest52 has quit [Quit: Ping timeout (120 seconds)]
<cone-527>
ffmpeg James Almer master:65a04cae6ff8: avutil/channel_layout: don't clear the opaque pointer on type conversion
Marth64 has joined #ffmpeg-devel
<Marth64>
hello
<elenril>
jamrial: kind of, but I'd rather not add it until there is an actual use case
<jamrial>
elenril: it would need to go after your descriptor set in any case
<jamrial>
and i already add a scenario there, with hevc global side data making it all the way to the encoder
<jamrial>
filters then can (and should) remove the relevant ones if they alter it in a way said side data is no longer valid (scale, color filters, libplacebo, etc)
<haasn>
jamrial: technically it would need to be propagated before query_formats() if you want the format selection to depend on it
<haasn>
but that's not a huge use case as far as I'm concerned
<haasn>
jamrial: what does this patch add vs. just sending one frame through the filter chain and looking at the resulting side data?
<jamrial>
having global side data separate and always available on filters, including (afaik) init(), instead of depending on it being set on all frames before being fed to the filtergraph
Krowl has quit [Read error: Connection reset by peer]
MisterMinister has joined #ffmpeg-devel
<haasn>
but isn't config_props run _way_ after init/query_formats?
<BBB>
I feel that elenril's vote is missing a bikeshed option. I'd like one additional option be added for each of the colors in the rainbow
<haasn>
(and by "way after" I mean "immediately after", judging by avfilter_graph_config)
Krowl has joined #ffmpeg-devel
<Marth64>
mkver: does the subtitle.c patch look better now?
<mkver>
Didn't look yet.
<Marth64>
no worries. thanks for the guidance.
<Marth64>
patch v9 1/5 is the correct one when you do get a chance
kurosu has joined #ffmpeg-devel
<nevcairiel>
who do we smite today for yellowing fate? Lynne? seems so!
* elenril
stabs BBB
<haasn>
I can submit a patch to make yellows green
<jamrial>
it's super trivial, just push the fix
<haasn>
(reference to orangegate)
<nevcairiel>
i was about to prepare that, unless someone has their sources open already =P
<cone-527>
ffmpeg Andreas Rheinhardt master:a8255aa357fd: fate/source: Fix FATE reference file
<mkver>
haasn: What's orangegate?
<haasn>
mkver: libplacebo makes DVD reds appear orange
<haasn>
(mainly because DVD reds *are* orange)
<jamrial>
haasn: ok so, in my set side_data is set on buffersrc after its init() was called
<jamrial>
it will not be available on any of the graph's filter's init() functions either, but will be in query_formats() and config_props() as those are run in avfilter_graph_config() after the graph is assembled
<JEEB>
haasn: primaries difference?
<JEEB>
the classic :3
<JEEB>
people did already know the matrix differences but primaries aren't something most people apparently cared too much?
<nevcairiel>
for a long time players probably didnt care to correct those
System_Error has quit [Remote host closed the connection]
<JEEB>
ye
<JEEB>
I think maybe only QT? since that even did BT.709 adjustment.
Marth64 has quit [Ping timeout: 240 seconds]
Marth64 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<haasn>
JEEB: yup (re: primaries, not re: Qt)
<kepstin>
by "the matrix differences" you mean the fact that different re-releases of the matrix movies have changed the amount of green color-grading, right? ;)
<JEEB>
lol
<BBB>
elenril: what did I do, I'm just trying to be helpful
<galad>
about DVD-Video, does anyone know if there were some standardized colorspaces in the DVD specifications or not? Because I remember I had a DVD recorder that added weird color tags in the bitstream, and now that those values are actually read and used, I don't know if what I am seeing is correct or not.
<Marth64>
its supposed to be only SMPTE170M or BT.624
<Marth64>
but in practice I have seen mixed content literally in the same title
<haasn>
galad: there are PAL/NTSC differences
<galad>
for example one was set to 5-5-5
<haasn>
AVCOL_PRI_BT470BG and AVCOL_PRI_SMPTE170M
<haasn>
5 is PAL
<haasn>
6 is NTSC
<galad>
yes, but the gamma 2.8 transfer function is a bit weird
<Marth64>
there are discs which start with a bt470 junk cell (~1sec) but then become smpte170m, their actual colorspace. IIRC, in my testing on this disc last year, this threw off MPV which started rendering the whole thing bt470 so color differences became obvious throughout playback
<Marth64>
VLC somehow handled correctly, I don't remember the outcome but that one of the reasons why dvdvideo demuxer has -trim option
<kierank>
TIL we support sh4
<jamrial>
i need to decode hevc on my dreamcast
<JEEB>
:D
<Marth64>
i might have to sell mine this year
<elenril>
to pay rent?
<Marth64>
$dayjob has gotten out of hand with overnight prod support and overall downhill. need to move on with my life
<Marth64>
barely sleeping these days
blb has joined #ffmpeg-devel
<elenril>
I hear farmers sleep well
<Marth64>
but i can't abandon my team yet until i get them to a good spot
<Marth64>
:D
<JEEB>
Marth64: hope you find a nice spot as well. props for thinking about others even though technically it probably shouldn't be your headache.
<Marth64>
thank you JEEB. i'm their team lead, i have to, it's one thing to just "up and quit" but i believe in work ethic and these are good people
<Marth64>
plan is to take some down time and start my own thing
<Marth64>
later in 24
AbleBacon has joined #ffmpeg-devel
<haasn>
why do we use a fundamentally flawed voting method for GA votes
<mkver>
What's the flaw?
<haasn>
it's based on ordinal voting, which is provably impossible to make fair in a way that can't be gamed for individual advantage (arrow's theorem)
<haasn>
cardinal voting systems don't have this problem
<haasn>
(to be clear, I am joking, and don't care)
<mkver>
haasn: The AMV encoder currently only allows AV_PIX_FMT_YUVJ420P, not AV_PIX_FMT_YUV420P. Is there a reason that the latter has not been added?
<haasn>
mkver: because we don't yet have a way for codecs to signal the color range they support
<mkver>
But all the other encoders accept both.
<haasn>
all other encoders support both ranges, except mjpeg in strict mode
Gramner has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
Gramner has joined #ffmpeg-devel
andrea_ has joined #ffmpeg-devel
<andrea_>
Hi, how do I submit a patch under the same series as the previous?
<Marth64>
Is it a new additional patch or a fix for an existing patch in the series?
<Gramner>
compilation of lavf/mov_chan.c now produces ~500x "warning: implicit conversion from enumeration type 'enum ShortChannelName' to different enumeration type 'enum AVChannel' [-Wenum-conversion]"
<andrea_>
Really it's the same patch but formatted correctly, I've sent it already but it fails checks - so a fix
<mkver>
Gramner: Already sent a patch for that.
<Gramner>
ah, nice
<Marth64>
andrea_: I am overall new to this too so I could stand to be corrected. But I do not believe it is possible to link it to the previous set cleanly. I think best you can do, is when you send the email, use the MessageID of the patch you are fixing when `git send-email` asks you what patch you want to reply to. This way it is in the same thread at least.
<andrea_>
Marth64: by MessageID you mean the name of the .eml file? I'm using a mail client and not git send-email btw
<Marth64>
andrea_: It would be found in the header of the email you are replying to. So, if I send you an email saying "Hello Andrea_!", and you view it's headers, there is a header titled `Message-ID`
<Marth64>
and that value would be used in your reply, to tie it back to my "Hello Andrea_!" email as a reply. I am not sure about individual mail clients, I apologize.
<andrea_>
No worries, thanks for the help
<Marth64>
good luck!
<thilo>
andrea_: just send a reply to your original message and attach the patch file
<andrea_>
Just wanted to avoid spamming patches ahah
* Marth64
is guilty of this
<cone-527>
ffmpeg Andreas Rheinhardt master:316239096b15: avformat/mov_chan: Use anonymous enum
<andrea_>
thilo: got it, doing that
<michaelni>
mkver, did a "ccache -C" also fixed the slot (all slots where supposed to be new it seems this one was duplciate to a old one)
<michaelni>
lets see if it works on the next iteration
andrea_ has quit [Quit: leaving]
deus0ww has quit [Ping timeout: 245 seconds]
deus0ww has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
* microchip_
farts
<microchip_>
excuse me
___nick___ has joined #ffmpeg-devel
Mister_D has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
rvalue has quit [Ping timeout: 255 seconds]
sr55 has joined #ffmpeg-devel
s55 has quit [Ping timeout: 264 seconds]
sr55 is now known as s55
s55 has quit [Changing host]
s55 has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
kasper93_ has joined #ffmpeg-devel
averne_ has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
zsoltiv__ has joined #ffmpeg-devel
_av500_ has joined #ffmpeg-devel
rodgort` has joined #ffmpeg-devel
staceee_ has joined #ffmpeg-devel
uau_ has joined #ffmpeg-devel
Gramner has quit [*.net *.split]
av500 has quit [*.net *.split]
kasper93 has quit [*.net *.split]
uau has quit [*.net *.split]
zsoltiv_ has quit [*.net *.split]
averne has quit [*.net *.split]
rodgort has quit [*.net *.split]
staceee has quit [*.net *.split]
BradleyS has quit [*.net *.split]
averne_ is now known as averne
staceee_ is now known as staceee
Gramner has joined #ffmpeg-devel
BradleyS has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
ngaullier has quit [Ping timeout: 260 seconds]
___nick___ has quit [Ping timeout: 255 seconds]
HarshK23 has joined #ffmpeg-devel
lesam has joined #ffmpeg-devel
cone-527 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 256 seconds]
___nick___ has joined #ffmpeg-devel
ananas1231 has joined #ffmpeg-devel
ananas1231 has quit [Client Quit]
lfiorini has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
andream has joined #ffmpeg-devel
dykai has quit [Quit: dykai]
<lfiorini>
Hi folks! I'm an computer engineering student from Belgium and I'm interested in starting contributing to ffmpeg with the gsoc this summer. I've read through the project ideas and I really like the x86 vvc decoder. I enjoy low level programming and I am proficient at C but my x86 asm and codecs knowledge are basic. Beside reading the code of the other decoders, are they good ressources out there to learn how to write efficient SIMD optimized x86
<lfiorini>
assembly?
<JEEB>
there were some x86inc.asm tutorials IIRC (which is x264 "framework" for SIMD, which FFmpeg also utilizes)
<JEEB>
basically handles the less interesting stuff such as differences between win or *nix
<cone-176>
ffmpeg Marton Balint master:8c936e9b437a: avutil/timestamp: change precision of av_ts_make_time_string()
<jkqxz>
Lynne: What changes would actually be needed for Vulkan in 7.0 to build on a recentish distribution? (Say Debian stable which has 1.3.239, but feel free to choose a different baseline.)
ramiro has joined #ffmpeg-devel
<j-b>
lfiorini: talk to Gramner .
<cone-176>
ffmpeg Michael Niedermayer master:6f9e90ab0bed: avformat/wady: Check >0 samplerate and channels 1 || 2.
<cone-176>
ffmpeg Michael Niedermayer master:3c43299e9e64: avformat/mov: Check sample_count and auxiliary_info_default_size to be 0
<cone-176>
ffmpeg Michael Niedermayer master:70b26b693e9e: avcodec/vmixdec: Check shift before use
<cone-176>
ffmpeg Michael Niedermayer master:b7cdaff7e23d: tools/target_dec_fuzzer: Adjust RKA threshold up further
<cone-176>
ffmpeg Michael Niedermayer master:c0f4abe2aa01: avformat/id3v2: read_uslt() check for the amount read
<Lynne>
jkqxz: updated headers, shipping the vulkan headers, or some amount of ifdeffery
ramiro has quit [Ping timeout: 264 seconds]
<Lynne>
I wouldn't object to ifdeffery, but I'm not going to do that
<jkqxz>
I do mean with ifdeffery, shipping the standard Vulkan headers with ffmpeg does not seem helpful.
<cone-176>
ffmpeg Mark Thompson master:4743c9e87a62: lavc/get_buffer: Add a warning on failed allocation from a fixed pool
<Lynne>
jkqxz: you'll need to ifdef the coop matrix stuff, and av1
<Lynne>
I think those are the only parts
ramiro has joined #ffmpeg-devel
<jkqxz>
AV1 must be a configure check. Would cooperative matrix be one as well, or should that be at build time?
<Lynne>
if your baseline was older than 239 I would probably kindly ask you to stop using 5 inch floppies instead
<Lynne>
I think you can just use #ifdef SOME_COOP_DEFINE
Marth64 has joined #ffmpeg-devel
lesam has quit [Ping timeout: 256 seconds]
___nick___ has quit [Ping timeout: 256 seconds]
<kierank>
some dreamcast linux people are going to setup a fate instance
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
<Marth64>
keeping sh4 alive i see
Guest52 has joined #ffmpeg-devel
<kierank>
I didn't even know we supported sh4
<wbs>
kierank: I don't think we "support" it actively in any way
<Marth64>
does XP still work?
<kierank>
there is a fate instance that largely passes
<wbs>
as long as the C compiler doesn't do anything broken based on the C code, it should be fine
<Marth64>
nice. I have some old ATI cards I wanted to do captures with and VirtualDub is there but I prefer ffmpeg
<Marth64>
will try it at some point
<Marth64>
less tools to deal with = less things to learn = less headaches
<mkver>
Marth64: XP should only work without threading.
<Marth64>
mkver: that is ok. machine will only do this one thing
ngaullier has joined #ffmpeg-devel
<Marth64>
speaking of threading. I'm looking at #10916 again now
<Marth64>
nervous of someone making this mistake in a production application or whatever accidentally and ending up with a hang
ngaullier has quit [Ping timeout: 256 seconds]
Livio has joined #ffmpeg-devel
<wbs>
jdek: are you ok with me merging the hevc aarch64 tomorrow morning, before the 7.0 branch is made?
lesam has joined #ffmpeg-devel
<jdek>
wbs: sure
System_Error has quit [Remote host closed the connection]
<kierank>
I love the way on twitter people are saying we should use inline asm
<kierank>
it's like being in 2005 again
<wbs>
jamrial: I think 6c2ff982dcbe143a6aa82f9b048a2f6e3ebac986 had a surprise extra effect; previously I could cross compile in an env entirely without a host compiler, now that fails
<Lynne>
kierank: what happened in 2005?
<wbs>
(in a build config that requires no host compilation of course)
<kierank>
Lynne: it was the de-facto way to write asm until x86inc came along later
<jamrial>
wbs: how does it fail?
<Gramner>
if inline asm had widespread support for intel syntax from the beginning it would at least have been somewhat tolerable, but at&t syntax is just atrocious in every aspect
<kierank>
Gramner: I am starting to think we need to write a book or training course
<kierank>
with maybe some token sum from FFmpeg donations or something
<Marth64>
I have a documentation question for AC3 decoder if any AC3 experts around. Is -heavy_compr the same as, or spiritually similar to "RF mode" drc?
<Marth64>
"RF mode" being one of AC3's known DRC options which does heavy compression
<kierank>
the DRC modes are so complicated
<Marth64>
yeah. I was thinking to document it somewhat more, this crossed my mind few days back.
<kierank>
there is a dolby doc somewhere
<Marth64>
It's discussed in a/53 too
<Marth64>
but wasn't sure about ffmpeg's implementation
<kierank>
I doubt we do all the combinations for hotel TVs and stuff
<Marth64>
I think ac3 only has 2 main modes, "RF mode" (high DRC for night viewing) and "Line mode" (medium DRC for rca analog passthrough). Then beneath these modes there are different profiles
<kierank>
yeah from memory there are tons of modes
<kierank>
and each one needs to work
<kierank>
I have some tv at work that I had to put a usb stick in to test
* Marth64
feels dumb
<Marth64>
thought I was replying to ML. replied to self
<Marth64>
yay
<Lynne>
I wish that ac3dec didn't do DRC in the decoder itself but left it as side data
<Lynne>
xhe's DRC is too complex imo to be part of decoding
<Marth64>
yes, I have had these thoughts because sometimes I want to see what tracks are expressing DRC ion
<Marth64>
-ion+on
<Marth64>
right now I don't know of a way to tell
<Marth64>
from ffmpeg alone
<Lynne>
kierank: yeah, x86inc is irreplaceable, maybe that's why everyone else thinks external asm is hard
<Gramner>
kierank: just make a tiktok video, that ought to do the trick
<kierank>
Rofl
<Marth64>
D:
<cone-176>
ffmpeg Michael Niedermayer master:d384af52261f: avformat/avidec: support huge durations
<cone-176>
ffmpeg Michael Niedermayer master:d973fcbcc2f9: avformat/cafdec: dont seek beyond 64bit
<cone-176>
ffmpeg Michael Niedermayer master:50d8e4f27398: avformat/dxa: Adjust order of operations around block align
<cone-176>
ffmpeg Michael Niedermayer master:b8e754525ca3: avformat/iff: Saturate avio_tell() + 12
<cone-176>
ffmpeg Michael Niedermayer master:b792e4d4c772: avformat/cafdec: Check that data chunk end fits within 64bit
System_Error has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
lesam has quit [Ping timeout: 252 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
<cone-176>
ffmpeg Jun Zhao master:5ebcca4e08bf: lavf/movenc: small cleanup for style