Hi Daniel, On 10/6/22 20:15, daniel.almeida@xxxxxxxxxxxxx wrote: > From: Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> > > A virtual stateless decoder device for stateless uAPI development > purposes. > > This tool's objective is to help the development and testing of > userspace applications that use the V4L2 stateless API to decode media. > > A userspace implementation can use visl to run a decoding loop even when > no hardware is available or when the kernel uAPI for the codec has not > been upstreamed yet. This can reveal bugs at an early stage. > > This driver can also trace the contents of the V4L2 controls submitted > to it. It can also dump the contents of the vb2 buffers through a > debugfs interface. This is in many ways similar to the tracing > infrastructure available for other popular encode/decode APIs out there > and can help develop a userspace application by using another (working) > one as a reference. > > Note that no actual decoding of video frames is performed by visl. The > V4L2 test pattern generator is used to write various debug information > to the capture buffers instead. > > Signed-off-by: Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> > --- > > The visl decoder is meant as a tool to help developers working on the > userspace stateless codec stack. It allows userspace code to run even > when no hardware is available. It also offers tracing through debugfs > and ftrace. It serves as yet another model for new drivers and it can be > used in automated testing. In particular, it can be used with existing > testing systems, one of which being the Chromium CQ. > > The Chromium CQ runs test suites on submitted code before it can land in > Chromium. Running the unit tests on a virtual machine will be made > possible through visl. These are the same tests that are run on real > hardware and they can be further enhanced to contain sanitizer builds. > This means that memory leaks can be found in the Chromium stack in an > automated way irrespective of hardware support. > > Developing a second userspace stack from a working one is easier using > visl. Its Ftrace-based tracing eliminates the cost of instrumenting the > working stack, and provides the exact same output format for all runs. > This is notoriously difficult to achieve with one-off printf-based > instrumentations, as invariably these would differ slightly by printing > out of order, or with slightly different format options, yielding a > dirtier diff which would make debugging harder. > > Note that the bitstream is not actually decoded by visl, the V4L2 TPG is > used to generate a test pattern with useful info instead. > Something else that I forgot to mention: it is a good idea to add Documentation/admin-guide/media/visl.rst documentation. Basically explaining how to use it, esp. the module options, debugfs and the tracing facility. Similar to what exists for vimc and vivid. Regards, Hans
