Danct12 has quit [Remote host closed the connection]
Danct12 has joined #cedrus
<ndufresne>
gamiee: there Hantro H1 encoder (h264) in Google Chrome OS downstream repo
<ndufresne>
and Paul K. made a presentation about renewing this, but I don't recall seeing the code yet
<gamiee>
ndufresne: thanks! Also, what you mean by "renewing this" ? Continue of work on Cedrus ?
<ndufresne>
The main goal is to determin where to abstract this, so that we can have a generic enough interface in the Linux kernel to make this usable by software framework
<ndufresne>
but it turns out we need to grew a deep understanding of the encoding process
<ndufresne>
Encoders are also difficult, because of the very patented "bitrate control" domain
<gamiee>
so this is the reason why there isn't any V4L2 request api encoders yet?
<ndufresne>
each vendor have it's own trick to accelerate and fine grain the control, which result in no consistency in terface
<ndufresne>
mostly yes, but also lack of commercial backing
<ndufresne>
vendors don't see the benefit of mainline, they use thin drivers that only handle memory allocation and irqs, and expose the registers directly to userspace (except the addresses)
<ndufresne>
and then they add proprietary code on top and make an "SDK"
<gamiee>
yeah, same as CedarX
<gamiee>
hmm, well, I'm just researching what options are, since I'm progressing with my PoC encoder library for Sunxi platform (which is actually just reverse engineered CedarX blobs)
<ndufresne>
on hantro, we have RK MPP that is open source, which helps, Cedar have had few Open Source releases in the past too
<gamiee>
CedarX have released only some API functions and memory allocation things, but directly the "encoding" process is still in blobs.
<ndufresne>
gamiee: do you include advance bitrate control, or are you doing that at frame level in userspace ?
<ndufresne>
In the work we did for these thing https://www.blaize.com/products/ai-edge-computing-platforms/ we had a short timeframe, so we basically started from Google Chrome OS code, and ported to VC8K interface, the encoder is limited, and uses a per-frame PID for rate control, which is ... good enough for network streaming, unlikely good enough for
<ndufresne>
television grade encoding
<gamiee>
ndufresne: at the moment, I'm just reaching the point of encoding at least one frame (Mostly initialization is done), so I didn't reached bitrate control yet much
<gamiee>
(afk, will be back in few hours)
<ndufresne>
the code is a bit hairy, so it's a small driver, no request, with a custom control, and there is a libv4l2 plugin that implements the userspace bits, and then it'S use with ffmpeg/gst v4l2 stateful encoder support
<ndufresne>
if I find the time, I'd redo that userspac code in gst, and move the driver to requests
<ndufresne>
(ffmpeg likely already got some rate control code)
<gamiee>
ndufresne: I'm back. Well, doing good rate control for television streaming is really problematic, I still didn't find out correct way of generating various timings for MPEG-TS (and the code in ffmpeg doing all this is kinda messy)
<ndufresne>
conformant mpeg-ts is it's own subject for usre
<gamiee>
yeah
<gamiee>
well, I'm kinda curious where is the bitrate controlled, but I don't think it's inside driver, maybe it's directly in IP Core implemented