Le jeudi 11 avril 2019 à 09:29 +0800, Randy Li a écrit : > > We agreed with Maxime and Ezequiel that there will be two distinct > > format, V4L2_PIX_FMT_H264_SLICE_RAW and V4L2_PIX_FMT_H264_SLICE_ANNEXB. > > And user-pace will take care of providing the right information. > > I have no idea on what does the SLICE_RAW mean here. If you skip the NAL headers, SLICE_RAW is what is left. This is exactly what is passed in VAAPI, and what makes Rockchip HW difficult to support through this abstraction apparently. The rationale is that all the information that was in the rest of the bitstream is already passed in C structures. If this isn't the case, let me know, since it would be a bad name indeed. Paul asked us why not always required ANNEX-B with start code as a super set. This is not very efficient, since it means that whenever you have a stream from an ISOMP4 media, you endup having to convert the AVC headers into ANNEX-B start code, and you loose the optimization the AVC header provides (AVC format is basically just a NAL type and it's size, so you can navigate through the stream with very little reads). The other thing is the memory alignment the require needs. I suspect that if the HW require SLICE_RAW, you cannot just pass a random pointer offset. So you'd need another buffer the userspace data to. Hidden copies in drivers are quite bad, it's better to leave it to userspace when we can in my opinion. Now that I'm saying that out-loud, I wonder how the "one v4l2 buffer per frame" restriction can be respected for SLICE_RAW. The receiver would have no way to know where each slices are. Isn't there a big flaw in this restriction ? Or did I miss-understood the format, and SLICE_RAW is a bad name ? > > Annex B describe a byte stream format but it doesn't mean it should > ship slice data with SPS or PPS SLICE means it won't pass SPS or PPS in-band. Only slice NALs and per slice auxiliary data if there is any. Do Rockchip needs the original SPS/PPS bitstream ? If so, all of them ? or just the activated one ? And when ? > > The problem of bootlin demo is it follows Annex B but withou a start > code !!!! We'll fix that if we decide to use this for testing. It was all early and unspecified. SLICE_ANNEXB will have a start code of course, as I don't see how you can call this ANNEXB otherwise. And I'm pretty sure the reason Rockchip need it is to be able to split the slices (we need to keep in mind that multiple slices per frame is commonly used in video conference streaming). The format documentation should be really clear about what it is, and if another HW with another format comes that does not match, it should define and document a new format. cheers, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
