On 11/04/2016 09:55 PM, Hugues FRUCHET wrote:
Hi Randy,
thanks for reply, some comments below:
On 10/27/2016 03:08 AM, Randy Li wrote:
On 10/26/2016 11:09 PM, Hugues FRUCHET wrote:
Hi,
This RFC aims to start discussions in order to define the codec specific
controls structures to fulfill the low-level decoder API needed by non
“Stream API” based decoders (“stateless” or “Frame API” based decoders).
Several implementation exists now which runs on several SoC and various
software frameworks.
The idea is to find the communalities between all those implementations
and SoC to define a single unified interface in V4L2 includes.
Even if “Request API” is needed to pass those codec specific controls
from userspace down to kernel on a per-buffer basis, we can start
discussions and define the controls in parallel of its development.
Yes, I have sent a one for H.264 decoder and JPEG encoder.
We can even propose some implementations based on existing V4L2 control
framework (which doesn’t support “per-frame” basis) by ensuring
atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]). Constraint
can then be relaxed when “Request API” is merged.
I would like to propose to work on a “per-codec” basis, having at least
2 different SoC and 2 different frameworks to test and validate controls.
To do so, I have tried to identify some people that have worked on this
subject and have proposed some implementations, feel free to correct me
and enhance the list if needed:
* MPEG2/MPEG4
- Florent Revest for Allwinner A13 CedarX support [1] tested with VLC
-> libVA + sunxi-cedrus-drv-video -> V4L2
- Myself for STMicroelectronics Delta support [2] tested with
GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
* VP8
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested with
Chromium -> V4L2
- Jung Zhao for Rockchip RK3288 VPU support [4] <cannot find the
framework used>
There is rockchip VDPAU driver supporting it, but it is .
Could you point out the code that is used ? Which application is used on
top of VDPAU ?
https://github.com/rockchip-linux/libvdpau-rockchip
* H264
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested with
Chromium -> V4L2
- Randy Li for Rockchip RK3288 VPU support [6] tested with VLC? ->
libVA + rockchip-va-driver -> V4L2
I only tested it with Gstreamer -> VA-API element -> Rockchip VA-API
driver -> V4L2
OK got it, thks !
VLC?
-> libVDPAU + rockchip-va-driver -> V4L2
I can work to define MPEG2/MPEG4 controls and propose functional
implementations for those codecs, and will be glad to co-work with you
Florent.
But it may not work with Rockchip's SoC, you may check the following branch
https://github.com/hizukiayaka/rockchip-video-driver/tree/rk_v4l2_mix
I have checked code and I have only found H264 support, do I miss
something ?
No, I have said above, only H264 decoder and JPEG encoder are supported
in currently Rockchip VA-API driver. And H264 decoder depends on a
Rockchip H264 parser. The rk_v4l2_mix just a branch make that clearly,
it could get what the VA-API doesn't offer from code.
I can help on H264 on a code review basis based on the functional H264
setup I have in-house and codec knowledge, but I cannot provide
implementation in a reasonable timeframe, same for VP8.
Apart of very details of each codec, we have also to state about generic
concerns such as:
- new pixel format introduction (VP8 => VP8F, H264 => S264,
MPG2 => MG2F, MPG4 => MG4F)
I don't think it is necessary.
But currently it is done that way in all patches proposals I have seen
so far, including rockchip:
rockchip_decoder_v4l2.c:{VAProfileH264Baseline,V4L2_PIX_FMT_H264_SLICE},
It is Google's idea, it would be removed with new version kernel driver
of mine. Also I don't like multiplanes image format from Google driver.
We have to state about it all together. Seems natural to me to do this
way instead of device caps.
Doing so user knows that the driver is based on "Frame API" -so
additional headers are required to decode input stream- and not
on "Stream API" -H264 stream can be decoded directly-.
> We should probably use something else then "STREAMING" in the
> capabilities instead of duplicating all the encoding formats (exception
> to H264 byte-stream and H264 AVC, that also applies to streaming
> drivers and there is not easy way to introduce stream-format in the API
> atm). Other then that, this solution works, so it could just be
> considered the right way, I just find it less elegant personally.
I agree with Nicolas.
Best regards,
Hugues.
[0] [ANN] Codec & Request API Brainstorm meeting Oct 10 & 11
https://www.spinics.net/lists/linux-media/msg106699.html
[1] MPEG2 A13 CedarX http://www.spinics.net/lists/linux-media/msg104823.html
[1] MPEG4 A13 CedarX http://www.spinics.net/lists/linux-media/msg104817.html
[2] MPEG2 STi4xx Delta
http://www.spinics.net/lists/linux-media/msg106240.html
[2] MPEG4 STi4xx Delta is also supported but not yet pushed
[3] VP8 Rockchip RK3288, RK3399? VPU
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0002-CHROMIUM-v4l-Add-VP8-low-level-decoder-API-controls.patch
[4] VP8 Rockchip RK3288 VPU
http://www.spinics.net/lists/linux-media/msg97997.html
[5] H264 Rockchip RK3288, RK3399? VPU
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-kernel/linux-headers/files/0001-CHROMIUM-media-headers-Import-V4L2-headers-from-Chro.patch
[6] H264 Rockchip RK3288 VPU
http://www.spinics.net/lists/linux-media/msg105095.html
--
Randy Li
The third produce department
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
