Building a Standards Converter

[ppppenguin]

There are 2 palces where you need to think about number of bits. First is the coefficients. Here 8 bits are ample. The multipliers in the FPGAs are always wider than this so, unlike the days of discrete logic, you don't have to worry about it. If you want to be able to multiply by unity as against 255/256 then just add an extra bit. Or with 8 bits use 0-128. It's still enough.

The other question is how closely you define the position of each output line. AFAIK, 5 bit resolution here is ample. That's placing each line within 1/32 of a line width. I reckon you could halve that and get away with it. I see little point in going to any more bits, it just increases the size of the coefficient memories.

Since the results of different apertures etc are subjective it's very easy to fool yourself. Even with Test Card and direct A/B switch comparison.

[Cardigan]

I am using coefficients that 8 bits wide and first tried a aperture that was purely cosine in shape. The coefficients ranged from 0 to 254. The results were disappointing to say the least. I then tried introducing lift and am now using a lift of 51 with the coefficients ranging from 51 to 203. The lift made an huge difference. I guess that makes sense as a 405 line is wider than a 625 one so will always contain information from more than one line even if the 405 line lies directly on top of a 625 one. It makes sense now but I hadn't thought of it that way before.

I seem to recall reading somewhere that a "raised cosine" aperture is what the BBC used. I'm assuming in this case "raised" = "lift".

It looks very, very impressive indeed. Well done.

[`FRANK.C]

Hi cardigan
That's exactly it, a cosine shaped aperture raise/ lifted a certain amount above  zero. The document that I read about it in was from the BBC R&D and available here.

Frank

[`FRANK.C]

Summery things have to take priority but in between I have been slowly whittling away at this project.

I had more or less decided to change to the  TW9910 video decoder as it has separate Y output the same as the TVP5146 that I am currently using but the last time I looked in RS it is listed as a discontinued product. Mouser still has stock but by the time I get this project finished it will probably be discontinued there as well.
So I thought it was time to bite the bullet and follow Jeffrey's advice by converting to a 601 input. After studying the ITU-BT601 standard and Jeffrey's Video input file I managed to that and at least now I have the choice of using almost any decoder out there but I will most likely go for the TVP5150.
Apart from the Y I really only needed to extract the Field ID  as all else is taken care of by counters on the FPGA but I have also execrated and used the SAV (start of active video) signal to ensure the video is centered within the 720 pixels.

I have adjusted the frequency of the output clocks to correct for I wrongly calculating for 720 pixel active line length and  not as I should have 702. The new frequencies are 8.748 MHz for 4:3 giving a active line length of  80.25 uS and 8.1 MHz for 5:4 giving a active line length of  81.24 uS

I have changed the way 5:4 is produced. I was cropping the lines on the 625 side before the interpolater, this was unnecessarily complicating things. Now the 625 side remains the same for 4:3 and 5:4 mode with all 720 pixels been passed to the interpolater.
On the 405 output side when in 5:4 mode all 720 pixels are clocked out and the cropping of the lines is done by imposing blanking level in the appropriate places. This simplifies things and also has the advantage that if I ever decide to try and record on SD for example, playback can be either 4:3 or 5:4 from the same source file.

I also looked into the possibility of down sizing to a Cyclone II FPGA but found that the PLL's multipliers and deliverers had a very limited range compared to the Cyclone IV so could not achieve the output clock frequency's that I would like, so I will stick with the Cyclone IV.  While browsing ebay looking at Cyclone II boards I stumbled across a different Cyclone IV development board this one has the dedicated clock pins brought out to the headers so in that regard will be much better to work with than the one I have the down side is the on board program memory chip has a much lower capacity. I have ordered one anyways to see how it will work.

Frank

[ppppenguin]

601 is definitely convenient as it carries Y, C and sync in a single 8 or 10 bit data stream. A digital sync separator is a very simple bit of logic.

[`FRANK.C]

Hi Jeffrey
Arranging the 601 input was a lot more straightforward than I had expected. I created a separate file for it which turned out to be very small, in hindsight I should have just have put it in the file that contains the rest of the 625 stuff.

Frank

[ppppenguin]

You probably won't need to do this but if you're making a 601 output you need to exclude the codes 00 and FF from the output stream as they can be misinterpreted as TRS (sync) information at the receiver. The VHDL is very simple. Here's an example for 8 bit operation:

if INPUT_VIDEO = X"00" then OUTPUT_VIDEO <= X"01";
elsif INPUT_VIDEO = X"FF" then OUTPUT_VIDEO <= X"FE";
else OUTPUT_VIDEO <= INPUT_VIDEO;
endif;

For 10 bit you have to exclude 0-3 and 1020 to 1023 hence: if INPUT_VIDEO <= "0000000011" then OUTPUT_ VIDEO <= "0000000100"; etc. Which shows one of the annoyances of VHDL when dealing with signals that aren't multiples of 4 bits long. Of course you can use integer type to make the expressions clearer.

All of this will be efficiently synthesised by the VHDL tools.

[`FRANK.C]

Hi Jeffrey
I don't expect to be making a 601 output but if I try writing to a SD card it will come in useful as the same would apply.
A scheme similar to 601 with the sound fitted in the line blanking looks like a good way to go.

Frank

[ppppenguin]

In a 601 environment sound in line blanking is called embedded audio. I've designed embedders and de-embedders and they're not the simplest things I've ever done. Standard definition embedded audio was the earliest usage of ancillary packets in the blanking interval and the standard wasn't very well written. This led to compatibility issues. The HD embedding standard was much better.

https://en.wikipedia.org/wiki/Ancillary_data

I don't think SMPTE 272M is available freely but I can share my copy.

[`FRANK.C]

Hi Jeffrey
I had a look at that link and it certainly looks complicated.
As I wouldn't have to communicate with any other device I would be hoping to get away with a bespoke and much simpler system. Something along the lines of re-purposing  the bits in the fourth byte of the SAV and EAV codes. The SAV would identify the following bytes as video and would also contain the FID. The EAV would double up to indicate that the following bytes are audio and also contain the number of bytes of audio that will follow. After the last byte of audio the next SAV would occur and so on.

This is very much pie in the sky at the moment and I would have to do a bit of reading on SD cards as I know nothing about them right now.

Frank