hverkuil: cool, we'll probably have a patch for it in the near future
trying to make some use of v4l2-compliance for chrome os testing :)
bbrezillon: ndufresne: in theory G1 supports ASO, but apparently then entropy decoding must be done in the software
I'd just forget about it
bbrezillon, regarding ffmpeg vp8 streamoff/on issue, seems there is a patch in the works on ffmpeg-devel mailinglist regarding this, see http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244706.html
Kwiboo: cool!
tfiga: noted
tfiga: ping
hverkuil: pong
tfiga: Hi Tomasz!
I was wondering when to expect a new version of the stateful spec. What are your plans?
hverkuil: Good morning!
I wish I had a good answer to that question ;/
we're trying to get the Mediatek drivers in a good shape asap
I had to take over the MDP3 driver in the end
hopefully after I'm done with that...
Do you think someone else should take over? It is kind of blocking things.
If there is someone, why not :)
New drivers have to stay in staging until we finalize the spec and finish the compliance tests.
OK, then I guess I'll volunteer for that. If you have any drafts that you can share with me, then that would help. If you have any known TODOs that should be fixed, then please let me know that as well. It help me to get up to speed.
Great, thanks
Let me send you my semi-incremental changes on top of the last version
I'll start work on this next week (I'm out of the office Thu and Fri this week)
hverkuil: I was generally addressing the changes kind of chronologically in the email threads, so I'll also point you to the first messages that still have pending comments
tfiga: there is a huge amount of effort going on by a lot of people creating and improving codecs, which is very satisfying to see. So if I can help things along by unblocking bottlenecks (i.e. you! :-) ), then I'm happy to do so.
Regarding posted mediatek drivers: I'm ignoring them for now. If you want me to review a series, then just let me know via irc or a direct email.
hverkuil: sure, thanks
hverkuil: we probably need your help reviewing the mtk-vcodec patches posted by acourbot@ recently
I'm actually do a quick review of that right now.
hverkuil: sent you an email
actually there's probably less changes left than I thought
but I might have possibly missed something
tfiga: thanks! I'll start working on that next week.
mchehab: do you have a command line that builds a pdf of just the media documentation?
mchehab: found it: make SPHINXDIRS=media pdfdocs
hverkuil: regarding the missing SoB in the qv4l patch, do I just reply to your message with "Signed-off-By: [info]" and nothing else? Or do I resend the commit header with the addition?
KitsuWhooa: just reply with your SoB, that's enough.
Alright
Question for H.264/HEVC experts: are DPB, IDR, PPS and SPS specific to H.264 or do they apply to HEVC as well? The glossary (https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html) mentions only H.264 for those terms, but I'm not certain if that's correct.
hverkuil: PPS and SPS are definitely part of the HEVC syntax
DPB is a decoder-specific concept, but it also applies to HEVC decoders
and looks like IDR exists for HEVC as well
Do any of these apply to VP8/9 as well?
hverkuil: I am not familiar with VP8/9 at all, but maybe bbrezillon has some idea
hverkuil: nope, it doesn't seem to apply to VP8
paulk-leonov: bbrezillon: thanks for the info!
tfiga, ah ok, thanks, we decided not to support SW entropy, because we don't have any userspace for that and the API isn't super clear
hverkuil, vp8/vp9 do have need a DPB, since there is no reordering of frames, but there is references frames, which are marked as golden or alternative
arg, do NOT need a DPB
hverkuil, oh, and there is only 1 golden/alternative frame at one time if I remember correctly, so whenever a new golden is marked, the old one is done
it's also entirely frame base, there is equivalent of ANNEX-B in vpx
hverkuil: if you're building with Sphinx version 1.7 or upper, you could add SPHINXOPTS="-jauto"
that makes the build quicker
(I submitted a patch that will automatically add it - not merged yet)
paulk-leonov: good news: I figure out 10-bit HEVC decoding on H6
bad news: it needs larger buffers than we calculate at set format stage
so I did this hack: https://github.com/bbrezillon/linux/blob/rk-vpu-h264-vp8/drivers/staging/media/rockchip/vpu/rockchip_vpu_v4l2.c#L541-L544
and even at this point we don't know if it is 8-bit or 10-bit, so I always add extra size, just to be sure
I wonder if there is better solution
paulk-leonov: another bad news: P010 output format, which can be displayed, secondary output has to be used
this will be pain to support properly