Dexter image quality bug discovered, fix is available now!

I've suspected for a while that something was a little off with Dexter's image quality.  However, this is almost unnoticeable on a CRT, so I haven't prioritized investigating it.  Now that I am trying to finish Star Rider support, which relies on data being decoded from the video signal, I looked into video quality issues further and found a couple of minor problems.

After some troubleshooting, I found that there are two issues with Dexter's image quality:

1) the video is shifted one line from what it should be,

2) the video has an unfocused look

Issue #1 is caused by the raspberry pi itself.  I don't have a "proper" fix, but I can compensate by shifting the video 1 line within the Dexter software which seems to do the trick.

Issue #2 is caused because I am using bilinear filtering inside of the OpenGLES2 code that Dexter is using.  Combined with my shader to implement interlaced video, this was creating a bunch of subtle artifacts that give the unfocused look.  I turned off the bilinear filtering and that did the trick!

I've fixed both of these issues internally and am working on a public fix for everyone.  It will be free for all Dexter customers, new and old.

UPDATE: the fix is live now! :)

Here are two images showing before and after.

Before

After (ignore the extra text)

Please ignore the "Current video line shift" and "Scale factor" text in the second screenshot.  Those are debug messages that I added while troubleshooting this problem.

300+ Raspberry Pi's delivered!

So many pi's...

Software Development Insights: Debugging multiple threads on a raspberry pi (Dexter/Daphne)

Wanna see how to debug threads on a raspberry pi?  Or do you like anything geeky related to Daphne and Dexter?  This video may be of interest to you.

Software development insights: Debugging OpenMax problem related to Dexter

If you are an aspiring software developer, here is a 30 minute video I just recorded of me troubleshooting a software problem with Dexter.  It could be interest or boring depending on what you are looking for, haha.

Subtle defect with Raspberry Pi NTSC video output

I've known about this Raspberry Pi NTSC defect for a long time.  The reason I haven't reported it is because I have been too lazy to provide a way to reproduce the defect.  Unfortunately, reproducing the defect requires an oscilloscope but otherwise it is something most anyone should be able to do.

Tools used to reproduce defect:
- LM1881
- Rigol DS1054Z oscilloscope
- Raspberry Pi B+ with Raspbian dated 2015-02-16
- A specially crafted PNG file
- The 'fbi' program

First, let's talk about why I am using an LM1881.  I am using it as a trigger for the scope so that I can get a consistent stable view of the problem.  To make sure everyone is on the same page, here is a part of the datasheet that defines the "field" pin:

So when the field pin is high, an "odd" field is starting, when the field pin is low, an "even" field is starting.  Also, in NTSC land, odd means the top field and even means the bottom field.  This is kind of backward from how computer science geeks think of things, because we think that the first item in a list is 0 which is an even number.  But in NTSC land, the first line is 1, not 0.  For this reason, I will refer to the fields as odd/top and even/bottom to avoid confusion.

Here is the specially crafted PNG file that I made.  It is almost black except for the top 3 and bottom 3 lines:

The resolution is 640x480, the 480 part being the crucial part here to match NTSC's 480 lines.
The top and bottom lines are solid white.  The second and second to last lines are grey (7f7f7f) and the third and third to last lines are solid white but only go halfway across the screen.  I chose these lines so they could be easily identified on a scope.

To reproduce the problem, I booted the raspberry pi in NTSC mode (with a TV plugged in so I could see).  I then ran the command "fbi rpi_ntsc_test.png" and pressed 'V' to disable the status bar once the image was displayed.  I then hooked one scope probe up to the NTSC signal and the other scope probe up to the "field" (odd/even) pin of the LM1881.

Here are the results with comments:

Conclusion: At the very least, the fields are currently being reversed in this iteration of raspbian and the pi (B+).  There may be additional problems since the first visible line according to NTSC does not line up with what the Pi is doing (see my notes in the PNG files).

In the past, I observed potentially different issues on earlier revs of the pi which are not important to note anymore.