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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<cone-932>
ffmpeg Michael Niedermayer release/4.2:aa564c7cbdd4: avcodec/hevc/hevcdec: Do not allow slices to depend on failed slices
<cone-932>
ffmpeg Michael Niedermayer release/4.2:11834dcd8baf: avcodec/proresdec: Consider negative bits left
<cone-932>
ffmpeg Michael Niedermayer release/4.2:4e5b5a06d728: avcodec/vaapi_encode: Check hwctx
<cone-932>
ffmpeg Michael Niedermayer release/4.2:4876fbc18130: avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 for snow
<cone-932>
ffmpeg Michael Niedermayer release/4.2:0d1d6587d0fc: avcodec/snow: Fix off by 1 error in run_buffer
<cone-932>
ffmpeg Michael Niedermayer release/4.2:64b96e2c9179: update for 4.2.10
lexano has quit [Ping timeout: 248 seconds]
<cone-932>
ffmpeg Michael Niedermayer n4.2.10:HEAD: avcodec/snow: Fix off by 1 error in run_buffer
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
linjie has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
essbee has joined #ffmpeg-devel
<haasn>
courmisch: is there any reason to schedule an unrelated instruction between vsetvli and a vector instruction?
<BBB>
isn't that just dependency management?
<BBB>
you don't want immediately-dependent instructions after each other because the result (delay) of one will prevent the next from (starting to) execute
<elenril>
>scheduling instructions manually in 2024
<elenril>
what is this, pentium mmx?
<Sean_McG>
>assuming compilers always know best
<Lynne>
>not scheduling your instructions ever
<haasn>
BBB: the question is whether or not vsetvli has a latency/delay
<Lynne>
yeah, it has, I remember it was pretty massive
<Lynne>
you should always interleave instructions when writing asm, at the very least, you make the CPU reorder's job easier
<Sean_McG>
^
quietvoid has quit [Ping timeout: 252 seconds]
<essbee>
Hey, I added basic support for interacting with ffplay using a game controller (via SDL2 API). Is this something I should submit as a patch, or is it is out of scope for ffplay?
<cone-817>
ffmpeg James Almer master:6f8e365a2af2: avutil/hwcontext_vaapi: use the correct type for VASurfaceAttribExternalBuffers.buffers
<cone-817>
ffmpeg James Almer master:f4daf633b2e3: avcodec/aacps_tablegen_template: don't redefine CONFIG_HARDCODED_TABLES
<cone-817>
ffmpeg James Almer release/7.0:b6b55f6e2be6: avutil/hwcontext_vaapi: use the correct type for VASurfaceAttribExternalBuffers.buffers
<cone-817>
ffmpeg James Almer release/7.0:d0d740946b72: avcodec/aacps_tablegen_template: don't redefine CONFIG_HARDCODED_TABLES
<haasn>
essbee: how large are the changes?
Livio has joined #ffmpeg-devel
<Sean_McG>
I would ask if there was a way to use libinput instead, but ffplay already depends on SDL2 doesn't it
<JEEB>
yes
<JEEB>
the window and everything
<Sean_McG>
OK, that's fair
<essbee>
The diff is about 60 lines, so not much.
<Lynne>
libinput doesn't do gamepad i/o
<Lynne>
its an anti-goal of the library, due to the huge amount of variation
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<courmisch>
haasn: not that I'd specifically be aware of, but I haven't reverse engineered the scheduling of T-Head's vector unit
<courmisch>
haasn: vsetvl is slow; vsetvli at constant VL and SEW/LMUL should be fast
<haasn>
vsetvli zero, zero
<courmisch>
yeah so constant VL
<courmisch>
haasn: also changing vxrm is slow
<courmisch>
(which goes agains the spirit of the spec, IMU)
<courmisch>
elenril: you sound like a compiler intrinsic fanboy
<courmisch>
elenril: by the way, FFmpeg not only has MMX, but even ARMv5 assembler
<Sean_McG>
I'd love to know if someone has an embedded application that uses FFmpeg on such a device
<courmisch>
even iPhone 3G and Nokia 800 where ARMv6
<JEEB>
yea, olden arm stuff is getting deprecated on the kernel level :)
<JEEB>
courmisch: yea those two are modern devices :D
<Lynne>
wow, they're probably killing off stm32f in 2026
<courmisch>
RISC-V world domination
<Lynne>
probably because no one was able to get any at all during the pandemic/post-pandemic shortage
<courmisch>
elenril: "
<courmisch>
elenril: micro-architecture implementation is a simple, five-stage, single-issue, in-order pipeline that is not vulnerable to the Meltdown and Spectre exploits that frequently occur in common, out-of-order machines. "
<courmisch>
somebody
<courmisch>
's bug is someone else's feature
<Lynne>
just don't rely on non-costant time cryptographic implementations or someone will guess the password from nothing more than power jumps
linjie has quit [Quit: Connection closed for inactivity]
<courmisch>
JEEB: government is obviously covering it up, but I saw first hand that here was a power outage in Kamppi/Länsisatama last week
<JEEB>
:o
<JEEB>
helsinki energia clearly failing
<courmisch>
Yaoi Day Flash Sale Special Discount. Hmm, thanks but no thanks.
elChippo has joined #ffmpeg-devel
<essbee>
I'm reading through the coding rules at https://www.ffmpeg.org/developer.html#toc-Coding-Rules-1, where mixed declarations and statements are discouraged. I found a couple of examples where this rule is violated in ffplay.c. Is this rule still valid?
AbleBacon has joined #ffmpeg-devel
<courmisch>
essbee: uh, IME, the compiler warns when you violate that rule (even though it should be very highly irrelevant now that we require C11)
johge has joined #ffmpeg-devel
<Lynne>
I'm all for getting rid of it as a rule, but keeping it as a discouragement
<Lynne>
but elenril says no :(
<Lynne>
its really liberating, you should give it a try
quietvoid has joined #ffmpeg-devel
johge has quit [Remote host closed the connection]
johge has joined #ffmpeg-devel
<courmisch>
Lynne: his Pentium MMXs probably can't handle it
MrZeus has joined #ffmpeg-devel
<Lynne>
he's got literally tens of thousands of pentium MMXs, plus a special compiler to run code on them
<courmisch>
still waiting for the Elenrilium RV64IMAFDQV processor
<courmisch>
systemd crashed my K230
MrZeus has quit [Ping timeout: 252 seconds]
johge has quit [Remote host closed the connection]
johge has joined #ffmpeg-devel
<Sean_McG>
cute.
haihao has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<thardin>
lennart strikes again
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<essbee>
I tried to submit a patch by following the documentation of ffmpeg.org and I got a CC to my gmail account. The mail does not appear yet on patchwork or the website indexing the mailing list. Is there a delay, or did I mess up somewhere along the line?
<ePirat>
essbee, did you subscribe to the ML before sending it?
<essbee>
Ah no
<ePirat>
essbee, got it now
<essbee>
Ah great!
<essbee>
Hopefully you only got one, subscribed and resubmitted
<ePirat>
yeah
AbleBacon has quit [Read error: Connection reset by peer]
AbleBacon has joined #ffmpeg-devel
<Lynne>
do DASH segments have to contain a keyframe?
cone-817 has quit [Quit: transmission timeout]
<JEEB>
I think not, otherwise low latency DASH or HLS wouldn't work too well
<JEEB>
actually DASH is still free as a spec so that's actually verifiable
<JEEB>
ok, so trying to piece this together since I don't see a random access flag for segments, and reading that "segments that are not yet complete at the time of request" are a thing, apparently DASH went for it being OK to show partially available segments
<JEEB>
while low latency HLS went for segments having to be always available, and thus you got those segments that don't have to be random access point'able
<JEEB>
*always fully available
<JEEB>
and yea, that low latency document compares CMAF "chunks" (whatever those were) against DASH segments
<JEEB>
> One reason for using chunks instead of shorter Segments is that Segments must start with an SAP type 1 or 2, i.e., for
<JEEB>
video a closed GOP. This decreases the coding efficiency of video. CMAF Chunks do not have this restriction since
<JEEB>
they are generated for neither bitrate switching nor randomly accessing the Representation
<JEEB>
Lynne: I guess the answer is that while DASH lets you define random access type for the whole thing (closed, open, gradual), it did not seem to have a per segment flag to note whether a specific thing contains a random access point or not. and looking at how they talk about allowing for requests of non-fully available segments, I think that is how DASH handles lower latency.
<JEEB>
while low latency HLS does contain non-random access point segments
<JEEB>
since I guess they want the media server to only serve fully available segments
<JEEB>
also DASH then has a separate Resync element which lets you tell if there are multiple CMAF chunks (are they talking about fragments?) within a segment so a client does not have to download the full thing to do random access
essbee has quit [Remote host closed the connection]
<cone-933>
ffmpeg Rémi Denis-Courmont master:c48213b2dc0b: lavc/audiodsp: drop opposite sign optimisation
<cone-933>
ffmpeg Rémi Denis-Courmont master:2f083fd5817f: lavc/audiodsp: drop R-V F vector_clipf
<cone-933>
ffmpeg Rémi Denis-Courmont master:1b2a925e94c7: lavc/riscv: drop probing for F & D extensions
System_Error has joined #ffmpeg-devel
<Lynne>
JEEB: could a situation happen when a P-frame from one segment depends on a B-frame from the previous segment?
essbee has quit [Ping timeout: 245 seconds]
Krowl has joined #ffmpeg-devel
<JEEB>
Lynne: I could see something like leading pictures in HEVC making that quite possible. leading pictures being P frames after the random access picture which have a PTS before the random access frame (and thus can depend on stuff before the random access point).
<JEEB>
DASH does allow for open GOP and gradual refresh, so that's another possibility as well
<Lynne>
so segments don't have any special meaning then, I guess
<Lynne>
I'm wondering why the dash demuxer isn't implemented on a lower level
<Lynne>
where a single demuxer context is used, which just ignores EOF, reads new segments/fragments and maintains the same state throughout
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]