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
<fflogger> [editedticket] QFox: Ticket #11435 ([avformat] Added "-extension_picky" breaks MPV?) updated https://trac.ffmpeg.org/ticket/11435#comment:7
<BtbN> "Dynamic decode surfaces allocation" in the SDK 13 feature list. Not sure what that means, I didn't see any major changes on the decode side. But if it means getting rid of the static sized array of output surfaces, that'd be neat
System_Error has quit [Remote host closed the connection]
<BtbN> ah, I see it
System_Error has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Compn has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 252 seconds]
<jamrial> not sure if it's automagically propagated to the encoder, but at least it's exported by the decoder
<BtbN> I guess that only appears once?
<BtbN> At least according to the spec
thilo has quit [Ping timeout: 260 seconds]
<jamrial> yeah
<jamrial> alongside the parameter set NALUs
<jamrial> so in extradata in the case of mp4/mkv
<BtbN> I guess I can just tell nvenc to write it whenever the side data comes along
<BtbN> that should align itself fine enough
thilo has joined #ffmpeg-devel
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<jamrial> BtbN: yeah, it's propagated just fine to the encoder. so just look for it in avctx->decoded_side_data
<BtbN> It'll still be on the frame though, right?
<BtbN> Cause that's a bit easier to deal with.
<jamrial> yes, it's also going to be in every frame
<BtbN> Oh, every frame
<jamrial> it could in theory change mid stream alongside sps/pps/vps, i guess, so it will be reflected that way
<BtbN> Hm, guess that's why it's passed to nvenc every frame
<BtbN> I wonder if it does the right thing, or just really writes it every frame
<jamrial> probably, but what i wonder about nvidia's approach for this is how it's the SEI supposed to be emited for extradata
<jamrial> you can't pass this info during init()
<jamrial> and nvEncGetSequenceParams() is called then
<BtbN> ffprobe does not detect mvhevc written by nvenc as stereo
<jamrial> maybe that function is not meant to return global SEI? I think it did for Alpha, but i may be wrong
<BtbN> It's definitely odd
<BtbN> Or they forgot global headers exist
<BtbN> Would also explain the alpha situation
<jamrial> if the sei is only going to be output with key frames (i hope that's the case and not *every* frame), then during mp4/mkv muxing it's not going to show up in extradata
<jamrial> and that's afaik not how the Apple spec wants it
<BtbN> I also get the encoder busy looping on clean exit when encoding longer videos with mv
<BtbN> LockBitstreamBuffer just busy loops internally
<BtbN> Anyway, time for bed for now
<jamrial> gn
<fflogger> [editedticket] MasterQuestionable: Ticket #11435 ([avformat] Added "-extension_picky" breaks MPV?) updated https://trac.ffmpeg.org/ticket/11435#comment:8
^Neo has quit [Ping timeout: 252 seconds]
<Lynne> jamrial: thanks, I'll take a look at it
<Lynne> now the corruption I'm seeing makes sense
Marth64 has joined #ffmpeg-devel
jamrial has quit []
mkver has quit [Ping timeout: 272 seconds]
Warcop has quit [Remote host closed the connection]
<Compn> ffmpeg reporting in from mars today
Warcop has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 265 seconds]
Compn has quit [Remote host closed the connection]
Compn has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<Marth64> nice
<Marth64> (re: ff on mars)
rvalue has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
rvalue has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<fflogger> [editedticket] fildens: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since FFmpeg 7?) updated https://trac.ffmpeg.org/ticket/11430#comment:7
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Marth64 has quit [Quit: Leaving]
<fflogger> [newticket] fenlaz: Ticket #11440 ([ffmpeg] Popping / Cracking sound on videos with .MKV format when played on MPV) created https://trac.ffmpeg.org/ticket/11440
putacho has joined #ffmpeg-devel
elChippo has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 265 seconds]
putacho has quit [Ping timeout: 252 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
BestLeader has joined #ffmpeg-devel
<BestLeader> thardin does MXF stores key/intra frame flags for videos in any way?
ngaullier has quit [Ping timeout: 260 seconds]
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
DauntlessOne4 has quit [Read error: Connection reset by peer]
DauntlessOne4 has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 245 seconds]
BestLeader has quit [Quit: Client closed]
auri has quit [Quit: No Ping reply in 210 seconds.]
BestLeader has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<BestLeader> the bilinear interpolation C code in vf_rescale.c is at least 20-40 fps faster than current sws bilinear interpolation C code (for svga->2k rescaling)
<BestLeader> very interested in magic that sws SIMD code does
jamrial has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
jamrial has quit []
BestLeader has quit [Quit: Client closed]
jamrial has joined #ffmpeg-devel
witchymary has quit [Ping timeout: 248 seconds]
BestLeader has joined #ffmpeg-devel
<haasn> Does anybody know if the FOSDEM'25 meeting will be on saturday or sunday?
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
DauntlessOne4 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
<BestLeader> will there be meeting at all?
<jamrial> supposedly, yes
System_Error has quit [Remote host closed the connection]
<fflogger> [editedticket] MasterQuestionable: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since FFmpeg 7?) updated https://trac.ffmpeg.org/ticket/11430#comment:8
System_Error has joined #ffmpeg-devel
<jamrial> BtbN: do you have an updated set for mvhevc using the global side data anywhere?
<BtbN> nope, I'm still at work
<jamrial> ok
<BtbN> I guess it should just check for the existence of the new side data on init?
<jamrial> to set profile and such, yeah, but ultimately, you have to pass the payload to the driver on frame processing
<BtbN> I mean just for the auto detection, yeah
<fflogger> [newticket] emcodem: Ticket #11441 ([documentation] Typo in docs for format filter) created https://trac.ffmpeg.org/ticket/11441
ngaullier has quit [Read error: Connection reset by peer]
ngaullier has joined #ffmpeg-devel
<fflogger> [editedticket] tjgreen: Ticket #11212 ([avformat] FFmpeg throws errors on certain moov atom positions using pipe input) updated https://trac.ffmpeg.org/ticket/11212#comment:5
<fflogger> [editedticket] MasterQuestionable: Ticket #11440 ([avformat] Specific Opus had glitched playback in Matroska container) updated https://trac.ffmpeg.org/ticket/11440#comment:1
srikanth has joined #ffmpeg-devel
srikanth has quit [Client Quit]
srikanth has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<fflogger> [editedticket] MasterQuestionable: Ticket #11212 ([avformat] FFmpeg throws errors on certain moov atom positions using pipe input) updated https://trac.ffmpeg.org/ticket/11212#comment:6
ngaullier has quit [Remote host closed the connection]
cone-872 has joined #ffmpeg-devel
<cone-872> ffmpeg Gyan Doshi master:221816456a60: doc/filters: fix typo in format filter
<fflogger> [editedticket] Gyan Doshi <ffmpeg@gyani.pro>: Ticket #11441 ([documentation] Typo in docs for format filter) updated https://trac.ffmpeg.org/ticket/11441#comment:1
<BtbN> jamrial: you think init should return EINVAL if it finds AVStereo3D with a clearly unsupported type? Like, anything that's not 2D, unspec or frameseq?
<jamrial> i'd say no, because ultimately those are views packed within a single frame, which can be encoded just fine as is
blb has quit [Quit: brb]
blb has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
<BtbN> I'm trying to keep the ability to encode arbitrary content without metadata as mv
<jamrial> yeah, that's needed too
<BtbN> ./ffmpeg -v verbose -f lavfi -i testsrc2=duration=3600:size=1920x1080:rate=60 -an -sn -c:v hevc_nvenc -profile:v mv -y -f null -
MyNetAz has quit [Read error: Connection reset by peer]
<BtbN> This command still, when it runs for more than like 1000~2000 frames, will hard-lock on clean exit, with gdb pointing at nvEncLockBitstream, which is internally busy-looping
<BtbN> Just changing profile from mv to main makes it exit cleanly
MyNetAz has joined #ffmpeg-devel
<jamrial> BtbN: looks like my 4070 can encode mv
<BtbN> yes, MV encoding is not a Blackwell feature
<BtbN> the new pixel formats and bit depths are
<jamrial> BtbN: http://pastie.org/p/0LHSapjsPKaZdfyUGokqB2 this doesn't look right
<jamrial> same id for both views
<jamrial> from the output of the above command
<BtbN> But no hard-locking?
<jamrial> i encoded a single second
<BtbN> ah
<BtbN> I don't see an obvious mistake with that
<BtbN> so probably something with the driver
<jamrial> BtbN: try with "./ffmpeg -i mv.mov -an -sn -map 0:v:view:all -c:v hevc_nvenc -t 1 mv.mp4"
<jamrial> i'm getting eagain
<haasn> this was one of the most productive train rides of my life
<haasn> time=2345 us, ref=3403 us, speedup=1.451x faster rgba64le <-> rgba64be
<jamrial> nice
<haasn> time=6563 us, ref=22646 us, speedup=3.450x faster rgba -> rgba64le
<haasn> time=5218 us, ref=23459 us, speedup=4.495x faster rgba -> rgba64be
<haasn> I'm even giving swscale an "advantage" by also compiling it with -mavx -mavx2
<haasn> (it's not a real advantage because I also compile my template with -mavx -mavx2, though in practice it will mean a bigger speedup because we will be able to use the AVX-enabled template at runtime)
<haasn> time=5439 us, ref=15060 us, speedup=2.769x faster rgba -> gbrp16le
<haasn> this one is without any special cases
<haasn> I did add a special case for just LE <-> BE conversion which got it from ~1x to ~1.4x
<haasn> and a special case for 8->N bit expansion which got the 8->16 bit conversions from ~2x to ~3.4x
System_Error has quit [Remote host closed the connection]
<haasn> time=1449 us, ref=2479 us, speedup=1.711x faster yuv444p -> yuv444p10le
<haasn> yuv444p16le*
<haasn> since swscale does not have a fast path for this
<haasn> but my template approach gets it for free
<haasn> from just one additional macro expansion
<haasn> for yuv444p10le the perf is roughly 1x
<haasn> since swscale already handles this well
<haasn> in theory we could also add a fast path for packed<->planar conversion while also swapping bytes, but the generic path handles this well enough (~1x compared to current swscale)
<haasn> handling subsampled formats and scaling is still a massive WIP, I think I will try and merge this code as-is before worrying about that
<haasn> also still needs YUV<->RGB conversion and LUT applications (so we can use it for color management, PAL8, YUV<->RGB etc)
<haasn> but the worst slowdowns so far are on the order of 2-5% speed loss
<haasn> I'm sure once this is merged and we can start actually writing optimized SIMD routines the speedup will be even faster
<haasn> comparing templated C (compiled through -mavx -mavx2) against hand-written SIMD in some cases..
<haasn> while everything else is from 2x to 4x speedup
<haasn> but my goal for now is to make the C path as fast as possible because, no matter how many optimized SIMD routines you can produce, at the end of the day, somebody will trigger these slow paths
<haasn> and swscale shows that the slow vs fast path discrepancy is way too big
System_Error has joined #ffmpeg-devel
<BtbN> jamrial: I'm getting Error encoding a frame: Resource temporarily unavailable
<jamrial> yes
<BtbN> but with a weird log message
<BtbN> like, double-wrapped log, not sure what logs like that
<BtbN> like, [vost#0:0/hevc_nvenc @ 0x559714893980] [enc:hevc_nvenc @ 0x55971487fd40] Error encoding a frame: Resource temporarily unavailable
<BtbN> jamrial: but it kinda makes sense it's doing that. Looking at the other log output, it's discarding all but the first two frames or so
<BtbN> so nvenc never fills its delay buffer, so just spins EAGAIN forever
<BtbN> in mv mode, the delay is doubled, so the other modes don't run into actually failing with EAGAIN
<jamrial> but why are those frames dropped?
<jamrial> the hevc decoder exports both views as separate frames with the same timestamp. maybe that's why?
<BtbN> Then I'd expect it to drop every other frame, but the log looks like it drops all but the first two
<BtbN> It's also "vf" doing the dropping, oddly enough
<jamrial> in any case, rebase your branch with https://github.com/jamrial/FFmpeg/commits/tdrdi/ since i pushed a fix
<jamrial> BtbN: even if i don't force both views (by removing the -map argument), i still get EAGAIN
<BtbN> But it's not an issue with nvenc, is it?
<jamrial> i don't know
<BtbN> it dropping a ton of frames happens long before nvenv
<jamrial> no frames are dropped if i only decode one view
<BtbN> it's dropping the same way if I encode it as mpeg4
<BtbN> so I don't think nvenc is involved here at all
<BtbN> it's just reacting more strongly to so many dropped frames
<jamrial> did you remove the -map part of the above command line, to get only one view?
<BtbN> no, since I wanted to check if somehow nvenc is triggering the drops
<BtbN> yeah, no drops anymore without the map
<BestLeader> haasn do scaling also in C, its impossible mission
witchymary has joined #ffmpeg-devel
BestLeader has quit [Quit: Client closed]
cone-872 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
iive has joined #ffmpeg-devel
cone-001 has joined #ffmpeg-devel
<cone-001> ffmpeg Michael Niedermayer master:d8455331302c: avformat/hls: Print input format in error message
<cone-001> ffmpeg Michael Niedermayer master:0fe33c99a26a: avcodec/h263dec: Check against previous dimensions instead of coded
DauntlessOne4 has joined #ffmpeg-devel
ccawley2011_ has quit [Read error: Connection reset by peer]
<BtbN> jamrial: according to nvidia, the busy-looping happens when the encode ends with an uneven number of frames. That's... definitely an odd one
<BtbN> It seems like a driver bug to me. It should never ever enter a busy loop like that oO