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
<qwertyttyert>
In both cases, the file is encoded with the file time.
realies has quit [Quit: ~]
Marth64 has joined #ffmpeg-devel
<Marth64>
Are there any common reasons vulkan encoding would fail intermittently? For example, this command works sometimes then raises Encode failed: -<random negative numbers> intermittently
<qwertyttyert>
Humor or not humor. Oh, these modern DEs, they need RTX3060. Oh, this modern FFmpeg he need... The very case when the old turned out to be better than the new for me. Optimizations from Debian?
<aaabbb>
qwertyttyert: you mean encoding is slower on a newer ffmpeg than older?
Marth64 has quit [Quit: Reboot]
<aaabbb>
might not be ffmpeg's fault. might be changes in default presets for whatever encoder you are using. unless you are doing heavy use of filters (big complex filtergraphs) then ffmpeg itself is not doing mutch and the encoding library is doing almost all of the work
Marth64 has joined #ffmpeg-devel
<Traneptora>
Marth64: which random negative number?
Tanay has joined #ffmpeg-devel
Tanay has quit [Remote host closed the connection]
jamrial has quit []
<Marth64>
Traneptora: it rotates between a few, I'll work on a proper TRAC ticket
<qwertyttyert>
Did you look at the links? Have you opened the links? There is real-time -re encoding, the time spent is the same, but the CPU load is significantly different. I don't always need to be faster. If it significantly reduces the real-time CPU usage, I'll use real-time encoding.
<Traneptora>
qwertyttyert: this channel is for development of ffmpeg itself, for user help please use #ffmpeg
<qwertyttyert>
I don't ask, I show what I saw.
<Traneptora>
if you believe you have found a bug please open a ticket on trac
<aaabbb>
qwertyttyert: #ffmpeg will still be better unless you're trying to narrow down a particular bug
<Traneptora>
as it stands I don't think anybody has any idea what you are talking about
<aaabbb>
if there's a regression then asking about it in here is fine but otherwise it's a bit confusing when you just say that older is better
<fflogger>
[newticket] lixingchen: Ticket #11445 ([avcodec] FFMPEG Remux Fails After A Few Frames Lost In The FLV RTMP Live Stream Because Of An Internet Problem) created https://trac.ffmpeg.org/ticket/11445
cone-398 has joined #ffmpeg-devel
<cone-398>
ffmpeg Scott Theisen master:33daef5f498c: avcodec/mpeg12dec: rename 0x0502 CC format
<cone-398>
ffmpeg Dale Curtis master:957eb2323a92: avcodec/h264dec: make slice header parse errors fatal under AV_EF_EXPLODE
<qwertyttyert>
Everything is working normally. I don't know why there is such a difference. I can only guess.
<Marth64>
qwertyttyert: what is the question exactly?
<Marth64>
please put in #ffmpeg
<Marth64>
bot?
<Traneptora>
they think they've discovered some bug but rather than say anything intelligible they've chosen to spam
qwertyttyert was kicked from #ffmpeg-devel by Marth64 [please direct user question to #ffmpeg or file ticket on trac]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since 7.0) updated https://trac.ffmpeg.org/ticket/11430#comment:11
jarthur has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 272 seconds]
mkver has quit [Ping timeout: 252 seconds]
^Neo has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
tufei has joined #ffmpeg-devel
<fflogger>
[newticket] Marth64: Ticket #11446 ([undetermined] Intermittent Vulkan encoding failures with 4060TI(driver 550), Ubuntu 24.04, Vulkan SDK 1.4.304.0) created https://trac.ffmpeg.org/ticket/11446
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
leoh has quit [Read error: Connection reset by peer]
MisterMinister has joined #ffmpeg-devel
leoh has joined #ffmpeg-devel
cone-398 has quit [Quit: transmission timeout]
vrgkar has joined #ffmpeg-devel
leoh has quit [Read error: Connection reset by peer]
vrgkar has quit [Quit: vrgkar]
MisterMinister has quit [Ping timeout: 260 seconds]
<fflogger>
[editedticket] fildens: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since 7.0) updated https://trac.ffmpeg.org/ticket/11430#comment:12
xvaclav has quit [Ping timeout: 248 seconds]
xvaclav has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
xvaclav has quit [Ping timeout: 248 seconds]
xvaclav has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 244 seconds]
MeritLeader has joined #ffmpeg-devel
<MeritLeader>
Major news: got working interpolation of phase between min-phase and linear-phase FIR, I just had to unwrap phase of linear FIR filter.
ngaullier has joined #ffmpeg-devel
<kierank>
MeritLeader: nice
ngaullier has quit [Ping timeout: 244 seconds]
ngaullier has joined #ffmpeg-devel
xvaclav8 has joined #ffmpeg-devel
any1 has quit [Ping timeout: 246 seconds]
xvaclav has quit [Quit: Ping timeout (120 seconds)]
xvaclav8 is now known as xvaclav
any1 has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
mkver has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 248 seconds]
jamrial has joined #ffmpeg-devel
rvalue- is now known as rvalue
<haasn>
MeritLeader: using float32 as intermediate may actually be faster than fixed point int16_t
<haasn>
at least in my dumb synthetic benchmark it is
<haasn>
I'm starting to think we should scrap the whole approach of using awkward 15-bit/19-bit intermediates and just switch to float32 precision everywhere
<haasn>
let me try to switch to float on a branch and see if it's faster
<JEEB>
yea, worth a try definitely
<wbs>
haasn: if you can package that up into an easy to build/run testcase that we can test on a few other platforms as well, it'd be nice
<Compn>
haasn, might be worth it to have a separate float version. i know people run ffmpeg on hardware where float is slower
<haasn>
indeen
<haasn>
with the design I have right now it wouldn't be very hard to have a separate float table/template
<haasn>
well, it's actually a bit awkward in one sense
<JEEB>
I would first check the most common non-x86_64 archs (aarch64, armv7, risc-v, power). slow floats I would probably expect to happen on MIPS (which at this point is getting less and less utilized) and soft-float ARM (also at this point quite old)
<haasn>
which is that for float pipelines you may want to optimize operations a bit differently
<JEEB>
it's telling that the amount of non-float alternative implementations hasn't really risen the past few years
<haasn>
since float operations associate more easily than fixed point stuff you can roll everything into a single 3x3 matrix op
<haasn>
including range expansion and convertion between msb/lsb aligned data etc
<haasn>
whereas in the int pipeline I'd rather have a dedicated shifting / conversion step that does not rely on a matrix multiplication step
<haasn>
I guess more specifically, the issue is that fixed range matrix multiplications have quite limited value range, e.g. only supporting coefficienst between -2 and +2
<haasn>
whereas with floats you can easily have a coefficient as large as, say, 65535
<haasn>
and thus roll all range/depth conversions into the 3x3 matrix
<BtbN>
jamrial: Nvidia basically just confirmed to me that the sequence parameters will never contain the ref disp info. But they're looking into the pairs of SPS/PPS.
<BtbN>
I guess the only way to deal with that is to force-disable global headers when in MV mode
<BtbN>
and hope they move it all to the first packet
<kasper93>
Marth64: shouldn't the ret value be ffmpeg own AVERROR? Maybe try with valgrind, to see why it is random, because it doesn't sound right at all, no matter what nvidia is doing in thier driver
<jamrial>
BtbN: if you're supposed to merge two packets out of nvenc into one, what they currently output should be fine as long as we force-disable global headers in mv mode, yes
<jamrial>
they seem to output each layer slice and PS NALUs into separate payloads, when they should be together in a single temporal AU
<cone-861>
ffmpeg Zhao Zhili master:1438f6997db7: avcodec/nvenc: Enable recovery point SEI for intra refresh mode
<cone-861>
ffmpeg Zhao Zhili master:ef3ffd8c5c75: avformat/seek: Remove dead code
<Marth64>
kasper93: I agree even after following the code it looks like it should be one of our own. I did a quick av_err2str() but it didn't get a result, so random feels even more wrong
<Marth64>
I will valgrind
ngaullier has quit [Remote host closed the connection]
<MeritLeader>
nobody can beat librempeg; it have much more features than any other ffmpeg fork
<llyyr>
when will you upstream 86473583b4cd11595f2d372666115024124d429f
<MeritLeader>
is this serious? does that commit actually fix some broken files?