DVR

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wish to build a DVR (digital vide2o recorder).
I wish to record at least one camera.
i will most liky use this camera, http://oemcameras.com/products/b...
but i would like it to be capable of http://oemcameras.com/products/b...

The DVR would make a new file and record to it when given power.
Possibly allow switching of sources in future via a PWM signal.
It will write to an SD card using fat filesytem.

I am use to working with the atmega168, is this processor powerful enough?
How do i go about saving video to a file like this?
Do i use an external CODEC encoder?

I think there are a few post about this on here but I am ill and didn't feel like digging a lot. Specialy looking at TI's DSP chips. I think they are over kill, plus i am not familiar with them

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I am use to working with the atmega168, is this processor powerful enough?
Of course!! One wonders why pc use gigahertz computers and 32 bit data.... :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Of course!! One wonders why pc use gigahertz computers and 32 bit data.... :?

mine uses 64 bits.
Good to know :D
So how do I save video, I guess i will use mpeg4 video and pcm audio... how do i go about doing this?
found this, http://www.jrobot.net/Projects/A...
Need more info on this I Supose

scratch the analog cameras, He we go
http://www.electronics123.com/s....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So how do I save video, I guess i will use mpeg4 video and pcm audio... how do i go about doing this?

So how much programming have you done with the M168??

Do you understand what you think you want to do?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DVR's are what I do for a living. I think the suggestion that you could do it on an 8bit micro is rather a wonderful one. Even the idea you can do it on just a 32bit (or a DSP) is quite interesting. It's true that I looked at using the dualcore ADi Blackin 591 that contains two 600MHz C55xx DSP cores and this was able to MPEG4 encode two lots of CIF (352x240) at 25 frames per second. But this is nowhere near D1 quality that you need even for SD-TV, let alone HD-TV.

The bottom line is that DVRs are based on specialised MPEG2 or MPEG4 dec/encoding silicon (and the same silicon probably contains transport stream demultiplexers too). Chips that do this are things like the STi5514, the NEC EMMA2 and a (for MPEG4) things like Conexan't and Broadcomms ranges (Angelina, Trinity, etc.)

Typically these silicon have about 200MHz+ of 32bit host core (ARM, MIPS, ST20) but then a whole bunch of autonomous processors operating their own DMAs and functions. Some of the Conexant's for example, have the equivalent of NINE ARMs on the one piece of silicon in amongst everything else.

What's more most of these chips are only MPEG2/4 *decoders*. They receive the transport stream of MPEG2 from a headend (via cable, satellite, IP) that has already been MPEG2/4 encoded and they just have to decode it at live vieweing or recording playback time. Doing the MPEG2/4 *encode* thing to record an external source like a camera is FAR more compute intensiive.

So do not underestimate the complexity of the processing power you require. If you truly want to DVR record video from an external source you will need MPEG encode/decode in silicon or a MASSIVELY powerful CPU to do it in realtime in software (anything from about a 1GHz Intel upwards can actually do D1 MPEG4 encode in software alone)

One thing's for sure: you aren't going to achieve this with an AVR (though we do use them for the front panels to do the buttons/switches and IR to take some more of the load off the main CPU)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was afraid of this D:
Basicly, I want to do video recording like what you find in a camera today. Pop in a sd card and start recording is the plan.
I mean TI has this solution
http://focus.ti.com/docs/solutio...
IE:
http://focus.ti.com/docs/prod/fo...

real time encoding: http://focus.ti.com/docs/toolsw/...

But this is WAY more then I have ever done

cliff can i e-mail you about this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup and those TI chips are bascially 600MHz DSPs at the core with 8 40-bit ALUs, about 2MB of L1/L2 cache and come in a 548 pin Ball Grid Array.

I'll bet you are loking at about $20 of silicon there (in quantities of 100,000 to 1,000,000).

We typically take about 20-40 man years of engineering to get something like this working with something like 5 million lines of C source code

This kind of thing is NOT for the feint-hearted and is not the sort of thing a home hobbiest could ever achieve.

Cliff

PS But if you do you have a job waiting here

PPS my email is clawson@amstrad.com - our company is now a division of Rupert Murdoch's News Coproration (20th Century Fox, Wall Street Journal, Facebook, DirectTV etc.) and BSkyB (of which we're a part) is the leading supplier of domestic satellite TV systems in Europe.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks... I will stick to digital logic for now...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff!!! I was having fun with this... :lol: You wet blanket.....

Anyway, because the op did not know it could not be done, he might have come up with an algorithym to store several movies inside the EEPROM of a M168...now all of that is gone thanks to you.

He would have had all the encouragement from me. :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This actually looks very interesting and in my opinion achievable.
The camera Shutter has chosen has two outputs: one B&W analog and two 8-bit digital. The last one according to the specs can be configured to output in three different formats 4:2:2 YUV, 4:2:2 RGB or raw RGB (if I read the specs correctly). Also the maximum ‘video resolution’ is limited to 352x288 pixels with adjustable frame rate up to 60fps. The camera’s output is ‘progressive’, so that will limit how one can play the recording. The video on the digital port is already digital so Shutter doesn’t have to worry about digitizing the video, a most important hurdle overcome. All the AVR has to do is to be a traffic-cop between the camera and the storage.
So lets see, if used in 4:2:2 YUV mode at max resolution (352x288) each frame will be
352 * 288 * 2 = 202,752 bytes of uncompressed data per video frame. Taking into consideration the storage max throughput (according to specs an SD card will handle 22Mb/s of data) about 3MB/s translates to around 14 frames per second. If my quick calculations are correct, without any compression on a 16GB SD card (just looked it up if one exists, it does) Shutter can record: 84,733 frames, or 6,052 seconds, or 100 minutes of video data (at 14fps) without any compression (assuming you are writing just one long stream, forget FAT, the compression, etc).
An AVR that would initialize everything at the start and then just passed the data from one port to the other (camera >> AVR >> storage) in my opinion actually has a fighting chance to do it (not much more though…). If anyone has the experience and can confirm that an AVR running at X MHz can read PORTA and PORTB and then write that data consecutively to PORTC (about 3MB of data per second), we will then know if it is possible.
For the playback Shutter would probably need a PC program to read the raw data from the SD card and display it (progressive) on the monitor or for that matter converts into a usable AVI encoded with codec of his choice. This would probably be the easiest part of the whole project.

Rob

JS, I think you are on again! :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How fast do you think the AVR needs to be clocked to sustain a 3MB/s data rate to an SD/MMC ? (don't forget it's not just dumping raw 512 byte buffers, you have to keep stopping for cluster allocation). Or were you suggesting the file is pre-created and so FAT allocation is not needed?

But I'd love to see hobbiest solder a 576 pin BGA ! :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...sustain a 3MB/s data rate to an SD/MMC ?...

I must be off by a factor. Never actually did it, but as I recall the write time for each 512 byte block was like 2ms. so you couldn't stuff down the throat of the SD/MMC much faster. Or am I missing something?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, I don't think so. For reasons of stability we've looked at the possibility of using flash for stream storage in DVRs but the write bandwidth cannot sustain the data rates (and that's SD, not HD). Having said that things like Samsungs 64GB SSDs offer blistering data rates (up with PATA/SATA rates). But this isn't SD/MMC!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff wrote:
How fast do you think the AVR needs to be clocked to sustain a 3MB/s data rate to an SD/MMC ? (don't forget it's not just dumping raw 512 byte buffers, you have to keep stopping for cluster allocation). Or were you suggesting the file is pre-created and so FAT allocation is not needed?
Okay, I did this with a Sigma Designs part and a Wipro MPEG encoder... Hmmm... 200 MHz, maybe more? Lessee -- If we cool the AVR down with liquid nitrogen, we may get a factor of 5X on the clock. Maybe up the voltage? I don't see where that other factor of 2 is coming from... :twisted:
Cliff wrote:
But I'd love to see hobbyist solder a 576 pin BGA ! :lol:
That's what toaster ovens are for! ;-)

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson:

Yes, I fully agree with you that full SD-D1 resolution is too much for SD card. But, the camera he is talking about is only one quarter the SD-D1 frame size, and I have adjusted the FPS down to 14 to accommodate the bandwidth shortcoming. BTW, according to this spec [http://www.sdcard.org/about/spee..., the Class 6 SD card guarantees sustain speed of 6MB/s. Reading the specs of the SD card, I now see that this card is not the best choice for this job. The SD-card interface at max is 4-bit wide, complicating the data transfer even more. But nothing is written in stone yet, so lets say we can change it to CF card for example. According to SanDisk, max size is 16GB, to/from host data rate is guaranteed at 16MB/s and the bus is full 8 bits. To quote the SanDisk spec:

 …The 512-byte sector size of the CompactFlash Memory Card is the same as that in an IDE magnetic disk drive. To write or read a sector (or multiple sectors), the host computer software simply issues a Read or Write command to the card. This command contains the address and the number of sectors to write/read. The host software then waits for the command to complete. … 

Therefore, at the beginning of each frame, the AVR would just issue a write command, specifying the (updated) start address, 396 sectors to write and then just pump the data right through without any formatting. Later on when reading the data back, one knows that each frame starts every 396 sectors, no need for any kind of synchronization. Also you ask if FAT is needed, I say no. The application at this moment calls for storage, not sharing (in my opinion unnecessary overhead). PC software can be easily written to read raw sectors of the CF card and since the data is a raw YUV format (unusable to most) the software could at that time convert it to an AVI encoding it with a codec of choice.

You also ask of my opinion: …How fast do you think the AVR needs to be clocked to sustain a 3MB/s data rate… By writing few simple lines of code to see the cycle count for each operation, I estimate that a 30MHz should be enough. Yah, I know I just shot my self in a foot ;) No 8-bit AVR will run at 30MHz.

How about these new XMEGA CPUs with DMA? I don’t have any experience with that.

Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know I am bringing back a dead horse, but I have gotten a lot better at AVR stuff. Anyways, now my mentor wants me to learn to use FPGAs. He wants me to write a encoder [jpeg probably] on a FPGA. He has done it before. :<

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now you will have all the horsepower you need. The XESS board is what I am using, and I like it a lot for video work. I also found Verilog to be much easier to work with than VHDL.

Verilog is actually easier than basic, but getting past the sequential mode of thinking when used to working with microcontrollers took a while.

Now I just pretend I have a 200MHz AVR that can execute every single line of code once every clock cycle! Oh, and don't forget ns propagation delays... those are a real bugger.

Good luck.
Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could always spread the data across many SD cards in parallel to get the bandwidth, but you will not be able to read it in a PC.