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
mkver has quit [Ping timeout: 264 seconds]
<Traneptora>
locales lol
<Traneptora>
>that time when libquivi fucked up OpenGL rendering, because calling a libquvi function would load some proxy abstraction library, which in turn loaded a KDE plugin (even if KDE was not used), which in turn called setlocale() because Qt does this, and consequently made the mpv GLSL shader generation code emit "," instead of "." for numbers, and of course only for users who had that KDE plugin installed, and lived in a
<Traneptora>
part of the world where "." is not used as decimal separator.
AbleBacon_ has quit [Read error: Connection reset by peer]
kurosu has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
rooisnoek has quit [Quit: Leaving]
<elenril>
Marth64: sounds very much like 'use timestamps and don't invent imaginary problems'
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
rodgort has quit [Quit: Leaving]
_av500_ is now known as av500
rodgort has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 240 seconds]
Marth64 has joined #ffmpeg-devel
jarthur_ has quit [Quit: jarthur_]
cone-456 has joined #ffmpeg-devel
<cone-456>
ffmpeg Peter Ross master:a2cfd6062c61: av_tx_init: accept NULL scale for RDFT
<pross>
lynne: your rdft is plenty fast enough for my purposes: speech recognition with kaldi k2
<JEEB>
speech recognition, nice
Krowl has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 272 seconds]
elastic_dog has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
elastic_dog has quit [Excess Flood]
elastic_dog has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
cone-456 has quit [Quit: transmission timeout]
<elenril>
mkver: seems to me the whole AV_CODEC_ID_S302M does not really fit into our codec model
<mkver>
+1
<elenril>
as a codec that is, it should be a bitstream filter or inside lavf
<kierank>
302M itself is a codec
<kierank>
as the pcm is not raw
<kierank>
there is some metadata attached on a per sample level and the data is bitreversed
<kierank>
the issue is "tunneled" data inside s302m (and in wav)
Krowl has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 264 seconds]
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
<elenril>
then that should be extracted in the demuxer
<Daemon404>
MQA when
<JEEB>
raw pcm can be in various containers so it might need to be in the raw pcm "decoder"?
<kierank>
exactly
<kierank>
elenril: so the demuxer has to decode, then parse
<kierank>
and it can change on a frame by frame basis
<elenril>
bitreverse is barely decoding at all
<elenril>
better do that in the demuxer and have it output PCM than stuff this nested decoder crap into lavc
<kierank>
gonna have to do that in every demuxer that supports pcm
<j-b>
s302m was a mistake
<elenril>
kierank: how so?
<elenril>
pcm is raw data
<kierank>
JEEB: s302m is fine, s337 is the problem
<kierank>
but it's the same as spdif, same problem there
<kierank>
but ffmpeg doesn't ever need to receive spdif, only send
<kierank>
wav, mp4, ts (ts has even more processig)
<kierank>
and I dunno how you handle the case where it goes back to PCM
<Daemon404>
going to make a format where the audio is stored in the blanking interval
<kierank>
that's literally analogue
<Daemon404>
i kniw but digital.
<kierank>
that's sdi
<Daemon404>
til sdi has blankimg
<kierank>
there is some embedded vendor that has written ffmpeg support for it
<kierank>
it's not very good
<Daemon404>
shows how much broadcasy i do
<kierank>
needs to be backwards compatible with analogue
<Daemon404>
is it official in sdi or a hack?
<kierank>
what?
<kierank>
audio?
<Daemon404>
yes
<kierank>
official
<kierank>
how else will you transport audio
<Daemon404>
in blanking interval i mean
<kierank>
in horizontal blanking
<Daemon404>
delightful
<kierank>
and the rules for muxing are very complex
<Daemon404>
that sounds awful
<kierank>
jdarnley had to independently write a checker from the spec
<kierank>
and I implemented the spec
<kierank>
and we both made mistakes iirc
<Daemon404>
all that means to me is that everything everywhere will be mildly noncompliant
<kierank>
no, they all use the same chip
<kierank>
so it's fine
<Daemon404>
lol
<kierank>
it's when you have to do it in software it's a problem
<kierank>
and some devices care about the weird muxing rules
<kierank>
as I learnt the hard way
<kierank>
12:09:50 <•elenril> better do that in the demuxer and have it output PCM than stuff this nested decoder crap into lavc
<kierank>
what happens if you have a dolby e frame that spans two pcm packets
<Daemon404>
thankful to not touch broadcast
<kierank>
etc etc
<kierank>
webshit is much worse
<Daemon404>
webshit is bad sure but at least it dies quick
<Daemon404>
comparatively
<elenril>
kierank: what difference does it make whether it's processed in lavf or lavc?
<kierank>
I dunno, supporting all the old smart tvs and stuff
<kierank>
elenril: in principle there can be N streams
<Daemon404>
if thr vendor eols then i cease to care
<elenril>
kierank: that's an argument for doing it in lavf though
<elenril>
because demuxer can add streams
<kierank>
sure, but it means duplicating the logic in every demuxer
<elenril>
no?
<elenril>
you have a shared component
<Daemon404>
you still jeed to add it to every demuxer
<Daemon404>
even if shared
<kierank>
and pcm can have lots of variants
<elenril>
the demuxer just toggles the "run these packets through this component" flag
<kierank>
16-bit, 20-bit, 24-bit
<kierank>
each having to be handled
<kierank>
and the tunneled data can be one of each as well
<kierank>
hence the complexity in that patchset
<elenril>
Daemon404: I see exactly one demuxer supporting AV_CODEC_ID_S302M currently
<kierank>
s302m is a packing of wav
<kierank>
that's all
<kierank>
sorry pcm
<kierank>
it can appear in any pcm codec
<elenril>
pcm is raw data
<kierank>
s302m just happens to be the one that an end user is most likely to see as they can pick it off satellite
<elenril>
there needs to be higher level information that tells you to parse it
<kierank>
looool
<kierank>
welcome to the real world
<kierank>
where there isn't
<kierank>
you read every byte
<kierank>
and find a startcode inside
lexano has joined #ffmpeg-devel
<kierank>
and the stream can also go back to pcm when it wants
<JEEB>
yea
<kierank>
you show a film, it goes 5.1 dolby e, you go back to non-film, it goes to pcm
<nevcairiel>
its similar nonsense to dts-in-wav, we have a container for raw data, and we just shove our bitstream in instead
<JEEB>
thus having it as option in the pcm decoder is most realistic (which would enable probing)
<elenril>
JEEB: no
<elenril>
pcm decoder is pcm decoder
<elenril>
pcm is raw data
<elenril>
and besides, i still see no reason it can't be done in a bitstream filter
<JEEB>
yes it would then enable bsf
<nevcairiel>
pcm-in-wav is handled in the demuxer by just changing the codec id, but its certainly not equipped to deal with changing between raw pcm and dts in a stream
<JEEB>
yea the dynamic swap is something we generally don't handle
<JEEB>
so that is low prio IMO
<nevcairiel>
dts-in-wav*
<kierank>
12:25:06 <•JEEB> yea the dynamic swap is something we generally don't handle
<kierank>
12:25:10 <•JEEB> so that is low prio IMO
<kierank>
yeah fair enough
<kierank>
I'm just saying the real world is a dirty place
<JEEB>
yup
ccawley2011 has quit [Ping timeout: 246 seconds]
derpydoo has joined #ffmpeg-devel
<thardin>
is there some way to pass ffmpeg options in yt-dlp?
<thardin>
it makes ffmpeg overly chatty
<thardin>
maybe -q is enough for my purposes
Krowl has quit [Read error: Connection reset by peer]
<thardin>
it also seems -re doesn't handle delays in startup very well
<elenril>
define "very well"
<elenril>
there's -readrate_initial_burst
<thardin>
that's not quite what I need
<thardin>
I'm processing audio from a live stream with a delay of ~30 seconds. processed audio arrives on a fifo. but I think I can just write a small python thing that runs select() on the fifo and once it has data launches ffmpeg via subprocess
<thardin>
possibly after an additional delay of a couple of seconds, so as to guarantee enough of a buffer
haihao has quit [Ping timeout: 272 seconds]
haihao has joined #ffmpeg-devel
<elenril>
>+13 outside
<elenril>
what kind of a winter is this
<JEEB>
o_O
<JEEB>
thankfully it's blowing white today here
<JEEB>
did a run through the forest
<thardin>
trying meat outside so I'm hoping it remains below zero for quite a bit longer
ccawley2011 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 246 seconds]
Marth64 has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
rooisnoek has quit [Quit: Leaving]
<thardin>
woop, my streaming pipeline thing works, and there's no lip flap. the 1.4 second timestamp shift on output is annoying, but can lucikly be compensated with with -itsoffset
<JEEB>
wow, itsoffset works for you?
<JEEB>
it tends to get annulled unless you disable *all* timestamp adjustment by ffmpeg
<JEEB>
only subtitle streams have it working, I think
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
<elenril>
file bugs
<elenril>
send patches
<elenril>
all this shit has no tests, because people who supposedly care about these features cannot be bothered to add tests
<JEEB>
yea I've looked into it and it was a messy mix of things in ffmpeg. if I get the free time I'll poke at it again
<thardin>
going to try streaming to youtube with this and see how that works
<thardin>
woo
<kurosu>
kierank: "no, they all use the same chip" <- so that's what defines the standard, and not the specs, then ? Gotta love this, but happened in the past for other standards...
<thardin>
and yeah the amount of tests is abysmal. just the recent interlacing discussion shows this
<kierank>
14:18:08 <kurosu> kierank: "no, they all use the same chip" <- so that's what defines the standard, and not the specs, then ? Gotta love this, but happened in the past for other standards...
<kierank>
Yes there are two chips, gennum and ti
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 240 seconds]
Krowl has joined #ffmpeg-devel
Marth128 has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth64@173.239.204.116))]
<kierank>
Lol
<kierank>
Where did you get those IP ranges from
<elenril>
whois
<Marth128>
elenril: that was my read too, but I think I'm missing something as I've got some discs demuxing with audio streams starting 500ms or so before the video. with other tools, its only 67ms. I emailed the author of the article to discuss the experience
<Marth128>
thanks for checking it out
<courmisch>
elenril is obviously affiliated with some spy agency
<elenril>
kierank: remember the fun evening with balling?
<kierank>
Ah
<Marth128>
ban hammer
Marth128 is now known as Marth64
<Marth64>
doesnt that nickname troll TRAC too?
<courmisch>
elenril: "the" ? I thought there were several fun evenings
<elenril>
yes
<elenril>
i only remember one in this channel
<courmisch>
and VLC and mpv and presumably some other projects
<elenril>
Marth64: well, broken timestamps are also a fact of life
<elenril>
I don't really know why do people break them so often, but they do
<Marth64>
a sad one D:
<Marth64>
cheaply authored dvds
<courmisch>
elenril: because many players don't care about timestamps?
<elenril>
they are doing it wrong then
<courmisch>
just apply frame rate or sample rate. Who needs additional timestamps!
<elenril>
undoing all the "there is a frame rate" assumptions in ffmpeg CLI/lavf is so annoying
<elenril>
life would have been so much easier if they were never added in the first place
<elenril>
even "CFR" streams have crap like duplicated frames
<elenril>
or, better, duplicated fields
<elenril>
with various weird hysterical-raisins names
<courmisch>
you poke the wrong field to do OSS
AbleBacon has joined #ffmpeg-devel
<Lynne>
what's going on with nginx?
<Lynne>
I saw 2 forks by ex-devs being released today
<elenril>
taken over by the state?
<Traneptora>
I think a lot of devs are jumping ship because of technical decisions made by nontechnical execs