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
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
abdu72 has quit [Ping timeout: 240 seconds]
cone-699 has quit [Quit: transmission timeout]
Marth64 has quit [Quit: Leaving]
System_Error has quit [Remote host closed the connection]
<fflogger>
[editedticket] rgonzalezfluendo: Ticket #11406 ([avcodec] vvcdec doesn't set pict_type and AV_FRAME_FLAG_KEY in the output) updated https://trac.ffmpeg.org/ticket/11406#comment:1
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
abdu40 has quit [Quit: Client closed]
ccawley2011 has quit [Ping timeout: 245 seconds]
abdu has joined #ffmpeg-devel
<fflogger>
[editedticket] steven1: Ticket #11407 ([undetermined] heap-buffer-overflow vulnerability find in in function mov_read_trun at /ffmpeg/libavformat/mov.c:5944) updated https://trac.ffmpeg.org/ticket/11407#comment:2
Flat has joined #ffmpeg-devel
<fflogger>
[newticket] ffmpeg-fixes: Ticket #11420 ([ffmpeg] macos clang -O3 produce buggy ffmpeg: output is rotated 90 degree.) created https://trac.ffmpeg.org/ticket/11420
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
NiceLeader has joined #ffmpeg-devel
<NiceLeader>
ffmpeg messes up color profile in png encoder according on reddit ffmpeg channel
<BtbN>
probably the same issue that's already on trac and I think haasn already fixed?
<NiceLeader>
help why does github copilot keeps autocompleting "Signed-off-by: Niklas Haas" into my commit messages when I work on my fork code?
<NiceLeader>
lol mmxext inline still in swscale
<haasn>
I'm working on the rewrite as we speak :)
<haasn>
currently benchmarking different proof of concept designs
<NiceLeader>
avx2 or nothing
<NiceLeader>
avx512 even
<haasn>
I am targeting a 512 bit vector size, coincidentally
<haasn>
Just because I benchmarked that to be the best
<haasn>
or rather, a 512 bit primitive size
<haasn>
the slowdown from doing uint16_t tmp[32]; op1(tmp); op2(tmp2); op3(tmp3); is fairly small relative to a "merged" op123() that skips the round trip through L1
<haasn>
and in fact I found that using SoA is on average quite a bit faster that AoS
<haasn>
so the current plan is something like this: 1. unpack input into a struct { uint16_t r[32], g[32], b[32], a[32] }
<haasn>
2. do all operations on this in-place as separate function calls
<haasn>
3. pack back into memory for the next sampling step
<haasn>
op1, op2 etc will use fixed sizes, always operating on exactly 32 pixels
<haasn>
that makes the C code quite a bit faster too, incidentally
<NiceLeader>
i have an idea to do generic pixel transform (and maybe scaling later) via multiple templates in pure C like I did it for af_asf2sf.c sample format conversion filter - sort of alternative to swresample library, ultimate idea is to make everything a filter.
<haasn>
I also played around with using C vectors but I found that in the best case, it is only about as fast as the same autovectorized code the compiler generates with the fixed size arrays
<haasn>
so there is no point in investing time into using C vectors, direct SIMD will be better but the C code alone already vectorizes fairly well
<NiceLeader>
yes, compilers fail it to optimize it in best/fastest way but its still faster then very unoptimized C code, anyway my idea is very heretic
<haasn>
the big open question I currently have (and will need to prototype and benchmark tomorrow) is whether convolutions are better on packed or planar data
<NiceLeader>
and it takes several seconds to compile that filter...
<haasn>
for pixel convolutions you can probably treat the pixel as a uint64_t
<haasn>
if it's packed
<haasn>
just expanding the weights appropriately (and choosing them carefully to prevent overflow)
<haasn>
(which is a given in any case)
<haasn>
so I'm strongly assuming that packed intermediate format is better
<haasn>
even though we want to *output* planar
<NiceLeader>
really? i want actual benchmarks and way to reproduce it on my side
<NiceLeader>
the idea of template approach is to code generic scaler for both packed and planar and do not need to have billions of little functions doing almost same operations over and over again
<BtbN>
so kinda how scale_cuda works?
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<NiceLeader>
i can not see internals of CUDA, but probably use more advance language than C
<BtbN>
It's literally C++ templates
<NiceLeader>
yea, my idea is using C "templates" but I too lazy to start the actual work
<michaelni>
anyone wants some probable malware: (in my inbox) "Hi, I developed a video player used ffmpeg, a high-performance player , see the enclosure, a windows edition, you can install it , if you have any interest you can connect me" "OriginPlayer_Setup_0.0.1.exe"
System_Error has quit [Remote host closed the connection]
<NiceLeader>
attack towards me are far less sophisticated: the last time it was directed directly to me is when they wrote something in this fashion: we have found your open source contributions are worth XYZ coins, follow this link instructions to claim it.
ngaullier has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<NiceLeader>
did anybody received similar mails? did you get your coins?
khrbtxyz has joined #ffmpeg-devel
<BtbN>
I just get an endless stream of absolute and utter nonsense from Duke Abbadon
<NiceLeader>
me too, but that is more/less standard
abdo has quit [Quit: Connection closed for inactivity]
Marth64 has quit [Quit: Leaving]
NiceLeader has quit [Quit: Client closed]
NiceLeader has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
cone-395 has joined #ffmpeg-devel
<cone-395>
ffmpeg James Almer master:fd1772b7475d: avformat/mov: fix potential unsigned underflow in loop condition
<Compn>
i get so much .hu spam because of my email on mphq :D
<Compn>
someone on a .hu domain? spam him forever and ever!
<Compn>
i killfiled duke a while back
<Compn>
bout 100 emails a day telling me my @ffmpeg.org address is going to expire/password update/messages stuck in queue
<NiceLeader>
Compn: your @ffmpeg.org address validity is going to expire soon, tell my your pass so I can extend duration of your mail validity.
<Compn>
my password is 12345678
<Compn>
please validate my email
<NiceLeader>
you just lost you mail account
<Compn>
i shouldve updated it before!
<Compn>
maybe someone emailed me update-and-verify-email.exe
<Compn>
ehe
<michaelni>
"<NiceLeader> did anybody received similar mails? did you get your coins?", IIRC i got several of these, I did look at the last and it was the most insanely insecure way to autheticate, as in put your private ssh key into our binary doker image
ccawley2011 has quit [Ping timeout: 272 seconds]
<NiceLeader>
ouch
<michaelni>
there was an alternative (safe) way to athenticate but it was complex and i didnt do it but i think i would have gotten 500$ worth of some shitcoin
<haasn>
NiceLeader: I can see that coexisting with my "kernel" approach, given functions foo() bar() you can auto-generate a bunch of special cases foo+bar() bar+foo() foo+bar+bat() etc
<haasn>
that just literally expand to foo(ptr); bar(ptr); bat(ptr); with the appropriate inline hints
<haasn>
of course it would probably make more sense to do this on SIMD, not C
<NiceLeader>
both
<haasn>
what I'm working on for now is just the basic foo(), bar(), bat() primitives, and trying to keep the set of primitives as small as possible
<haasn>
most likely in a template so that we can use different bit depths
<NiceLeader>
also, i'm fighting with some YT persona that claims that ffmpeg DV decoder is poor quality (worse than virtuadub DV decoder)
<haasn>
dolby vision?
<NiceLeader>
you wish
<NiceLeader>
Digital Video
<NiceLeader>
very old tech
<haasn>
oh
<haasn>
I was about to say
<haasn>
ENOCARE?
<NiceLeader>
it might be just bad yuv411 upscaler
<NiceLeader>
so i keep asking for DV sample
<NiceLeader>
but still no sample for me
abdo has joined #ffmpeg-devel
jamrial has quit []
jamrial has joined #ffmpeg-devel
NiceLeader has quit [Quit: Client closed]
ccawley2011 has joined #ffmpeg-devel
rinfer has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
rinfer has quit [Quit: Client closed]
^Neo has joined #ffmpeg-devel
cone-395 has quit [Quit: transmission timeout]
abdu has joined #ffmpeg-devel
Flat has quit [Changing host]
Flat has joined #ffmpeg-devel
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
<BtbN>
I'm confused how the current flv de/muxer handles timestamps. It just verbatim writes the values it reads from the stream to the dts/pts fields
<BtbN>
But it never seems to set a timebase, but ffmpegs internal timebase is 1/1000000 seconds, while FLV uses 1/1000
<BtbN>
Ah, it calls avpriv_set_pts_info(st, 32, 1, 1000);
<BtbN>
The fun part is, there is now in theory support for nanosecond accuracy timestamps