On 01.03.2017 16:21, Nicolas Dufresne wrote: > Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit : >> - on output side you have encoded bytestream - you cannot say about >> interlacing in such case, so the only valid value is NONE, >> - on capture side you have decoded frames, and in this case it >> depends >> on the device and driver capabilities, if the driver/device does not >> support (de-)interlacing (I suppose this is MFC case), interlace type >> field should be filled according to decoded bytestream header (on >> output >> side), but no direct copying from output side!!! > I think we need some nuance here for this to actually be usable. If the > information is not provided by the driver (yes, hardware is limiting > sometimes), it would make sense to copy over the information that > userspace provided. Setting NONE is just the worst approximation in my > opinion. The whole point is that s_fmt on output side is to describe format of the stream passed to the device, and in case of decoder it is just mpeg/h.26x/... stream. It does not contain frames, fields, width, height - it is just raw stream of bytes. We cannot say in such case about field type, there is not such thing as interlaced byte stream. Using s_fmt on output to describe things on capture side look for me unnecessary and abuses V4L2 API IMO. > > About MFC, it will be worth trying to read the DISPLAY_STATUS after the > headers has been processed. It's not clearly stated in the spec if this > will be set or not. > Documentation for MFC6.5 states clearly: > Note: On SEQ_DONE, INTERLACE_PICTURE will return the picture type to > be decoded based on the > sequence header information. In case of MFC5.1 it is unclear, but I hope HW behaves the same way. Anyway I agree it will be good to fix it at least for MFC6.5+, any volunteer? Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |