mchehab: can you apply this patch for vicodec? https://patchwork.linuxtv.org/patch/51223/
It solves a stupid media_build error.
ezequielg, excellent, I'll probably give it a shot sometime this week
hverkuil, by the way, is there any preference at all regarding ISO/CEI codec naming vs UIT-T naming?
I see a HEVC pixfmt, and H264, and MPEG2, so it feels like this lacks consistency
ezequielg: I was wondering about that as well. As far as I know all m2m devices use the same mutex for both queues in any case.
paulk-leonov: we long ago abandoned any pretense at consistency or standardization regarding pixel formats.
It's a lost cause :-)
I see :)
I would have preferred H265 instead of HEVC, but HEVC seems to be much more common in the industry, so it became HEVC.
hverkuil, would it matter that I call the slice format HEVC_SLICE or is H265_SLICE equally acceptable?
we standardized on HEVC for better or worse, so let's stick to that.
alright
paulk-leonov: what would be the meaning of "_SLICE" there?
tfiga, meaning coded slice data
as in, a group of macroblocks
(enough to allow decoding a full frame)
maybe that's not the right terminology for hevc?
how would that differ from non-"_SLICE"?
that should also include macroblocks I think?
tfiga, the non-_SLICE is for raw bitstream data
at least that's the convention for other pixfmts
okay, so you mean just the slice data alone?
yes exactly
excluding the associated metadata that's coded in the bitstream
I assume this is for the stateless API?
correct
paulk-leonov: I was wondering if it wouldn't make sense to include full bitstream data and just point to the parts of the buffer containing slice data
that would let us support not-fully-stateful hardware with stateless API
e.g. decoders with various levels of brokenness in hardware/firmware making it require some additional data from userspace
tfiga: wouldn't that mean having to re-construct a bitstream that has already been parsed for video decoding APIs?
mripard: with what paulk-leonov mentioned, yes, but not what I'm suggesting, since the full bitstream would be in the buffer
unless the bitstream is actually further mangled and there is no way to give a byte offset to the slice data within it
no, I mean, APIs like libva
which parse the bitstream and send you only the slice data as far as I know
mripard: hmm, I don't know VAAPI too much, but it would indeed be a problem
I'd personally just fix those broken firmwares tbh...
I'm mostly thinking about mtk-vcodec and venus and their quirky handling of input buffers, especially with H264
pH5: thanks for correcting my misunderstanding about coda, I forgot about the copy into CAPTURE buffers
lyakh: aargghhhh there's a next one :-)
I thought the next one was Kieran's async patches, but your patch came first
pinchartl: so far the last one and it's "just" a doc. That should be the last one for now, I think... Maybe "forever." The only thing, that might still need to be added to that is adding more cameras that use the same metadata
are those cameras easy to source commercially ?
speaking of which, it can be done adding like a dozen of identical quirk entries to the driver, with the only different field being the idProduct, or it might be decided to do something smarter like making arrays of PIDs...
some of them are, I believe
I'm not opposed to a smarter solution :-)
I'd like to get access to one of those cameras for testing if possible
pinchartl: I'll raise that matter with appropriate authorities B-|
but I hope reviewing the documentation patch can be done without that?
lyakh: sure
I'm not trying to force your hand to send me a camera :-)
that seems to be my observation too so far
shuah: ping
shuah: i am trying to understand about kselftest media_tests. I've noticed they are not included as default targets.
shuah: I am considering the introduction of a test (more could come) that would not need any hardware, won't fail if the driver/subsys is not configured, and would take 2 minutes in the worst case (duration is random).
so I was playing with the idea of moving the current tests to TEST_GEN_PROGS_EXTENDED, and have this new test in TEST_GEN_PROGS.
and more could come based on vivid, vicodec, and the virtual bunch