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
iive has quit [Quit: They came for me...]
Samillion has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
cone-745 has joined #ffmpeg-devel
<cone-745>
ffmpeg Peter Ross master:6bf9252807c8: avformat/Makefile: include object files for image_vbn_pipe demuxer
<cone-745>
ffmpeg Peter Ross master:7aeae8d1ae84: avcodec/Makefile: include aom_film_grain.o file for h264_sei component
Marth64 has quit [Quit: Leaving]
thilo has quit [Ping timeout: 244 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht6 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 244 seconds]
arch1t3cht6 is now known as arch1t3cht
<Mirarora>
just tried to compile git master and it failed with a few errors all referencing src/libavcodec/amfenc_av1.c:467:57
<Mirarora>
actually i take that back there is more than 1 number
<Lynne>
yeah, none of us actually test or run with amf turned on, its all amd's thing
<Guest84>
is libav still necessary to acess low level api?
<Guest84>
i would like to build a static binary but find it hard to set up the build correctly.
<Guest84>
most confusing is the relationship between libav and ffmpeg
<compnn>
Guest84, the top line of that document explains what the page is
<compnn>
"First some disambiguiation: there is a fork of FFmpeg called Libav. There is also a library system that underlies FFmpeg itself, called libav. This page is about the library libav, which is a part of FFmpeg. "
<compnn>
libav* in this case, refers to libavcodec, libavformat, libavutil, libavfilter etc. which are part of the ffmpeg project
<Guest84>
the wording FFmpeg the organisation and ffmpeg the tool
<compnn>
yes we agree the now-dead fork name was confusing.
<compnn>
yes the project is called ffmpeg and the main tool is called ffmpeg :D
<Guest84>
i do have to provide libav* separately, building ffmpeg.
<compnn>
i think you just want ./configure --enable-static , no ?
<Guest84>
correct
<compnn>
then do that. you dont have to provide anything
<compnn>
and that trac url is not for you
<Guest84>
well the intent arises from the error: CFFmpeg/avutil_shim.h:6:10 'libavutil/avutil.h' file not found
<compnn>
and this channel is not for building questions, you want to ask in #ffmpeg . this channel is for development
<Guest84>
sorry about that
<Guest84>
i am on a webclient and have issues joining the correct channel
<compnn>
no problem :)
* compnn
will be afk brb
<Guest84>
it demands me to "log in" can you believe it :P
cone-745 has quit [Quit: transmission timeout]
jamrial has quit []
<compnn>
ok i back
<compnn>
also "CFFmpeg" i think is some other project/frontend to ffmpeg
<compnn>
so you'll have to follow those instructions to get that working
<haasn>
as an expirement I tried plugging libzimg into the swscale API as an optional backend
<haasn>
but so far the results seem.. not promising
<haasn>
swscale has a lot of special converters that are by far more optimized
<haasn>
so at least in the general case it's not a great idea to just use zscale out of the box
<haasn>
it's also strangely limited
<haasn>
e.g. it can't handle packed input at all without writing a bunch of dedicated unpacking routines that essentially boil down to converting them to planar first
<haasn>
whereas swscale can directly decode packed inputs
<haasn>
I also get worse accuracy
<haasn>
e.g. going from 96x96 down to 64x96 and back gives me an MSE of ~8 instead of ~4.5 from swscale
cone-833 has quit [Quit: transmission timeout]
<haasn>
with the same dithering and scaling settings
<haasn>
while also being slower
<haasn>
I imagine it may have something to do with everything in zscale going through float afaict
<haasn>
the only thing it consistently does faster is init, but the margin is tiny (~1 us faster on avg)
<haasn>
and the swscale init code is a nightmare
<haasn>
kasper93: there is an incredible amount of extremely low hanging fruit on the ffmpeg trac
<haasn>
I'm talking about 13 year old bugs that took all of 30 mins to debug and fix
<haasn>
if not for the complete and utter lack of anybody caring about swscale
<JEEB>
yea, swscale had a reputation which might or might have not have been valid
<JEEB>
for example I was afraid to set flags in vf_scale because I did not know did swscale do matrix only (probably?), or did it also poke at primaries when doing some conversions
<fflogger>
[editedticket] bubbleguuum: Ticket #11363 ([avcodec] [Android] MediaCodec decoders/encoders do not work on Pixel 8 Pro (No output buffer available)) updated https://trac.ffmpeg.org/ticket/11363#comment:2
MyNetAz has quit [Read error: Connection reset by peer]
MyNetAz has joined #ffmpeg-devel
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
<fflogger>
[newticket] marcusmueller: Ticket #11364 ([ffprobe] µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample) created https://trac.ffmpeg.org/ticket/11364
Marth64 has joined #ffmpeg-devel
tufei has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
<haasn>
Should I nominate myself for the CC?
<BBB>
isn't the election finished already?
<elenril>
tbh i see little point in CC existing at all under the circumstances
<jamrial>
BBB: no
DauntlessOne4 has joined #ffmpeg-devel
<elenril>
the circumstances being that the person on whom CC powers technically depend is 1) calling for CC to be ignored and bypassed 2) technically facilitates it
<another|>
IMHO there's a fundamental problem of distrust. Unless that is solved, everything is just bandaids over symptoms.
<another|>
Which is a big part of why I think face-to-face meetings are important.
<Marth64>
conference calls over ffmpeg is it possible?
<Marth64>
kidding.. I do want to come to a booth or event though
<elenril>
Marth64: fosdem in just slightly over a month
<Marth64>
yeh, I am trying to arrange for time off
<Marth64>
fingers crossed that my current project ships and I can take the time
<Marth64>
if not the Vegas thing is realistic
<Marth64>
today will be fun. digging up old PCI cards to test the ivtv thing
<Marth64>
happy CC month. Christmas Carols, Community Committee, Closed Captions
<Marth64>
all the things cc
<JEEB>
elenril: ah yes, I procrastinated on getting my flights for FOSDEM... need to do that before the year ends
<JEEB>
(granted, it seems like flights to brussels don't differ too much)
<JEEB>
since it's mostly EU officials flying
<bcheng>
seemingly there's no way to build ffmpeg (the actual tool) without thread support right?
<elenril>
bcheng: correct
<elenril>
any reason you need that?
<bcheng>
I'm debugging an issue with the vaon12 driver (translates vaapi to d3d12), that isn't threading related. But with newer ffmpeg, it seems like it always trips the threading issue, which is blocking the debug of the original issue.
<bcheng>
-threads 1 isn't sufficient, seems like the bitstream download is always on a separate thread from the encode op
<elenril>
might be simpler to use one of the transcoding examples
<bcheng>
ah true, thanks for the suggestion
<fflogger>
[editedticket] Balling: Ticket #11364 ([ffprobe] µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample) updated https://trac.ffmpeg.org/ticket/11364#comment:1
<BBB>
jannau: how hard would it be to change the simd to read 11 pixels instead of 12, thus not overflowing at all?
<BBB>
jannau: not a requirement for your patch, just wondering
<JEEB>
elenril: you made all stream options be set at a specific early'ish point in ffmpeg, right?
<JEEB>
since right now all the things that get set from the input AVFrame no longer can be overridden it seems (color stuff etc)
<jannau>
BBB: extra load instruction and extra instruction to shuffle the trailing 3 or 7 pixels into place. all widths are affected not just 4. on arm32 also additional gp registers for the load
<BBB>
we have to set that off against the extra emu_edge check for every inter block
<BBB>
one could argue that it's better to make w=4 h slightly slower at the benefit of one lesser emu_edge check
<BBB>
(I'm not in a position to argue which is better, you obviously are. but I don't think w=4 h-only inter blocks are super-common relative to inter blocks in general?)
<jannau>
BBB: width 8, 16, 32 and 64 over read as well one pixel. I made w=4 already slightly slower to not over read 5 pixels
___nick___ has quit [Ping timeout: 272 seconds]
<fflogger>
[editedticket] marcusmueller: Ticket #11364 ([ffprobe] µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample) updated https://trac.ffmpeg.org/ticket/11364#comment:2
<fflogger>
[editedticket] marcusmueller: Ticket #11364 ([ffprobe] µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample) updated https://trac.ffmpeg.org/ticket/11364#comment:3
<fflogger>
[editedticket] Balling: Ticket #11364 ([ffprobe] µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample) updated https://trac.ffmpeg.org/ticket/11364#comment:4
<BBB>
jannau: ah, ok, didn't realize it was all widths. ok then, understood, thanks
<jannau>
it loads just once block width + 8 bytes because that fits well in vector loads and shifts the data in registers
<jannau>
not clear if the x86 method would be less instructions and due to the lack of immediate offset vector loads it would use 8 gprs for the load, i.e. only possible on arm64
<fflogger>
[editedticket] MasterQuestionable: Ticket #11283 ([avfilter] "aloop" filter somehow gave misalignment in 48 KHz Stereo WAV) updated https://trac.ffmpeg.org/ticket/11283#comment:20