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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
jarthur_ has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 240 seconds]
feiwan1 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
feiwan1 has quit [Ping timeout: 264 seconds]
feiwan1 has joined #ffmpeg-devel
<jamrial>
BBB: is vvc sad for 8bit correct? fate doesn't exercise it
<jamrial>
and the same c function is used for all bitdepths
<jamrial>
the checkasm is limited to 10bit
<sdc>
hi jamrial, the passed values are always 16bit ints even if the video bit depth is 8bit
<jamrial>
i see
<sdc>
I mentioned it in the commit msg of the other patch but I probably should add it to the checkasm commit / leave a comment as well
arch1t3cht8 has joined #ffmpeg-devel
cone-023 has joined #ffmpeg-devel
<cone-023>
ffmpeg llyyr master:d1b96c380826: avformat/mov: avoid seeking back to 0 on HEVC open GOP files
quietvoid has quit [Remote host closed the connection]
quietvoid has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 260 seconds]
cubicibo has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
elenril has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Lypheo2 has joined #ffmpeg-devel
signalhunter7 has joined #ffmpeg-devel
odrling_ has joined #ffmpeg-devel
staceee_ has joined #ffmpeg-devel
jluthra_ has joined #ffmpeg-devel
jkkm_ has joined #ffmpeg-devel
kylophone_ has joined #ffmpeg-devel
Son_Goku_ has joined #ffmpeg-devel
galad_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
skinkie has joined #ffmpeg-devel
odrling has quit [Ping timeout: 268 seconds]
jluthra has quit [Ping timeout: 268 seconds]
jkkm has quit [Read error: Connection reset by peer]
graphitemaster has quit [Ping timeout: 268 seconds]
kylophone has quit [Read error: Connection reset by peer]
galad has quit [Remote host closed the connection]
Son_Goku has quit [Read error: Connection reset by peer]
staceee has quit [Read error: Connection reset by peer]
signalhunter has quit [Read error: Connection reset by peer]
Lypheo has quit [Read error: Connection reset by peer]
skinkie_ has quit [Ping timeout: 268 seconds]
odrling_ is now known as odrling
kylophone_ is now known as kylophone
Son_Goku_ is now known as Son_Goku
Lypheo2 is now known as Lypheo
jluthra_ is now known as jluthra
jkkm_ is now known as jkkm
staceee_ is now known as staceee
signalhunter7 is now known as signalhunter
emersion has quit [Ping timeout: 268 seconds]
graphitemaster has joined #ffmpeg-devel
emersion has joined #ffmpeg-devel
galad_ is now known as galad
<frankplow>
mkver: WDYM by "prefer loop-based iterators"?
<mkver>
Use loop scope for iterators
<mkver>
for (unsigned i = 0;
<frankplow>
Ah, I see
<frankplow>
Is it okay to shadow i in such a case?
<mkver>
IMO yes.
<mkver>
I always use loop-scope when I have to touch the line containing the for anyway, even if it leads to shadowing (of course, it sometimes also allows to remove the outer "int i" altogether).
System_Error has joined #ffmpeg-devel
<frankplow>
Makes sense
Krowl has joined #ffmpeg-devel
OLGA69 has joined #ffmpeg-devel
OLGA69 has quit [Client Quit]
cubicibo has quit [Quit: Client closed]
<Lynne>
courmisch: I figured, but how did they get even less memory bandwidth than a 908?
Krowl has quit [Read error: Connection reset by peer]
cubicibo has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
<courmisch>
Lynne: and single thread scalar perf worse than VF2, which is the current FATE hardware
<courmisch>
although 8 threads would be faster than 4... if there is enough RAM for 8 clangs or gccs in 4 GiB
Krowl has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 240 seconds]
cubicibo has quit [Quit: Client closed]
rvalue has joined #ffmpeg-devel
<Lynne>
a 908 has a single core, this has 8, if the bandwidth is 1/8th of that with all CPUs running, oof
<courmisch>
FATE is on a VF2 with NVMe, not a K230 and a TF card
cone-356 has joined #ffmpeg-devel
<cone-356>
ffmpeg James Almer master:3d1597d3e2ff: x86/vvc_alf: use the x86inc instruction macros
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
I'll try to switch to eMMC and see
<BBB>
I wonder how my last round of review made vvc-sad faster (128x128: 1070 -> 860 cycles)
<BBB>
it was just cleanups or out of loop optimizations
<BBB>
nothing inloop afaics
<BBB>
weird
<BBB>
noise I suppose?
<kurosu>
No idea, but yeah, most x86 numbers are meaningless without enough iterations, or warm up, or... In a way, the START/STOP_TIMER are neat because they try to take into account outliers (that should be due to the OS or processes doing things in benchasm's back, and not merging numbers that could be way too different) to converge to a somewhat nicer number
<courmisch>
x86 is forbidden arcane dark magic, so...
<kurosu>
I wonder how much is due to how deep/precise the OOE is. What is the impact of a context switch, or something that throws off/empties the branch predictor
<Lynne>
impact of a context switch would be quantized to the linux kernel timer frequency
<Lynne>
branch predictor issues would go on top of that, not sure how mitigations are done these days
Krowl has joined #ffmpeg-devel
<jdek>
im seeing up to 50% variance in --bench results even at 262k samples using rdtime, will try rdcycle again but it makes it really hard to bench anything reasonably
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<Lynne>
but its secure
blb has quit [Quit: brb]
blb has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<cone-356>
ffmpeg Andreas Rheinhardt release/7.0:935279b85572: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356>
ffmpeg Andreas Rheinhardt release/6.1:ab4fcc06ce95: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
merbanan has joined #ffmpeg-devel
* Sean_McG
peeks in
<cone-356>
ffmpeg Andreas Rheinhardt release/6.0:90a59f9e4889: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
Krowl has quit [Read error: Connection reset by peer]
<cosminaught>
when it comes to modifying AVDOVIRpuDataHeader do fields have to go to the end? It seems like it would be better to keep them matching the RPU syntax, and I think this was the intention based on the commit that added them
<cosminaught>
> In order to be able to extend this struct later (as the Dolby Vision RPU evolves), all of the 'container' structs are considered extensible, and the individual constituent fields must instead be accessed via offsets.
<mkver>
cosminaught: If you add something in the middle of a struct, direct access to all the fields after the field you just added will no longer work, because their offset changes.
<cosminaught>
understood, but I think this is not intended to use direct access and instead must be accessed via offsets
<mkver>
The constituent "fields" meant here are the substructures, not the individual basic members.
<mkver>
You do not understand: Accessing a AVDOVIDmData via a AVDOVIDmData* works via direct accesses (after all, we provide no getter for AVDOVIDmData.level (or for its offset in AVDOVIDmData)); only retrieving a pointer to the substructures from the containing AVDOVIMetadata* works via offsets.
<cosminaught>
I very well might not understand, that's why I'm asking for clarification
<cone-356>
ffmpeg Andreas Rheinhardt release/4.3:78cf22f3990f: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356>
ffmpeg Andreas Rheinhardt release/4.4:abe6b3fb3819: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356>
ffmpeg Andreas Rheinhardt release/5.0:43de07cd2032: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356>
ffmpeg Andreas Rheinhardt release/5.1:41c2da99f7ed: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cosminaught>
ok, sent v3 which moves these fields to the end and bumps the lavu minor version
Livio has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<JEEB>
cosminaught: basically it would work if the struct's contents would be strictly private and all external users would see would be more or less a void pointer with a named type. and then all access would go through functions or so. (or you don't give API users any ways of accessing what's in the thing
<Sean_McG>
mkver: I had a thought for the patches reads where you are checking for non-zero and returning -- is it possible any of those reads could set errno to EAGAIN?
<cosminaught>
I thought that was the intent based on the commit message, but not seeing anything to facilitate that so perhaps it never materialized (or I misunderstood the intent)
<JEEB>
I don't recall that being there ever since actual RPU parsing got in, since projects like libplacebo would just utilize the struct members
<mkver>
Sean_McG: What patches?
<Sean_McG>
the coverity ones you posted recently, there's quite a few of them
<JEEB>
I have looked at that as well as the dash components
<Sean_McG>
I was talking more generally, but was thinking specifically of ones like avformat/dhav and matroskaenc ff_put_wav_header() ones
<Sean_McG>
if handling EAGAIN in those is not the "done thing" I apologize
<mkver>
Which should errno be set to EAGAIN on ff_put_wav_header() failure?
<haasn>
cosminaught: the intent was for these structs to only be extended by adding members to the end
<haasn>
but for the three structs to be extensible independently
<haasn>
(hence them being variable size with offsets)
<mkver>
The code for the Matroska muxer (and most muxers) would have to be rewritten for it to support the usecase of calling write_header a second time after the first one failed.
<Sean_McG>
OK, fair enough. it was just a thought.
<mkver>
If writing the header fails, the user can analyze the error and retry (with a new AVFormatContext with the necessary parameters set, so that it does not fail this time).
<JEEB>
michaelni: with regards to tests failing with zlib-ng, did I understand it correctly that you and paul are of the opinion that we should invent our own zlib to get bitexact results everywhere? since most of the tests actually failing seem to be failing because the transcoding function always logs the size and hash of the output file
<JEEB>
so I thought the more realistic way would be to add an option to the transcode shell function to allow for disabling of the size/checksum output
<JEEB>
then there's one or so test which logs exact sizes of packets it's encoding, that's less simple although there as well I don't think the exact size of the packet matters?
<JEEB>
as long as the packet has a correct timestamp and can be decoded into the expected image the result should be correct, no?
<JEEB>
it's just being really annoying not being able to run FATE nicely
<JEEB>
(I wonder how fedora works around it since they do package FFmpeg. do they just not run FATE?)
<Sean_McG>
hmmm, do they publish their package build scripts?
<JEEB>
so I would be surprised if it would replace ye olde zlib any time soon
Livio has quit [Ping timeout: 272 seconds]
<JEEB>
oh wait, david heidelberg in that thread seems to note that it's a step-by-step process
Livio has joined #ffmpeg-devel
<cone-356>
ffmpeg Rémi Denis-Courmont master:910d281b2157: lavc/h263dsp: R-V V {h,v}_loop_filter
cubicibo has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<michaelni>
JEEB if zlib-ng results in 5% loss in compression rate it should not be used. Also we have replaced other simple LZ compressors already. If zlib has unstable output it would be nice if it can be avoided. How complex is it to replace it?
<JEEB>
I don't think it in general gave worse results since there were multiple cases where the packet size or such went down?
microchip_ has quit [Quit: There is no spoon!]
<JEEB>
in other words, I recall there being one or couple which went upwards, and then others that went downwards
<JEEB>
as for complexity, I have no idea. haven't mapped what we're utilizing from the library
<JEEB>
also apparently one of the r'aison d'etre of zlib-ng seems to be merging the various SIMD from various other zlib forks
microchip_ has joined #ffmpeg-devel
<JEEB>
and finally, I would like to contribute something else to FFmpeg, not end up rewriting zlib :D
<JEEB>
https://fedoraproject.org/wiki/Changes/ZlibNGTransition > The transition to Zlib-ng aims to enhance the compression efficiency and performance for Fedora while ensuring compatibility with existing packages and libraries.
<JEEB>
so according to something, the overall compression efficiency is *supposed* to be better
<michaelni>
if its too hard then we need to do something else but we should look first maybe its not hard ?
<JEEB>
I'm not really caring about it with regards to likes & dislikes. just that does do somewhat different things, and it feels like the tests that are were not actually testing what the test tests with the bitexactness since in most cases it was just the file size/checksum that changed. then there's one test testing PNG attached image feature I think, and that didn't seem to actually require the packet
<JEEB>
size there to check that it can be parsed as an image and that the provided image could be decoded.
<JEEB>
*tests that are failing
<JEEB>
if it was a test which seemed like it based on the bitexactness for something serious I'd feel a bit different
<michaelni>
is zlib-ng matching zlib if compression is disabaled ?
___nick___ has joined #ffmpeg-devel
<JEEB>
is some test doing bitexactness and setting that mode? if yes, then if that test is not within the ones I posted (and which are available @ https://megumin.fushizen.eu/random/fate-zlib-ng.diff ), it is still working
___nick___ has quit [Client Quit]
<michaelni>
i have no idea, iam just wondering if some mode would still math between zlib and zlib ng
<michaelni>
matCh
___nick___ has joined #ffmpeg-devel
<JEEB>
it could, but I'm not sure how useful that is
<courmisch>
guess who did a debootstrap and did not create a user account or root password
<michaelni>
JEEB, that mode can be used in fate and then noone would have to look at zlib to find out how hard it is to write a native implementatin of what we need
<JEEB>
then you're suddenly testing some parameter path which is not what production users will utilize. in which case encoding and then decoding and checking you're getting the same decoded image back (which some of the tests might already be doing) would be a more realistic check.
c1480 has joined #ffmpeg-devel
<JEEB>
bitexactness is simple to check for, but is it actually helping to verify what these failing FATE tests are testing?
<michaelni>
its better to test the muxer output than not to
<michaelni>
if we canot then we cant but it should not be the first choice
<JEEB>
but it is being tested in many of these cases by them decoding the result?
<JEEB>
because for me the first idea after seeing that most of them were just the default size & checksum which you cannot disable in the shell function, that there could be an option added to the transcoding shell function to control if the test wants that thing to get disabled
<JEEB>
meanwhile the remux function doesn't have that checksum and file size stuff to begin with
<michaelni>
everything should be tested, muxer output demuxer output decoder output
<JEEB>
I agree that everything should be tested, but were these tests that are now failing actually trying to test what is now causing the difference?
<JEEB>
but sure, if you think all these tests explicitly chose to have the size and checksum there, then I will just raise my hands and give up for now
<JEEB>
I will just have to remember each time I try to add something to have the commits updating those FATE test results in all of my branches, and get annoyed when I forget
<JEEB>
btw, the idea of using a specific config or something is not bad, but I just think it makes sense to test the code path that's probably going to get utilized in actual usage :)
<courmisch>
-bash: make: komentoa ei löydy
<courmisch>
funny that configure does not complain about that