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
Kei_N has joined #ffmpeg-devel
arch1t3cht2 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht2 is now known as arch1t3cht
Guest3917 has quit [Ping timeout: 252 seconds]
Son_Goku has quit [Ping timeout: 252 seconds]
jdek has quit [Ping timeout: 252 seconds]
Guest3917 has joined #ffmpeg-devel
Son_Goku has joined #ffmpeg-devel
jdek has joined #ffmpeg-devel
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
<nasso>
not sure if i should ask this here or in #ffmpeg, but has anyone ever asked for a light theme on the documentation website? i couldn't find any ticket on trac
<nasso>
my main concern is accessibility, as it's pretty hard on my eyes to navigate the website in a very bright room
<JEEB>
nope, no such requests to my knowledge
<JEEB>
web site specific stuff is on the web repo, and then the stuff talking about options etc are actually built off the stuff that also generates man pages :)
<JEEB>
llyyr: so NAL unit types 62 and 63 now get ignored?
<nasso>
so the change would just need to be on the web repo, right?
<JEEB>
this kind of hints that something is off since usually you get the profile from the parameter sets
<JEEB>
in this case there's just... none
<JEEB>
llyyr: so if you compare to trace headers before, did you get parameter sets?
<llyyr>
no, everything is the same.
<llyyr>
previously ffmpeg just soldiered through the errors, now after that change it explicitly fails
<JEEB>
yeh, but at least we have now verified that we are not missing parameter sets
<nevcairiel>
hevc buffering period? i dont even see where that is parsed at all
<JEEB>
or have a bug in that bit
<JEEB>
nevcairiel: it's a lot of NAL units referring to SPS
<JEEB>
the first might just be a SEI of some sort
<nevcairiel>
which must be returning something thats not AVERROR_INVALIDDATA?
<JEEB>
llyyr: so what seems to be happening is that this mkv file doesn't have anything in the decoder initialization data (or broken data?) and thus the decoder has no parameter sets, and then the stream *also* does not start with a random access point which would contain the parameter sets. if after decoding N frames it succeeded then at some point you should have a parameter set there (if you raise the
<JEEB>
number of frames in the trace_headers command it should show up)
<JEEB>
let me know if that is the case, which would then more or less confirm my theory
<nevcairiel>
from what I'm seeing, any unknown SEI will return FF_H2645_SEI_MESSAGE_UNHANDLED, which decode_nal_unit now sees as a fatal error, maybe special casing that is all thats needed
<nevcairiel>
hm or maybe not, its not a negative value
<nevcairiel>
error should really get into the habbit of logging what the error code is
<JEEB>
yea
<nevcairiel>
decode_nal_sei_pic_timing return ENOMEM if the SPS isnt available
<nevcairiel>
which seems like a bizarre choice of return value
<JEEB>
:D
<nevcairiel>
that should just be invaliddata i guess
<nevcairiel>
and then it should work again
<JEEB>
interesting choice indeed
<JEEB>
llyyr: if you have a clone around, try poking at libavcodec/hevc/sei.c::decode_nal_sei_pic_timing's sps check in the beginning that returns ENOMEM atm to AVERROR_INVALIDDATA
<JEEB>
quietvoid: ok, thanks for noting that you also had a delay
<JEEB>
I could try doing a LGTM as a manual In-Reply-To from archive
<nevcairiel>
email is just a very limited thing, why arent we moving forward on some new workflows
<JEEB>
I think at some point I wanted to start a thread on alternatives to move to. personally I'd like videolan's gitlab, but there was a person open to hosting ffmpeg's own until people notice that maintaining a thing is not fun.
<JEEB>
then there were some other things and github as the other alternatives. and then there would be some sort of decision
<elenril>
Lynne: no special reason
<elenril>
just randomly picked a codec with many files
<nevcairiel>
i would also be happy to assist with hosting something like gitea/forgejo or our own gitlab, in the time of docker such things arent that much effort anylonger, as long as i'm not ending up being the only person, i would hope hosting wouldnt be the lynchpin in a decision
SystemError has quit [Remote host closed the connection]
zsoltiv_ has quit [Ping timeout: 246 seconds]
feiw2 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
<Lynne>
I'd be happy to admin a forgejo instance
<wbs>
ramiro: btw, on which device do you test A55?
ccawley2011 has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 246 seconds]
feiw1 has joined #ffmpeg-devel
feiw2 has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 260 seconds]
Sean_McG has quit [Ping timeout: 260 seconds]
kepstin has quit [Ping timeout: 260 seconds]
kepstin has joined #ffmpeg-devel
Sean_McG has joined #ffmpeg-devel
bcheng has quit [Ping timeout: 260 seconds]
bcheng has joined #ffmpeg-devel
<JEEB>
apparently I finally got the email at... > Fri, Aug 30, 2024 at 2:20 PM (Delivered after 22784 seconds)
jarthur has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<Daemon404>
there has been some major delay lately
<Daemon404>
i think jamrial mentioned it
darkapex_ has quit [Remote host closed the connection]
darkapex_ has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
<ramiro>
wbs: Orange Pi 5 Plus (rk3588). it has both a55 and a76, so I can easily benchmark both locally.
<wbs>
ramiro: ah, I see
<ramiro>
wbs: btw the new patch I just sent (deinterleaveBytes) is basically just a copy of interleaveBytes with ld2/st1 instead of ld1/st2. the only place that is a bit different is that I changed zip1 to shrn/xtn.
<wbs>
ramiro: ah, nice, that looks reasonsble. I guess the same could be done uzp1/uzp2 too, but it's probably equivalent
<ramiro>
I don't know which cores are affected by these commits. it improves for A55, and has no changes for A76. but I don't know if it may negatively impact other cores, and I don't plan on testing older cores.
feiw1 has joined #ffmpeg-devel
feiw2 has quit [Remote host closed the connection]
IndecisiveTurtle has quit [Ping timeout: 272 seconds]