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
Everything has quit [Quit: leaving]
Martchus_ has quit [Ping timeout: 276 seconds]
Martchus has joined #ffmpeg-devel
<BtbN>
hm, thought I got x265 alpha layer encoding working. But now I get a stack smashing protection error from exiting our libx265_encode_frame()
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
<Lynne>
how is alpha implemented? a new NALU?
<BtbN>
second layer
<BtbN>
basically just as tacked on as with VPx, just within the bitstream
<JEEB>
if it was zlib-ng I'd generally expect the changed bit to be static, though
<JEEB>
since it would be the compressed things changed
wbs has joined #ffmpeg-devel
<BtbN>
Hm, just realized. You could build FFmpeg against an alpha-enabled libx265, then at runtime switch the library against one without alpha (which has the same soname), and it'll crash spectacularily, cause the ABI changed
<BtbN>
Who in their right mind thought ABI-Changing configure-switches are a good idea?!
<JEEB>
yea
<BtbN>
there's also structs that change their layout depending on a few
<BtbN>
And it gets extra fun when you combine differently configured libx265 into one with the get_api thingy for the multi-bitdetph
\\Mr_C\\ has joined #ffmpeg-devel
<beastd>
JEEB: That should be the crc at the end of the chunk that changes because it includes the tag which changed in one bit, no?
<JEEB>
ah, OK
<beastd>
JEEB: Shall I write on list or you do it?
<JEEB>
I can do it :) these checksum-only diffs for FATE tests means that if you then actually attempt to review the binary diff if you don't fully know the structure you end up asking for confirmations like I did :)
<JEEB>
since it's not visible in the FATE test diff and thus you're not sure if it's meant to be there or not
<beastd>
yes
realies has joined #ffmpeg-devel
<beastd>
definitely good to doublecheck on those things
<beastd>
Not sure how we could sensibly avoid this stuff the FATE tests because it is part of the format. The test ref at least showed that the relevant sidedata stayed the same as expected.
realies has quit [Client Quit]
<JEEB>
yea, so that bit was clear :)
<beastd>
:)))
<beastd>
Sth completely different but I find it really bothering how many ppl nowadays go the route of "hmm I don't understand this and can't get it to work" -> "let's ask favourite LLM"
<JEEB>
there's a low barrier to forming a question
<beastd>
Also if LLM get's sth working out. Will they take the time to understand it?
<beastd>
I mean if they do, it's kind of OK. More or a less a different way to utilize the information on the Internet
<beastd>
If they don't it's just the same as blindly copy pasting from StackOverflow
<beastd>
It's like remote code execution without a software weakness but with cooperation of the victim. The payload doesn't have to malware but how do they know?
Marth64 has quit [Quit: Leaving]
cone-053 has joined #ffmpeg-devel
<cone-053>
ffmpeg James Almer master:68ee3faf48a7: avformat/hevc: add a log context to ff_isom_write_{hvcc,lhvc}
<cone-053>
ffmpeg James Almer master:e2953fedf99f: avformat/hevc: also print NALU ids
Kwiboo- has joined #ffmpeg-devel
Kwiboo has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
<cone-053>
ffmpeg Marth64 master:3b0e6c0eccd7: avformat/mov: use dvdclut for YUV to RGB conversion of DVD subtitle palettes