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
mkver has quit [Ping timeout: 265 seconds]
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
jdek has quit [Ping timeout: 265 seconds]
minimal has quit [Quit: Leaving]
jdek has joined #ffmpeg-devel
Guest24 has joined #ffmpeg-devel
Guest24 has quit [Client Quit]
Xaldafax has joined #ffmpeg-devel
Xaldafax has quit [Quit: Bye...]
Xaldafax has joined #ffmpeg-devel
Xaldafax has quit [Client Quit]
Xaldafax has joined #ffmpeg-devel
Xaldafax has quit [Client Quit]
psilokos has quit [Ping timeout: 268 seconds]
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
<BtbN>
Another thing from C++ I wish C would officially adopt would be the abolition of UB
<BtbN>
It's just a pointless magnet for miscompiled code that can cause security flaws
<BtbN>
Someone actually made a research paper about LLVMs aggressive UB-using optimization
<BtbN>
it's single-digit performance benefits, for a huge risk of miscompiling code compared to what the author intended/expected
<Gramner>
do you want "for (int i ..." loop to be a lot slower? because no UB means you'd need to do sign-extension every time such iterator is used for an array index etc. whereas signed overflow being UB means you can currently use a pointer-sized register for it
<haasn>
no UB means the compiler would have to insert a range check before every array access
<BtbN>
does it? Sounds just like implementation-defined to me
<BtbN>
C++ managed to get rid of UB in the standard, and it didn't turn atrociously slow when doing so
<haasn>
ramiro: I implemented the "fuse lines when strides are compatible" optimization on the ops.c level but one thing to note is that it totally breaks SWS_OP_DITHER (since that one depends on the exact x/y coordinates)
<haasn>
so most likely we would need to couple this with a mechanism for establishing whether the x/y coordinates matter or not
<psykose>
> C++ managed to get rid of UB in the standard
<psykose>
huh, what did i miss?
<haasn>
which seems like a bit of a hack
<BtbN>
I think it's not actually in the standard yet, but it's a proposal that'll likely be in the next iteration
<haasn>
I think I'd rather outsource that decision logic to the implementation, and make the entrypoint basically just take the base pointers and the x/y coordinate range
<haasn>
I may even nuke SwsOpExec entirely
Thulinma has quit [Quit: Laters]
___nick___ has joined #ffmpeg-devel
Thulinma has joined #ffmpeg-devel
<thardin>
getting rid of UB sounds good to me. it's weird that the compiler is free to assume a program terminates
<jkqxz>
Getting rid of UB sounds like a terrible idea. What will the implementation do with a pointer received from outside the translation unit? Scan the memory map of the program to make sure it's in an "allowed" range of some kind before you're allowed to dereference it?
<BtbN>
Just dereference it?
<BtbN>
I really don't see the problem there. Leacing it to the platform and implementation to define the final behaviour is fine
<BtbN>
It just needs to be defined how exactly the language behaves, up to its boundaries
<BtbN>
So that stuff like optimizing away null checks or other nonsense like strict aliasing that completely messes with with programmer expectations can't happen
<jkqxz>
How does the implementation define what happens when it might overwrite the implementation's internal structures?
<jkqxz>
Saying that the implementation is allowed to say that implementation-defined behaviour is undefined defeats both the point of implementation-defined behaviour and also the attempt to remove undefined behaviour.
<BtbN>
Well, if you overwrite it in the right way, it does what what you wrote did
<fflogger>
[newticket] weihuaqd: Ticket #11554 ([ffmpeg] ffmpeg does not respect A/V start_pts in the input file while transcoding to HLS/fmp4, the output has A/V sync issue) created https://trac.ffmpeg.org/ticket/11554
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
<ramiro>
haasn: that's what I did with asmjit. I only keep track of x/y when dither is used.
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]