Simple memory card player idea

[Karen O]

I was a bit tongue in cheek when I suggested the 405-625 idea Jeffrey so don't take what I said as market pressure I guess it's something that might be useful for converting 405 line archive material though.

One thing I like about my approach, despite it being a dumb byte mover, is that any algorithmic refinements can be handled off-line. So even if the first results are not good there is always room for improvement.

I've a feeling I'll end up with something that is materially cheaper than the Aurora, but in reality will be much more expensive - unless that is you value your own time at considerably less than minimum wage. I think the off-line preparation is going to take hours

I've yet to see the effects of bad blocks. They may result in an occasional blackened frame and brief silence on the audio. I do hope that doesn't present a problem.

[tubesrule]

Originally Posted by Kat Manton

I've found it's better not to de-interlace. The choice seems to come down to 'combing' on motion or a soft picture. Subjectively I prefer the remarkably crisp picture I get on 405 with de-interlacing turned off. (I remember several people commented on the excellent picture quality at the NVCF demo once I'd hit the Pye monitor hard enough to get it to work. I had de-interlacing turned off then, too.)

So normally if the source material is interlaced (e.g., DVB-T), the display device is interlaced (e.g., a 'proper' 405/625/819 CRT telly) and the frame rates match, I don't bother de-interlacing. IMO it isn't necessary and the picture quality is better (noticeable on a monitor, probably less so on a TV set.)

Kat

I have only used ffmpeg in a cursory manor when compressing things for my iPod, so I would be interested in understanding more of it's capabilities. It seems straightforward when enabling de-interlacing, but how does it handle an interlaced source when de-interlacing is not enabled? Does it take the full interlaced frame and scale it to the output size, or does it do as Jeff mentioned and scale each field individually?

Darryl

[Kat Manton]

Hi Darryl,

The post you quoted concerned MythTV rather than FFmpeg; the documentation for MythTV's de-interlacing settings is here. It doesn't state what it does when set to 'none' but I'm fairly certain it scales each field individually - CPU load is low and I don't see combing etc. when I've watched interlaced sources on an interlaced CRT set or monitor.

FFmpeg... I've only really used that for transcoding without scaling. Though I'm now starting to look into using it for scaling as well. What I hope it's doing is scaling fields individually; I'm transcoding/scaling interlaced source material and forcing the output format to be interlaced. I currently lack functioning or accessible sets/monitors; I haven't watched any of the transcoded/scaled material on anything other than a computer monitor, so I'm not sure if it's de-interlacing/scaling/re-interlacing when that's not what I want it to do.

I think the only way to determine with some certainty what it's doing is to examine the source code. I might take a look but I'm not too sure if I'd understand the code. I may at least be able to point you at the relevant file(s). I'd like to know what it's doing, or at least know it's doing what I think I've told it to do.

At the moment, it happens to be a fairly easy way to get data into a format suitable for Karen's CF card reader. If it is scaling frames rather than fields, we may have to look at alternatives if it can't be tweaked via options.

I need to re-organise "Mission Control" and build another PC with the right bits in it. Then I can dig out a monitor and look at the output of FFmpeg as it's being used here, figure out if it's doing something we don't want it to do, then see if any settings can be tweaked or try something else if needed.

Kat

[tubesrule]

Thanks Kat. I've often wondered what ffmpeg did when using it for conversion. I think your assumption that it scales fields individually when not set to de-interlace must be correct. I've used it to scale content I've grabbed from the web to play through some of my old sets, but wasn't sure exactly what it did. If you do find the time to dig into it more, I would certainly like to hear your findings about how the settings affect the output.

Cheers,
Darryl

[Kat Manton]

While not directly relevant, this is fascinating so I'm posting the link anyway. IMO some of it's relevant; regardless, it's interesting to read how recording and storage of television pictures was handled in the past.

[Karen O]

The ideal recording medium would be a long solid such that a section at right angles to the length would yield a single image. No quantisation - continuous in all axes including time! Perhaps it can be done in glass using lasers?

I like the continuous moving film idea but why overlay the odd and even frames to make a single hi def image? It uses no more film to keep the frames separate (appearing half height on the film) and it would allow the chronological distinction to be preserved.

Recording is possible (and I believe has been successfully done) by projecting a single line from a CRT onto a continuously moving film.

[neon indicator]

Originally Posted by Karen O

T
I like the continuous moving film idea but why overlay the odd and even frames to make a single hi def image? It uses no more film to keep the frames separate (appearing half height on the film) and it would allow the chronological distinction to be preserved.

To create normal film frames for normal projectors. The "separated" sequential fields would have required new projectors especially for TV sourced film.


There is also a Film Scanner that uses continuously moving film (shot normally or telefilm), a photodetector and uses a CRT for illumination. presumably the the blank raster is odd and even fields above each other.

There are also rather cunning revolving polygon mirror projectors and camera that use continuous movement film. Jerking the film every frame makes a lot of vibration and wears out the film sprockets.

You also want "continuous" movement for ether optical or magnetic track sound. Though when I was in BBC in late 1970s they mostly used sepmag film (a separate synchronised magnetic tape). As well as the obvious idea of optical track on edge of film for sound, there is film stock with a magnetic stripe. One wonders why it took so long to add sound to cinema.

[Karen O]

Here's my near-finished hardware.

My next task is to get it generating a complete 405 line picture. I don't have a monitor yet but I can at least check the sync timings.

I'm also going to get it generating audio - a 25Hz sine wave to go along with the picture. If I can get those happening then the rest should be easy.

[neon indicator]

25Hz is too low. Even 250Hz a bit low.

Between 400Hz to 800Hz would be better.


Those Hammond cases do look smart.

[Karen O]

It's only 25Hz because that is the rate of complete picture refresh (odd and even fields). This is a test to check out audio replay and not a representative audio tone. I will probe at the output of the DAC with DC coupling and look for discontinuities, etc. I want a slowly changing waveform to exercise the DAC resolution a little.

[neon indicator]

Use the line rate (10.125KHZ) to o/p a rough sinewave based on 32 values. That's 316Hz. Lots of small speakers don't work very well at 25Hz.

DACs are simple. In my experience I've never had a problem outputting audio on a DAC.

In reality you want to o/p audio at 40.5KHz, 50.625 or even 324KHz rate and then analogue 10KHz low pass filter. The Audio can be stored at 22.05KHz or 24KHz sample rate.

[Karen O]

The 25Hz is never going to drive a speaker!

It's not the DAC I'm worried about, it's my codes extraction of audio samples from the sectors and it's delivery to the DAC in the right order I want to test. Trust me.

For better or for worse I've settled on an audio sample rate of 30.375kHz.

[neon indicator]

Makes the work of analogue filtering harder. But you can play the samples at x4 to make filtering easier

[ppppenguin]

Originally Posted by neon indicator

Makes the work of analogue filtering harder. But you can play the samples at x4 to make filtering easier

My understanding is that the digital audio output will be driving a commonplace oversampling audio DAC. Analogue filtering is not a problem, 1 R and 1 C.

[Karen O]

Oh I don't worry about reconstruction filtering. I can't hear the residual sample frequency plus harmonics anyway, and if it annoys next door's dog I'll consider that a plus.

Over-sampling, i.e. beginning the filtering process in digital to ease the analogue aspect is not on for a processor that doesn't have a multiply instruction.

[neon indicator]

18F is same prices and DOES have a multiply instruction. Also 12MIPs without overclocking.

[Karen O]

Perish the thought that this might be a properly conducted engineering exercise! If it were it'd have an ARM processor and a couple of megs of SDRAM by now.

No, no, no - much better to use under-powered hardware, personal whim and what happens to be in my junkbox.

A 'C' programmers moral: Two longs don't make a byte.

[Karen O]

Second stage accomplished! I now have an interlaced 405 line picture on the TV kindly donated by Jay.

It's also producing a frame's worth of audio - actually a 25Hz sine wave. The idea is that these 40msec segments will stitch together during continuous playback.

Oh yes, I've relented: the audio playback is 12 bits at 40.5kHz sample rate

[ppppenguin]

This is looking good. I assume the little box with a Scart is a modulator since that's a standard TV9-90 without AV input.

[Karen O]

Yes, Jeffrey - a Maplin UHF modulator. You probably know that, with both buttons pushed in on the TV9-90, this nice little TV accepts a UHF signal but uses a 405-line line frequency.

I forgot to mention - the audio is being streamed off the card too. It's interleaved with the video.

Just need to add 376 to the logical block address each frame and it should play back a movie. I need to get into the Linux script Kat supplied but that can wait until I come back from holiday