I’m sure you have all seen the following on a channel in the middle of the night. It’s a set of colorbars.
[lightbox title=”Em28xx video quality” href=”../../blog/wp-content/uploads/2010/01/tvtime-output-085940-PM-300×200.png”]
[/lightbox]
The above colorbars were taken using KernelLabs’ analog generator, in conjunction with an em28xx based device. I had been bothered about the general picture quality on the em28xx for some time, but without a good reference signal it can be very difficult to ascertain what is wrong with a picture.
If you click on the above image to see the full version, something might jump out at you. Notice the pixelation along the vertical edges of the color bars. This is an artifact of interlacing that is usually only seen when there is fast horizontal motion. But this is a steady picture, so we shouldn’t be seeing that here. So, why do we see this here?
I used the v4l2 capture-example tool to capture a raw yuyv sample, and then converted it to RGB and opened it in the Gimp. This approach works around the fact that the screenshot feature in tvtime saves in PNG format, and I don’t want to be confused by compression artifacts.
Once you have the raw frame opened in the Gimp, you can now take a *very* good look at it. And zooming into the top left corner of the frame shows the problem (magnified to 1600x):
[lightbox title=”Em28xx video quality” href=”../../blog/wp-content/uploads/2010/01/em28xx-magnify.png”]
[/lightbox]
There is an apparent problem with the formatting of the video such that the start of the top field is off by one pixel (the pixel is green because that’s the default color before the driver populates the buffer). This means that the two fields are misaligned, resulting in a zigzag pattern on vertical edges. And combined with the deinterlacing algorithms employed by application such as tvtime, it results in a slightly blurry image.
I’ll have to dig into the driver source and identify where the buffers are not being properly populated, but at least I know what the problem is. Looking at live video, all you can say is that the picture “just looks bad”, but with the proper test signals you can actually identify what is wrong with the picture so that you know where to look in the driver code.
This is fascinating stuff. I’m really enjoying following along and looking forward to using tvtime on my ati 600.
Note those checker patterns may be due to: http://en.wikipedia.org/wiki/Dot_crawl
Also png uses lossless compression.
Note some em28xx devices have onboard deinterlacing which can be enabled.
cheers,
Pádraig.
Pádraig,
While it is possible that there is some dot crawl, it usually won’t be aligned on an interlace boundary like the above, and it also won’t appear with video sources other than CVBS.
PNG does employ a lossless compression algorithm, however I have no idea what filtering tvtime does beforehand, nor do I have any knowledge as to what colorspace compression is being performed as a result of the conversion to PNG (if any). PNG is still a good format in general, but not necessarily a good choice compared to capturing the raw YUYV data (where I can be assured that no loss is incurred between the driver and the viewer).
According to all of the datasheets I have seen, I am not aware of versions of the em28xx that have an onboard deinterlacer. The em28xx does support both interlaced and progressive inputs, and in some cases a product that has an em28xx may also have a video decoder that can do deinterlacing in hardware (the PCTV Ultimate is one such example, as it has an saa7136). It’s possible that they added a deinterlacer in the em2884 or newer (I haven’t seen the specs).
Cheers,
Devin