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: 252 seconds]
rvalue has joined #ffmpeg-devel
deer3 has joined #ffmpeg-devel
galad has quit [Ping timeout: 272 seconds]
galad has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 264 seconds]
thilo has quit [Ping timeout: 246 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
lexano has quit [Ping timeout: 252 seconds]
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
jamrial has quit []
AbleBacon has quit [Read error: Connection reset by peer]
HarshK23 has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
Martchus_ has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 256 seconds]
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
Teukka has quit [Read error: Connection reset by peer]
<JEEB>
MXF had specific identifiers for crap-in-PCM I think?
<JEEB>
but in general it's just "this is PCM", and you may have bitstream formats inside
<JEEB>
like capture cards that let you capture digital PCM
kekePower has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<haasn>
wtb static_assert()
Krowl has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
<rajivharlalka>
Hi, was taking a stab at this issue: https://trac.ffmpeg.org/ticket/10692 : was able to reproduce the issue and would like to work on it. Can someone give an heads up what I should understand before moving ahead with the actual issue considering it's my first time taking up with ffmpeg.
<JEEB>
I expect that you have already built FFmpeg yourself, possibly with disable-stripping (although the `ffmpeg_g` binary in your build root should always be unstripped so it should allow for debugging)
<JEEB>
then you probably want to check whether that command makes sense and what it should do
<rajivharlalka>
yes, have built and have the ffmpeg_g binary with me.
<JEEB>
after that, you would have to look at the assertion and why it is originally there. if you grasp that understanding, then you should able to figure out whether it is possible to do what the command requests the filter to do
<JEEB>
yea I wanted to ask if there was any other opinions on my patch for that
<JEEB>
since the other alternative is to disable the MESA version if new enough headers are installed. the patch I posted renames the header and its inclusion guards so you still get the MESA defines
<JEEB>
since that should be possible to backport
<Lynne>
it broke?
<JEEB>
that's the same av1 extension build failure
<JEEB>
no, the patch should still work. just trying to grasp how others feel about something like this since it does lead to redefinition warnings for the decoding extension version define (1.0->0.1)
<JEEB>
if nothing then during today I'll apply that patch
<JEEB>
I think it's then to be back-ported to 6.1?
<Lynne>
sure
<JEEB>
kinda surprised that core header includes all of these video decoding headers tho
<JEEB>
since the breakage right now comes from hwcontext_vulkan.h -> <vulkan/vulkan.h> -> vulkan_core.h
<haasn>
elenril: for your WIP patch, am I correct in assuming that only side data types which are currently contained in `sd_global_map` need to be checked against `side_data_prefer_bytestream`, since all others can't possibly be duplicated on the demuxer layer?
<haasn>
or do we foresee this list extending in the future
<haasn>
I guess I might as well change all calls, just to avoid unexpected surprises in the future
<haasn>
although surely something like e.g. AV_FRAME_DATA_S12M_TIMECODE really has no business being set from the demuxer, ever
omegatron has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
cone-961 has quit [Quit: transmission timeout]
tufei has joined #ffmpeg-devel
<rajivharlalka>
might be a silly question, but is there a guide for debugging present? couldn't locate anywhere in the wiki as such.
<JEEB>
just standard gdb or lldb debugging methods should work. for the simplest of things just adding more av_log calls would help.
<kierank>
13:18:24 <haasn> kierank: to clarify, were you saying that literally any container that can store PCM could also contain an AES3 / Dolby E stream in disguise?
<kierank>
13:26:08 <haasn> and if so, how does that work? S302M is specific to MPEG-TS, so how does Dolby E appear in other containers?
<kierank>
using syncwords in the pcm
<kierank>
as it is done in s302m
<jkqxz>
Does that mean that in any full-range audio input you can make a sound which will break things which support this when they try to play it back?
<kierank>
the sync word is very unlikely to happen in actual audio
<jkqxz>
It looks like it even kindly masks out the low bits so you don't need to get the sound exactly right.
<kierank>
it's the same as spdif
<kierank>
in spdif in theory you could make pcm that causes a receiver to change to ac3
<nevcairiel>
dts-in-wav was even nice enough to only use 14 bits of the 16-bit samples so that unaware equipment wouldnt play noise at max volume, these kind of stupid things existed as long as we had audio
<kierank>
it's the fact that it's now tunneled inside other containers is what breaks the FFmpeg model "designed" around avi
\\Mr_C\\ has joined #ffmpeg-devel
<Marth64>
hacks on top of hacks
rvalue has quit [Read error: Connection reset by peer]
any1 has quit [Ping timeout: 255 seconds]
any1 has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
any1 has quit [Ping timeout: 268 seconds]
any1 has joined #ffmpeg-devel
<haasn>
would it be possible to construct a PCM stream that sounds good when played as dolby E *and* when played as PCM
<haasn>
like a codec polyglot
<nevcairiel>
that sounds unlikely
purva has quit [Quit: Connection closed for inactivity]
<elenril>
it walks over all avoptions that are malloced and frees them
<haasn>
oh, I see
<elenril>
otherwise looks good enough indeed
<elenril>
thanks
<elenril>
going to sleep, will look at it in more detail tomorrow or on monday
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
<Lynne>
apparently the nvidia issue I have is due to gcc-14 causing a script check to fail, causing that define to be skipped
<psykose>
which check
<Lynne>
the one that checks for the new api (since 2020)
<Lynne>
and because the C program which does the check is written badly, the new gcc errors enabled cause it to fail, and the drivers think it's a really old kernel
<Lynne>
I also found out it's ISH which causes my boot to fail, but because my machine only lets you do bios changes once, I have to open it up and remove the battery
<Lynne>
wish I could save this nvidia gpu and run mesa on it
<Lynne>
but mainly intel, and all uefi implementation wrappers
Traneptora has quit [Quit: Quit]
<Lynne>
I'd like to show the idiot who programmed the boot selector menu how it ignores my selection on reboot
<jamrial>
<@Lynne> apparently the nvidia issue I have is due to gcc-14 <-- are you using an in development gcc to compile crap for your daily use pc?
<psykose>
i do the same it's a lot of fun
<psykose>
someone has to do the regression testing
<jamrial>
yeah, but maybe not on the machine you use to work :p
<Lynne>
err, gcc is released, enough so that it's packaged by debian
<Lynne>
*gcc-14
<psykose>
gcc-14 isn't released, sid just updates to snapshots earlier iirc
Marth64 has quit [Ping timeout: 256 seconds]
<psykose>
it's mostly frozen
Marth64 has joined #ffmpeg-devel
haihao has quit [Ping timeout: 255 seconds]
haihao has joined #ffmpeg-devel
<mkver>
Would changing a public function to a static inline wrapper around a replacement be an API break?
<BtbN>
API break, potentially. ABI break, yes.
<BtbN>
it's less of an issue than replacing with a macro, but I'm sure there can still be corner cases, like when someone for whatever reason wants a function pointer or tries to dlopen it
<mkver>
I know it is an ABI break, that's why I am asking now.
<mkver>
Actually, the only thing that could be broken were function pointer equality checks.