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
MyNetAz has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 272 seconds]
MyNetAz has quit [Remote host closed the connection]
<BtbN>
The 16 patch long rtmp/flv series with new feature I have on the list right now
<BtbN>
+s
<BtbN>
Cause for multiple major companies, just reviving rtmp was apparently easier than reinventing their entire infra for a differenr protocol
<Compn>
i saw your patch i think. they added more codecs to flv? :D
<BtbN>
more modern codecs, more audio layout stuff, multiple tracks
<Compn>
ahahaha
<Compn>
i mean flv isnt a bad format anyway
<Compn>
container*
<BtbN>
It's not half bad, yeah
<BtbN>
Though while implementing that stuff, I had an urge to rewrite our muxer/demuxer for it from sratch
<BtbN>
cause it is super messy
<Compn>
always a good idea
<Compn>
no one dares fix mov.c
<Compn>
but then the fun begins when they start asking for more colorspaces, bit depths, alpha, interlacing support . then its like... good luck flv container
<Compn>
everyone hates rtsp? good? good.
jamrial has quit []
\\Mr_C\\ has quit [Remote host closed the connection]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
<Guest84>
can these be ignored?
<Guest84>
strip: Unable to recognise the format of the input file `libavfilter/x86/vf_eq.o'
<fflogger>
[editedticket] Balling: Ticket #9771 ([avcodec] Small MAX_SLICES makes d3d11va (AVC) not bitperfect and causes artifacts (but not CUDA/NVDEC)) updated https://trac.ffmpeg.org/ticket/9771#comment:6
<BtbN>
nevcairiel: ^ you know more about that stuff, and I think you are actually the maintainer?
<nevcairiel>
technically i guess, but that variable is in the main h264 decoder
<BtbN>
If there are valid h264 samples with significantly more than 32 samples, I guess the value needs to be actually increased, or turned into a dynamic buffer
<nevcairiel>
the software decoder manages somehow but has a minimal performance deficit
<BtbN>
Yeah, I just wondered that. Why isn't the software decoder affected?
zenmov has quit [Ping timeout: 276 seconds]
<nevcairiel>
maybe it can be solved without the max slices change, but i never investigated that since i dont care about a small memory increase
<nevcairiel>
otherwise feel free to try to submit the change
<nevcairiel>
im away for the next few days, more or less
<BtbN>
I just wanna avoid a situation where we bump the limit, and next week someone comes up with a sample with EVEN MORE slices
<nevcairiel>
thats why i've used 256 instead of say 64 or something
<BtbN>
I'm having a hard time finding any info on wether h264 has an actual upper limit on the slice count
<nevcairiel>
i believe i was told there isnt really one
<nevcairiel>
other then being limited by the resolution you have
<JEEB>
I would expect something like that, yea. since you apparently just get slice after a slice without a num_xyz variable
<JEEB>
4320p with a single macroblock height would be 270 I think?
<j-b>
good morning
zenmov has joined #ffmpeg-devel
<BtbN>
so it's kinda more like a policy decision. "What is sensible and what do we WANT to support?"
<nevcairiel>
or figure out dynamic
<BtbN>
Yeah, just dynamically re-alloc a buffer that grows as needed
<BtbN>
I think the resolution limits should prevent DOS attacks there
<nevcairiel>
i dont remember if its just a struct in the dxva code thats the limiting factor, because there certainly is one in there, or if its more
<BtbN>
The software decoder seems to just do "& (MAX_SLICES - 1)" for its static buffers
<BtbN>
so I'd assume that to make a mess when something actually exceeds the limit
<nevcairiel>
it decodes fine in software mode though
<nevcairiel>
so it must not need them anymore then
<nevcairiel>
probably only needs the last slice, or maybe last few for prediction
<nevcairiel>
the default limit could be raised in any case, the decoder warning doesnt seem like the value is big enough
<BtbN>
I have no idea how realistic of a sample this is
zenmov has quit [Ping timeout: 252 seconds]
cone-731 has quit [Quit: transmission timeout]
<fflogger>
[editedticket] Balling: Ticket #9771 ([avcodec] Small MAX_SLICES makes d3d11va (AVC) not bitperfect and causes artifacts (but not CUDA/NVDEC)) updated https://trac.ffmpeg.org/ticket/9771#comment:7
<fflogger>
[editedticket] oromit: Ticket #9771 ([avcodec] Small MAX_SLICES makes d3d11va (AVC) not bitperfect and causes artifacts (but not CUDA/NVDEC)) updated https://trac.ffmpeg.org/ticket/9771#comment:8
<fflogger>
[editedticket] Balling: Ticket #9771 ([avcodec] Small MAX_SLICES makes d3d11va (AVC) not bitperfect and causes artifacts (but not CUDA/NVDEC)) updated https://trac.ffmpeg.org/ticket/9771#comment:9
MetaNova has quit [Ping timeout: 276 seconds]
<fflogger>
[editedticket] oromit: Ticket #9771 ([avcodec] Small MAX_SLICES makes d3d11va (AVC) not bitperfect and causes artifacts (but not CUDA/NVDEC)) updated https://trac.ffmpeg.org/ticket/9771#comment:10
MetaNova has joined #ffmpeg-devel
Everything has quit [Quit: leaving]
witchymary has quit [Remote host closed the connection]