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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
minimal has quit [Quit: Leaving]
iive has quit [Quit: They came for me...]
<cone-661>
ffmpeg James Almer release/7.1:4c78a357d082: avcodec/lcevcdec: don't try to write to output frames directly
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
_whitelogger has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 264 seconds]
ngaullier has joined #ffmpeg-devel
<kierank>
Literally a year of tweeting about asm and still hundreds of messages saying the compiler knows better
quietvoid has quit [Quit: No Ping reply in 180 seconds.]
mkver has joined #ffmpeg-devel
<fflogger>
[newticket] r3d: Ticket #11604 ([ffmpeg] Infinite loop filter does not shutdown gracefully on SIGTERM) created https://trac.ffmpeg.org/ticket/11604
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
quietvoid has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
<fflogger>
[newticket] VotwianGamingVN: Ticket #11605 ([undetermined] h264_qsv codecs not working even though hardware supports them (Intel HD Graphics 2500)) created https://trac.ffmpeg.org/ticket/11605
<BBB>
michaelni: thanks for the qp command, I'm not sure why I couldn't find it, happy to see it still works
<nevcairiel>
<softworkz> don't know - maybe he patched it.. << patched? its a git config that you can even set per-repository to just checkout all files without the EOL conversion, which is a common requirement for handling linux-y project on windows
<nevcairiel>
there is also no problems using that when editing sources, unless you have no control over your editor. any good editor will adapt to the line-ending in the file, or you can configure it to do so (or use autocrlf=input in Git to strip CRLF when commiting, but not re-introduce it when checking out)
jamrial has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
<beastd>
nevcairiel: i agree. you should definitely set autocrlf=off . the default is just bad on git for windows. it's the first thing i tell people to change in in their config when teaching them git on windows machines.
<wbs>
I agree. that said, having proper .gitattributes so that things work without that setting is also nice - it's not a case of "fate tests have never worked for anybody on windows before this change"
<wbs>
s/it's not/but in any case - it's not/
arbitercoin has quit [Ping timeout: 252 seconds]
<beastd>
guess the patch is ok if i understood the eol git attribute correctly from its docs, but it's a bit weird i would say
<beastd>
maybe it would be better to unset the text attribute for those files instead (if that's possible)
<wbs>
if the file actually is binary, that's a good idea, but if the file actually is text, it makes for terrible diffs if the files are marked as non-text
kasper93 has quit [Read error: Connection reset by peer]
<beastd>
wbs: yeah, then eol is better because of diff
kasper93 has joined #ffmpeg-devel
<beastd>
was thinking more that it could actually be that we want LF in one of the files and CRLF in another. but defining them all as eol=lf will be fine for both cases IIUC (even if it's a bit misleading)
softworkz has joined #ffmpeg-devel
softworkz has quit [Read error: Connection reset by peer]
softworkz has joined #ffmpeg-devel
<softworkz>
nevcairiel: "patched" was my first thought only - I'm aware of autocrlf=input and also that most editors will adapt to existing line endings. Until you add a new file.
<softworkz>
nevcairiel: It's a long story with many caveats. autocrlf=on is the default on Windows and it's hard to educate users to change it, which needs to be done even before cloning the repo, as it's too late to do after cloning.
<softworkz>
nevcairiel: the patches I submitted make the FATE tests work with the default workflow that most people use on Windows without needing to jump through any hoops
ngaullier has quit [Remote host closed the connection]
softworkz has quit [Quit: Leaving]
softworkz has joined #ffmpeg-devel
cone-039 has joined #ffmpeg-devel
<cone-039>
ffmpeg Lynne master:56b85b689dcf: aacdec_ac: fix signed overflow in ff_aac_ac_update_context()
<cone-039>
ffmpeg Maxime Gervais master:cbdb5e2477ce: ffv1enc_vulkan: fix array overflow
<softworkz>
beastd+wbs: yes, setting it to binary was objected in 2021 due to readability of diffs
<softworkz>
beastd: some of the subtitle ref files have CRLF, that's why the patch is targeting specific files only
<softworkz>
beastd: " you should definitely set autocrlf=off" <= this will cause people accidentally checking in CRLF endings
<softworkz>
when you change autocrlf after cloning, you still have CRLF endings and that's then a recipe for great mess, also with autocrlf=input
<JEEB>
the windows "git shell" defaults are absolutely atrocious, but at least you can reset the repo if you have already cloned stuff before adjusting defaults. I can't believe they did all that just because in 2010 or so notepad.exe and visual studio's editors output CRLF by default.
<JEEB>
(and people didn't want CRLF in the repos)
<softworkz>
in 2010, almost all editors on Windows did CRLF and only few were adaptive
<JEEB>
given that I have been a windows user for most of my life, by that time I had notepad++ and some other one at the very least
<softworkz>
the autocrlf setting also affects Git's diffing, that's often forgotten, so @JEEB - yes, when you reset, you can get to a point where you can work with autocrlf=off, but you need to know about it and how to do it
<softworkz>
I said almost while thinking of n++ :-)
<JEEB>
I don't recall what else I utilized back then, but I distinctly recall having something. a few years after 2010 I started using sublime text
<softworkz>
which command do you use to "reset" after changing autocrlf to get the line endings on disk changed?
<JEEB>
I recall something regarding --renormalize, but I'd have to double-check since I've had it fixed on my side for so long
<JEEB>
yea, apparently git add --renormalize with selecting all files with a dot does it?
<wbs>
I remember fiddling with that, and no it doesn't reset the current checked out files
<JEEB>
the alternative is to get git to completely re-checkout a revision, such as by removing everything except the .git directory
<JEEB>
(pretty sure there is a command for something like that)
<softworkz>
I
<wbs>
yes, something like that does work
<softworkz>
It's git rm -r --cached .
<JEEB>
since you can do those bare clones where you don't check out
<softworkz>
followed by git reset --hard
<softworkz>
took a long time to find out :-)
<softworkz>
=> nobody knows it...
<nevcairiel>
i have used autocrlf=off globally basically since the day I started using git, I dont know who decided on these defaults, as I thought git was made by programmers for programmers, and every programmer should hate automatic eol nonsense, if its done by C APIs, Git, or otherwise
<fflogger>
[editedticket] esmorun: Ticket #11269 ([avcodec] hevc_amf with 10-bit video incorrectly forces output color space to BT2020) updated https://trac.ffmpeg.org/ticket/11269#comment:9
<softworkz>
nevcairiel: no doubt you can work with that, when you know what you're doing
<JEEB>
yea, I'd like to have a piece of that person's mind if it really was for visual studio 2010
<nevcairiel>
somehow I expect developers to generally know what they are doing
<nevcairiel>
seems like not a high bar
<softworkz>
LOL
System_Error has quit [Remote host closed the connection]
<nevcairiel>
if you cant even setup your dev tools, should you be writing low level C code?
<JEEB>
and hilariously enough it only took a few years after that that even notepad.exe supports LF
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<softworkz>
yea, couldn't believe it, hehe
<JEEB>
nevcairiel: the other possibility is that since CRLF files within git then got converted to LF and thus linux users would just get LF, it's possible it was a "make my life easier by keeping those CRLF people not affecting my files"
<JEEB>
kind of thing
<JEEB>
still not agreeing with the result, mind you. but that's another view of an annoyed linux user deciding the default
<JEEB>
(for windows)
<softworkz>
JEEB: yup, that's what I believe as well (avoiding CRLF getting commited)
<JEEB>
yes, making people essentially put a step 1: set it in your gitconfig
<softworkz>
there is no gitconfig before cloning
<JEEB>
there is
<softworkz>
you cannot expect people to set it globally
<softworkz>
if I'd to that it would screw all my work
<softworkz>
elsewhere
<JEEB>
I'd expect most guides to start with that, which is bonkers of course
<nevcairiel>
you can initialize a repo without cloning and then set config, but its uncommon practice
minimal has joined #ffmpeg-devel
<softworkz>
yes - there are ways. but only few will do it. hence my patch for making it work for the average users
System_Error has joined #ffmpeg-devel
<softworkz>
that's why I also wouldn't want to change it for the CI runners for Windows. they should reflect the typical situation on Windows
jamrial has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
softworkz has quit [Read error: Connection reset by peer]
softworkz_ has joined #ffmpeg-devel
softworkz_ is now known as softworkz
softworkz has quit [Read error: Connection reset by peer]
softworkz has joined #ffmpeg-devel
softworkz has quit [Read error: Connection reset by peer]
softworkz has joined #ffmpeg-devel
mkver has quit [Ping timeout: 276 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]
<IndecisiveTurtle>
Lynne: I have a review comment in VC2 about also using uint64_t in put_vc2_ue_uint to avoid overflow. The current put_bits function in common.comp only accepts uint32_t. But since the bit_buf is already uint64_t it does work if I change it to 64-bit. Would it make sense to change the function or just add a duplicate put_bits63?
softworkz has quit [Quit: Leaving]
<Lynne>
IndecisiveTurtle: better to duplicate it
<Lynne>
64-bit arithmetic is still expensive on anything that isn't 90x0 or a 50x0 (only the latest latest gen got real 64-bit adds/mults, previously compilers emulated them)
jamrial has quit [Ping timeout: 252 seconds]
<IndecisiveTurtle>
Okay makes sense
<IndecisiveTurtle>
I think amd gcn could support 64-bit adds as early as GCN2 with V_MAD_U64_U32 but not sure what compilers do there
<IndecisiveTurtle>
But the limitation is that the half part needs to be broken into a 32x32 multiplication
<IndecisiveTurtle>
So probably not feasable on most generic things
BtbN has quit [Remote host closed the connection]
kasper93 has quit [Read error: Connection reset by peer]
kasper93 has joined #ffmpeg-devel
<ePirat>
michaelni, how do I update a fate ref?
<wbs>
ePirat: "make fate-foobar GEN=1"
<Lynne>
IndecisiveTurtle: that's what I mean by emulated
<ePirat>
wbs, thanks
jamrial_ has joined #ffmpeg-devel
<IndecisiveTurtle>
Yeah I can see why now
<IndecisiveTurtle>
Send v5 of the patcset with comments resolved
jamrial_ has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
<mkver>
IndecisiveTurtle, Lynne: Are 64bits actually necessary to encode the coefficients? Maybe the overflow was triggered by writing some header value.
<IndecisiveTurtle>
mkver: I'm not sure, I haven't encountered any bugs with the plain integer. From the commit you mentioned, it appears to have been triggered by a fuzzer
<mkver>
Yes, and it is unclear whether the overflow has been triggered by the coefficients or by some header field.
<mkver>
Does the spec put limitations on the values of the coefficients?
<IndecisiveTurtle>
I don't remember seeing such a limitation in the smpte document
<IndecisiveTurtle>
But it only has an overview of the encoding process, the decoding process is what has pseudocode/details
<IndecisiveTurtle>
All header variables seem to be read with read_uint() so I believe it assumes that they all can fit in 32-bit
<mkver>
What do you mean by "fit in 32bit"? That the argument passed to put_vc2_ue_uint() actually fits into 32 bits (that is true)? Or that the code fits into 32bits? (The latter is unclear to me.)
lemourin has joined #ffmpeg-devel
E81l7HT8T7sF9JdA has quit [Quit: Leaving]
<IndecisiveTurtle>
It was regarding if the overflow could be from a header field, since the decoder reads them as uints, then the overflow is not super likely to be from there
<mkver>
I do not get that logic at all: The encoded size of a interleaved exp-golomb code is 2 * log2(val+1) + 1. E.g. val == UINT16_MAX would lead to an overflow when using 32bit encoded values (like before af9935835335c), yet they would not lead to an overflow with a decoder using 32bit values.