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 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
lexano has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
<fjlogger>
[FFmpeg/FFmpeg] Issue #20474 closed: FFmpeg Version 8 Encryption/Decryption Incompatible with version 7 using cenc-aes-ctr encryption scheme (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20474) by jamrial
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20435 closed: Fix function file_open,file_read,file_write,file_close,file_seek conflict with Nuttx (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20435) by caifan
microchip_ has quit [Remote host closed the connection]
<BtbN>
Hm, the situation with that is really annoying. Apparently our clang built nvptx does not work anymore on modern drivers, cause the minimum version we compile it for is too old
<BtbN>
so we have to bump it to 75 apparently, and leave users of not even that old GPUs behind. Or leave users of the latest GPUs out.
<BtbN>
Highly annoying
<JEEB>
right, so the cuda libs in latest drivers just dropped a bunch of things
<BtbN>
I'm not even talking about the libs
<BtbN>
purely our PTX code
<JEEB>
yea, I mean we build the more compatible stuff and then we have the libs compile it into the device-specific stuff?
<JEEB>
if I recall correctly what the PTX byte code was
<BtbN>
We compile to PTX code, which the driver can consume directly
<kasper93>
BtbN: thanks for looking into forgejo issue. I think github solves this issue by not even creating reference to commits, but completely another "review" snapshot of comments and related code.
<BtbN>
That's what forgejo does as well, but it pulls that snapshot at time of posting, even though the post sends along what commit id it's being posted on. All since a weird patch to gitea 4 years ago
<BtbN>
So if you spend too long reviewing, it breaks
<BtbN>
I don't think this will make it perfect, there's other issues in that area for sure. But this is certainly the most glaring one.
<frankplow>
Got a tricky fuzz sample with an issue related to the architectural decision to use CBS for all parsing in the VVC decoder.
<jamrial>
mkver: did that other PR prompt you to do this one? :p
<mkver>
jamrial: It gave me the kick in the arse I needed to write it.
<jamrial>
figured as much. happened to me before
<frankplow>
VVC requires all parameter sets within an AU (*consecutive* set of NALUs corresponding with a single coded picture, neglecting multilayer) with a particular ID to have the same content.
<mkver>
I hope Renjianguang-mi isn't pissed of by this.
<frankplow>
At the moment, this is checked at decode-time, i.e. once all NALUs corresponding to a particular coded picture have been received. This works fine for detecting problems with the parameter sets between multiple AUs, but not within a single NALU.
<frankplow>
But if a single AU contains multiple conflicting parameter sets then it can't notice it, e.g. if you have 1. SPS(id=0, content=0) 2. Slice 3. SPS(id=0, content=1) 4. Slice, then the second SPS overwrites the first without the problem being detected.
<BtbN>
Could someone give the Graphics.Capture PR a final review and Approval? I'm not aware of anything else that needs changing. I'm half-expecting the configure C++ changes to break something, somewhere. But that's hard to predict and needs to be fixed then.
<frankplow>
The only solution I can see is to move the parameter set management into the CBS, but this seems like a poor separation of concerns as none of this is strictly needed to parse the data and it's a moderate amount of code.
<jamrial>
frankplow: is there a reliable way for cbs where an AU ends?
<frankplow>
jamrial: I believe you can't always know if a particular NALU is the final NALU of an AU (or the first NALU of an AU) until some later NALU is received
<mkver>
frankplow: Would it be possible to add a RefStruct references to the parameter sets in force for a given slice to H266RawSliceHeader?
<frankplow>
mkver: I suppose so. How would this handle the example I sketched above: the two slices refer to different SPSs?
<mkver>
frankplow: You could use the proper SPS to decode each one of the slices.
<mkver>
BtbN: Would it be possible (or too onerous) to run FATE with ASAN as part of the CI checks?
<jamrial>
mkver: i think the point is that the second sps must be equal to the first if it's in the same AU
<mkver>
Then why does the parser not start a new AU if the currently used SPS gets overwritten?
<frankplow>
mkver: The parser doesn't control the parameter set management etc., that's all handled in the decoder: that's part of the issue.
philipl has quit [Ping timeout: 260 seconds]
<mkver>
But the parser should know that parameter sets can't just be put at random positions and act accordingly.
<frankplow>
Maybe the parameter set management does simply have to be handled there rather than in the decoder though, even if it is a poor separation of concerns? There already sort of is a primitive one in CodedBitstreamH266Context, maybe it needs to become as fully-fledged as the one in VVCParamSets
HarshK23 has joined #ffmpeg-devel
<mkver>
"rather than" sounds as if you wanted to remove the one in the decoder; given that parser and decoder are separated, this won't be happen.
<frankplow>
You can run the parser without the decoder but not the decoder without the parser. If the validation and management is handled in the parser, could it not then be removed or simplified in the decoder?
<jamrial>
frankplow: you can build, you mean. nothing forces an API user to use the parser if they only want to use the decoder
<mkver>
Incorrect; one can run the decoder without the parser.
<jamrial>
also, if you set the complete frames flags, no packetization happens
<mkver>
This makes sense when you know that you already have good packets.
<frankplow>
Huh, I didn't realise that was possible.