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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
aaabbb has quit [Killed (zinc.libera.chat (Nickname regained by services))]
aaabbb has joined #ffmpeg-devel
bbbccc has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<aaabbb>
memory corruption reproducible in latest btbn build. it is triggered by "ffmpeg -f lavfi -i color=s=1280x720:d=5 -c:v libx264 test.mp4" and then "ffplay -f lavfi -i movie=test.mp4,drawtext=text=foo". for it to be triggered ffplay has to take the input with -f lavfi -i movie= and not just -i
<aaabbb>
memory corruption happens about 50% of the time
<aaabbb>
that's all i can do right now but if someone wants to pull out a debugger they can narrow the problem faster than i can
<aaabbb>
it's actually really surprising that something like this wasn't noticed because it seems like it occurs with ANY input video if it's passed with "-f lavfi -i movie=anything.mp4,drawtext=text=foo" whether it's ffplay or ffmpeg. and yes i have tested my system to make sure it is not a hardware memory problem
haihao_ is now known as haihao
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
<cone-598>
ffmpeg sunyuechi master:538f217bbb4f: lavc/vp8dsp: R-V V put_bilin_hv
<cone-598>
ffmpeg sunyuechi master:bb5039b3cb79: lavc/vp8dsp: R-V V put_bilin_h v
<cone-598>
ffmpeg sunyuechi master:109daea6195c: lavc/vp8dsp: R-V V put_epel h
<cone-598>
ffmpeg sunyuechi master:6e77af1c220c: lavc/vp8dsp: R-V V put_epel v
<courmisch>
only rpi1 was Armv7?
<courmisch>
I guess AArch32 is very moribund
<courmisch>
except for embedded/IoT
<Lynne>
yeah, you could run arm64 on rpi2 onwards
<Sean_McG>
but with 4GB onboard there wasn't much point
<courmisch>
uh, AArch64 is a better ISA
<Lynne>
^^
<courmisch>
did away with much of the old Armv4 nonsense
<courmisch>
and ofc, double the GPRs
<courmisch>
I'm not a fan of writing assembler with 4 GPRs
<Sean_McG>
I bet it was never fun writing x86-32 asm
<courmisch>
much worse I suppose
<Lynne>
it was *tolerable*
<courmisch>
on Armv7, you could at least easily spill, although LDM/STM are terrible for CPU to implement
<courmisch>
but I remember going to pains to avoid having more than 4 parameters
<Lynne>
on x86 we regularly intentionally dirty a register used for function arguments if we need it, and just re-read it if we need the argument again
<Lynne>
x86inc gives us the address of the stack an argument used as r<N>m, e.g. r6m
<courmisch>
x86-32 is dead
<Sean_McG>
pretty much
<courmisch>
deader than Armv7 at least
<courmisch>
reminds me, I am supposed to be pissed at Debian for the pointless t64 mess
<psykose>
rpi1 is actually v6
<courmisch>
Armv6 is very dead
<psykose>
yea
<courmisch>
at least Armv7 can still be licensed
<psykose>
rpi2 is v7 (cortex A7)
<Lynne>
wbs had some concerns with the new FFT code as it removed armv6 vfm simd, as some rpi guy was very interested in keeping it alive
<courmisch>
I think it should be up to him to update the code, TBH
dionisis has quit [Quit: WeeChat 3.8]
Krowl has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<courmisch>
seems my BPI-F3 is enjoying its SZX-LGG
darkapex has quit [Read error: Connection reset by peer]
darkapex has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
qeed has quit [Quit: qeed]
<Gramner>
the annoying part about the debian t64 transition is that it affects 64-bit systems as well with weird package renames and such, which sometimes break things and requires manual package reinstalls
qeed has joined #ffmpeg-devel
<courmisch>
Gramner: and x86-32 where they stuck to 32-bit time_t anyway
<courmisch>
also riscv32 has had 64-bit time_t all along, but it's not supported by Debian
<courmisch>
Gramner: and most other 32-bit archs are deader than dead, so really, it was only for Armv6/Armv7
<Gramner>
also I wonder for how many years we will have to deal with the mess of having to install libfoot64 instead of libfoo
<courmisch>
oh I know the answer to that one
<Gramner>
before or after the heat death of the universe?
<courmisch>
since they will only remove t64 on library ABI breaks, it will still be there when you die on *some* packages
<Lynne>
I was surprised I didn't have to fix my system when I did the big package upgrade
<courmisch>
the moment that they decided to keep 32-bit time on 386, it became stupid
<Lynne>
and to this day I still find leftover packages that aren't t64
<courmisch>
I mean, I get why they did _that_ but they t64 was pointless
<courmisch>
Lynne: are you sure they are affected by the ABI change? if not, they won't get t64d
<Lynne>
they only get affected if other packages which are installed and using them get upgraded, I think
<Lynne>
btw we have a debian maintainer here, Sebastinas
<Lynne>
maybe he'd have a better idea why it was done this way
<courmisch>
well, I mean, obviously it was done this way because 64-bit time was The Right Thing to do and some people probably had taken some pride in it
<courmisch>
but when you consider which archs were actually concerned, it's just dumb
Livio has quit [Ping timeout: 268 seconds]
Kei_N has quit [Ping timeout: 264 seconds]
<Lynne>
couldn't the opposite be done? instead of t64 everywhere, t32 only on 32-bit systems?
Krowl has quit [Read error: Connection reset by peer]
kurosu has joined #ffmpeg-devel
s55 has quit [Ping timeout: 252 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
averne has quit [Remote host closed the connection]
averne has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
s55 has quit [Ping timeout: 268 seconds]
q66 has quit [Ping timeout: 255 seconds]
s55 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Livio has quit [Ping timeout: 240 seconds]
lexano has joined #ffmpeg-devel
sr55 has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 252 seconds]
s55 has quit [Ping timeout: 260 seconds]
s55 has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
sr55 has quit [Ping timeout: 268 seconds]
antonlyap has joined #ffmpeg-devel
sr55 has joined #ffmpeg-devel
cone-872 has joined #ffmpeg-devel
<cone-872>
ffmpeg Rémi Denis-Courmont master:c07af340ae90: lavc/riscv: explicitly require Zbb for MIN
<cone-872>
ffmpeg Rémi Denis-Courmont master:89029baebd01: lavu/riscv: allow requesting a second extension
<cone-872>
ffmpeg Rémi Denis-Courmont master:6c6313f1b581: swscale/riscv: explicitly require Zbb for MIN
<cone-872>
ffmpeg Rémi Denis-Courmont master:5afe734b6dc9: lavu/riscv: remove bespoke assembler for MIN
s55 has quit [Ping timeout: 268 seconds]
<antonlyap>
Hey, I have a question about Android MediaCodec and videos with resolution which isn't mod 16 (e.g 1080p). Currently they are handled as follows:
<antonlyap>
- the video is cropped using h264_metadata or hevc_metadata
<antonlyap>
- resolution is bumped to 1920x1088
<antonlyap>
The question is: how do I achieve 1920x1080 output with other codecs (such as VP9)? Is it possible without patching the code?
<antonlyap>
I could think of the following solutions:
<antonlyap>
- making it possible to disable the resolution alignment (some hardware can work with resolutions not divisible by 16)
<jkqxz>
Shouldn't that only be an H.264 constraint?
<jkqxz>
H.265 can do multiples of 8, though I guean encoder might not implement it.
<jkqxz>
VP9 should always be able to do arbitrary resolution.
<BtbN>
Does anyone happen to know how movenc handles alpha-in-hevc?
<BtbN>
For the VT encoder, it seems to "just work" with what falls out of the encoder
<BtbN>
But I see little evidence of alpha layer support in movenc itself
<JEEB>
the alpha layer should be in the same track, no?
<JEEB>
as a separate nuh_layer_id
<JEEB>
so you have a packet for the normal nuh_layer_id and then the other one for alpha. and before that you have a SEI which says that btw, this another nuh_layer_id is actually alpha
<JEEB>
so movenc wise they'd probably come in a single packet and that's it?
<JEEB>
-map 0:v -c copy -bsf:v trace_headers will probably tell
<BtbN>
nvenc just returns one buffer still, and two sizes. The end.
<BtbN>
And it doesn't "just work" :D
<BtbN>
there is no detectable alpha layer if I run it like this
<jkqxz>
(We probably shouldn't do that nowadays, since multilayer streams are actually a thing.)
<BtbN>
But how does it work for VT encoded HEVC then? :D
<JEEB>
they just have both the SEI that signals it, and the other layer
<BtbN>
oh wait, that's the decoder
<JEEB>
that's the CBS, which is used in bsf and some other things
<jkqxz>
Delete that to avoid it being hidden in traces, I mean.
<JEEB>
yea so you see the other nuh_layer_ids
<BtbN>
hm, so you mean it might already be working?
<JEEB>
or if not, you will see the diff between VT and nvidia's encoder's results
<JEEB>
if you pass some frames from both of them through trace_headers
<BtbN>
Well, I have no Apple-Devices, so can't do any testing on VT.
kurosu has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
sr55 is now known as s44
s44 is now known as s55
s55 has quit [Changing host]
s55 has joined #ffmpeg-devel
<BtbN>
jkqxz: so, if I see nuh_layer_id = 1 fields in the trace_headers output, it's working?
<antonlyap>
jkqxz: Probably it's because of hardware support. A comment in the code says that only mod 16 is guaranteed to work, but I can't find the source of that claim.
<mkver>
jkqxz: I thought we kept discarding higher layers in CBS because these may use some syntax structures that are not implemented.
sr55 has joined #ffmpeg-devel
<JEEB>
BtbN: and you also see the SEI that flags that that layer id is alpha
s55 has quit [Ping timeout: 268 seconds]
<BtbN>
All the id 1 ones fails with "PPS id 1 not available., Failed to read unit 2 (type 1)"