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.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
feiw has joined #ffmpeg-devel
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht0 is now known as arch1t3cht
cone-039 has quit [Quit: transmission timeout]
feiw1 has joined #ffmpeg-devel
feiw has quit [Read error: Connection reset by peer]
feiw2 has joined #ffmpeg-devel
feiw1 has quit [Read error: Connection reset by peer]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
jamrial has quit []
tufei has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw2 has quit [Remote host closed the connection]
microchip__ is now known as microchip_
AbleBacon has quit [Read error: Connection reset by peer]
feiw2 has joined #ffmpeg-devel
feiw1 has quit [Read error: Connection reset by peer]
lexano has quit [Ping timeout: 245 seconds]
lexano has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
johge has quit [Remote host closed the connection]
johge has joined #ffmpeg-devel
jeroen_ has joined #ffmpeg-devel
<jeroen_>
Hello
<jeroen_>
I maintain the R bindings. As of ffmpeg-7 we get an error, only on arm64 (not x86_64) in avcodec_receive_frame() that says: "Internal bug, should not have happened".
<jeroen_>
The only reproducer I have is with R code :/ Is this something I should report?
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
johge has quit [Remote host closed the connection]
johge has joined #ffmpeg-devel
<elenril>
well, internal bugs should not hapen
<elenril>
but then it being arch-specific is suspicious
<elenril>
does it happen with a specific input?
<jeroen_>
Actually I also reproduced it on macos-intel now
<jeroen_>
So it's MacOS specific, not arch specific.
<JEEB>
fun
<jeroen_>
I did confirm that the bug does not appear with ffmpeg@6 in macos, and also that it does not appear with ffmpeg-7 in Debian.
<jeroen_>
The fail happens when encoding pcm audio data with more than one channel
<jeroen_>
For any audio input
<jeroen_>
Ah some more output: An invalid frame was output by a decoder. This is a bug, please report it.
<elenril>
so did you mean _decoding_ pcm?
<elenril>
possibly there's a bug in your channel layout handling?
feiw2 has quit [Remote host closed the connection]
feiw2 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<jeroen_>
Yes the example converts 2 channel s32le pcm into mp3
mkver has joined #ffmpeg-devel
<jeroen_>
Possibly a bug on my side, though it has worked for many years and still does on Linux.
<elenril>
the big change in 7.0 was new channel layout API
<elenril>
and this failure could be caused by incorrect channel layout setup
<elenril>
can you link to the code that handles this?
<elenril>
setting channels after opening the decoder is very naughty
<elenril>
and if I'm reading it right, it happens specifically for pcm
<jeroen_>
Yes I think what happens here is that we have to specify the number of channels that exist in the s32le input data?
<elenril>
if you want to override the channel count/layout, you need to do it before avcodec_open2()
<jeroen_>
What do you mean override? I thought there was no way to know the channel count/layout from a s32le blob?
<JEEB>
in the sense that you set it as opposed to expect it got read from the input data format
<elenril>
I mean the code from line 181 to 191
cubicibo has joined #ffmpeg-devel
<JEEB>
funny how this fails only on macOS tho
<elenril>
it sets decoder properties based on some information you got somewhere
<elenril>
which you're not allowed to do after the decoder is open
<jeroen_>
Yes indeed, I was under the impression that one always needs to supply the PCM input channels because there is no metadata in the s32le blob to infer the number of channels from the input.
<elenril>
right, but that's not the issue
<elenril>
the issue is you're doing it in the wrong place
<JEEB>
yea, I tried to explain that the word override does not mean it's bad. it's just that you were doing it after X already happened
<jeroen_>
If I invert the order and set those channels first, then `avcodec_open2()` fails with "Invalid channel layout"
<elenril>
then my guess is, there's some nontrivial channel layout already in there
<elenril>
and by ovewriting the channel count you're making it inconsistent
<jeroen_>
You mean inconsistent with the pcm? The input is just 2 channel s32le. I tried a few example files and they all had the same issue.
<elenril>
see what av_channel_layout_describe() says before you set the channel count
<jeroen_>
`av_channel_layout_describe() ` says `mono` before setting the count
<elenril>
which means that the order is native, and the mask is 1
<elenril>
then you override the channel count to whatever, leaving the order and the mask as they were, and now inconsistent with the channel count you set
<elenril>
what you should do is 1. uninit the existing channel layout 2. set the channel layout fully, i.e. order, channel count, possibly mask when the order is native
<jeroen_>
Okay. OK so I understand now what has caused the change in ffmpeg-7 which gives me at least a quick fix to start. This line no longer runs for my PCM decoder: https://github.com/ropensci/av/blob/master/src/video.c#L184-L185. So this means that in ffmpeg-7 the default `ch_layout.order` is no longer `AV_CHANNEL_ORDER_UNSPEC` at least on macos (perhaps it is just uninitiated I dont know)
<elenril>
it should never be uninitialized
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<elenril>
seems the default in the lavf pcm demuxer is "mono"
<Lynne>
what I mentioned matters most on in-order systems (rpi 3, e.g. the last rpi that mere mortals could buy)
<Lynne>
you should use 4 scalar regs for the memory addresses too, and avoid using ld1 ..., x1, those adds aren't free and between each load and the next one using the same offset reg there's latency
<ramiro>
Lynne: line_size comes in w1, but I'm currently using x1 to post increment, which checkasm doesn't like (garbage at higher 32 bits). I'm searching a bit but haven't found something similar to what we do for x86_64 to convert the register from 32 to 64 bit.
<ramiro>
uxtw it seems...
Livio has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<ramiro>
the first version (unrolled, one at a time, always using v0/v1 for uadalp) still seem to be the fastest.
AbleBacon has joined #ffmpeg-devel
wastekoko has quit [Ping timeout: 252 seconds]
wastekoko has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
wastekoko has quit [Read error: Connection reset by peer]
wastekoko has joined #ffmpeg-devel
<Lynne>
ramiro: you should test on something else, ideally something in-order
<Lynne>
this is all splitting hairs though
<Lynne>
what the function does is a prefix sum, which can be parallelized using some more efficient algorithms, though not sure it would be worth it on arm64
Krowl has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
<courmisch>
ramiro: can't you sum columns in parallel in an accumulator vector and calculate the sum only at the end?
<courmisch>
ah nvmd that's already what you do
<courmisch>
ramiro: I would guess write-back is the problem
<courmisch>
ramiro: do I presume that you have mpegenvdsp checkasm code somewhere?
Krowl has quit [Read error: Connection reset by peer]
kekePower has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 244 seconds]