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
<michaelni>
ramiro, a comit from 2008, I would guess it maps white to white, black to black and may provide some biases to compensate for rounding of subsequent operations that existed in 2008. The number you quote is 0x2001D5B
<michaelni>
also its always possible that some mistake was done or a typo, especially if everything makes sense but one number doesnt
thilo_ has quit [Ping timeout: 246 seconds]
thilo_ has joined #ffmpeg-devel
aikaeksen has quit [Quit: Client closed]
MrZeus has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 276 seconds]
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
haihao has quit [Remote host closed the connection]
haihao has joined #ffmpeg-devel
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 260 seconds]
haihao has quit [Remote host closed the connection]
haihao has joined #ffmpeg-devel
jamrial has quit []
vipyne has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
arch1t3cht6 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 246 seconds]
arch1t3cht6 is now known as arch1t3cht
MrZeus has quit [Ping timeout: 252 seconds]
vipyne has quit [Quit: Leaving.]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
<Lynne>
how can hardware **not** support using B-frames as references?
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
<jkqxz>
Bad software layers on top of it?
<jkqxz>
Missing rate control would probably be a reason to say you don't do it.
Warcop has quit [Ping timeout: 252 seconds]
<Lynne>
the hardware supports encoding b-frames though
<jkqxz>
As would incomplete slice header support.
<Lynne>
does it not have plumbing to go from an encoded frame's reconstruction to be used as a ref?
<jkqxz>
Hardware companies are reluctant to expose how their hardware actually works, hence super-sekrit signed firmware to do anything.
<jkqxz>
Yes, obviously to a video person there is no difference, but if it's not an official feature then it will be very hard to get it.
<jkqxz>
(I'm assuming you are complaining about some Vulkan drivers here.)
<elenril>
how do hardware engineers come into being, one wonders
<haasn>
ramiro: it would make sense, unless benchmarks show otherwise
<haasn>
well
<haasn>
with my planned refactor this could possibly become negligible
<haasn>
because I plan on keeping each step inside the cache
<haasn>
at which point the overhead of first converting to 16 bit becomes negligible, since you need to do that anyway for dithering
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
SuperFashi has quit [Ping timeout: 252 seconds]
SuperFashi has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
<elenril>
speaking of omx
<elenril>
wbs: do you know if anyone still uses it?
<wbs>
elenril: not really, no
<elenril>
should we deprecate it then?
<JEEB>
even android is nowadays preferring codec2
<wbs>
dunno, maybe
<elenril>
codec2?
<wbs>
elenril: their own internal codec api abstraction
<elenril>
I thought codec2 was a speech codec
<JEEB>
welcome to overloaded words
* elenril
stabs google
<JEEB>
s/words/names/
<elenril>
stop inventing words
<elenril>
wbs: I mean do you see any good reason NOT to deprecate it?
<wbs>
elenril: not really, no
<elenril>
we did remove crystalhd and xvmc
<courmisch>
it's still used in embedded SBCs, but that's always some hacked up old FFmpeg
<courmisch>
I don't think it'll hurt to remove it in future FFmpeg versions
<wbs>
the main cases where I've seen it was older raspberry pis, and internally in android (where user code can't access it directly anyway, although the also-internal api IOMX was very close)
<wbs>
and in practice, it almost always required specific testing+tuning for each piece of HW
<wbs>
hmm apparently even the rpi4 still uses/supports OMX, with commits about that not very long ago (only a couple years ago)
<wbs>
and we didn't have OMX decoding (I did have code for that, but apparently never upstreamed it)
<courmisch>
there are SBCs other thab rPi
<courmisch>
those typically have semibroken OMXIL, no V4L2, no gstreamer
<elenril>
don't we have something for an rpi-specific decoding API?
<elenril>
mmal iirc
<wbs>
yes, that's probably why we don't have OMX decoding merged. but mmal doesn't do encoding
<JEEB>
yup
<JEEB>
rpi4 should have MMAL for the pre-HEVC formats, and then v4l2-requests decoder for HEVC
<wbs>
ah, why stick with one mess, when you can have two? :-)
<JEEB>
8)
<JEEB>
apparently someone started writing a wrapper for v4l2 for some of the older formats, but apparently those didn't work too well
<JEEB>
since it would go through mmal internally anyways
<JEEB>
wbs: I guess the mmal stuff they received from "upstream", and the requests stuff is their own development, so not surprising they don't want to touch stuff that "already works"
<wbs>
the fun thing about the rpi hw decoder, is that it uses OMX as API across the wire to the coprocessor, iirc. literally memcpy of the OMX structs over to the coprocessor
<wbs>
and MMAL was just a newly designed API on top of this, hiding OMX from the users
<JEEB>
fun design :D
<wbs>
and iirc there were fun aspects of this, because with a 64 bit userland, the OMX structs have a different size/layout. but this doesn't match the struct layout the DSP side expects
<JEEB>
yea
jamrial has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
arbitercoin has joined #ffmpeg-devel
<elenril>
I one saw a discussion where some hw people were asked 'why are you inventing a new API and not just use VA'
<elenril>
with the answer being it just didn't occur to them
<JEEB>
:D
<JEEB>
yea I did wonder the same thing
<elenril>
everybody else does it, so...
SystemError has quit [Remote host closed the connection]
<JEEB>
since like with ye olde MIPS stuff the user space overhead argument might have been valid, but at this point the aarch64 boards are fine running vaapi
<Daemon404>
elenril, easy, there is a competition for who can make the most perverse and insane api in the hw world
<Daemon404>
bonus points for horrible """pixel formats"""
<BBB>
hey you're back :)
<Daemon404>
since ages ago
<elenril>
>Looking for serious answers with out sarcasm, insults, or claims of simplicity.
<elenril>
lol
<Daemon404>
which mail is that form
<Daemon404>
from, evem
<Daemon404>
bloody keyboard, how do they work...
<elenril>
> Top Secret <topsecretscream@gmail.com>
<elenril>
but also > Message-Id <PH0PR16MB41978CD445B404C05B3D375CFC9B2@PH0PR16MB4197.namprd16.prod.outlook.com>
<elenril>
something smells weird there
<BtbN>
I didn't even read that sender, wtf
<elenril>
it's probably DHS
<Daemon404>
more likely just normal anonymous internet weirdos
<Daemon404>
theyre not even trying to introduce a backdoor.