OSD capability

[dongle]

Hi,

Will the OSD have any hardware features that will be of interest to people wanting to use it beyond the living room ?. For example could the serial port be used as a wired remote control ?.  I note that the maximum resolution is 720x480, is this the same for the PAL version ?.

Cheers

Pat

[dragonwisard(at)gmail.com]

I belive there will only be one version that supports both NTSC and PAL. Therefore, the answer would be yes.

[JoeBorn]

The OSD has plenty of features that would be of interest, I believe.  Serial can be used for a remote (or a variety of other things as well) as can USB Host.  Check out http://wiki.neurostechnology.com/index.php/OSD_Ideas for some general ideas.  It's an open platform in many ways, Linux, open application software, available schematics and hardware support, and obviously support from the manufacturer.

[dongle]

Joe,

Thanks for the reply. It will be interesting to see what features become available. 

Open source is great but what happens when someone would like a new feature but cannot program the OSD. Will there be a "wish list" that people can subscribe to in the hope that someone will write the code ?.

Also it would appear that the OSD will consume less power than the R2. Can you publish the power consumption for the following:

OSD connected to supply but not "On" (quiescent current)
OSD On
OSD Recording
OSD Playback

I am assuming the system will work in roughly the same manner as the R2. I also realise that these figures may vary according to the way it will be programmed but the first release can probably be regarded as a baseline in terms of power consumption.

Cheers

[JoeBorn]

What makes you think power consumption will be less with the OSD?  I'd assume it will be more.  It has a faster processor, more memory, etc.  Sean, can you chime in on power consumption.

Of course, we'll always be interested in hearing about features you want and trying to respond to our customers internally.  We don't view the community as a substitute for our own development work.

EDIT:

I should add that as far as a wish list, we actually have team members assigned to monitoring all the communications and making sure they make it into bugzilla (our central repository for bugs and enhancement requests).  At the same time, you are always free to enter and vote on bugs directly there:  bugzilla.neurostechnology.com this is the database that our internal and community developers share to prioritize work.

[dongle]

My mistake regarding lower power than the R2, can we have some numbers for the OSD please ?

Cheers

[sean weng]

Here are the OSD Power consume data:
No power but battery: 3.3 uW
Power on but no video: about 1.3 W
Power on and have video: about 1.75 W
Recording: about 1.65 W
Playing: about 1.4 W

[dongle]

Thanks for the info.

So the OSD  consumes around 30% less power than the R2 when recording, could be a good selling point !.

[mykulmac]

The R2 has a problem with continuously recording over two hours.  Does anyone know if the OSD has the same pitfall?

[JoeBorn]

The OSD doesn't have the two hour problem.  It might have an 8 hour problem, but it should be at least 8-12 hours of continues recording before it has an inherent isssue, and remember, we're limited by FAT32 on 2GB files, so over 2GB will have to be split anyway

[dongle]

Can you explain this  a bit better ?.

"It might have an 8 hour problem, but it should be at least 8-12 hours of continues recording before it has an inherent isssue"

Also, 8GB cards will be common and affordable in the next year or so. The ability to record 8+ hours of highest quality video on the OSD will appeal to many people but this will entail splitting the storage into 2GB chunks. If this process is automatic on the OSD (is it ?) then why can't it be done on the R2 ?.

The composite video signal into the R2 has horizontal sync pulses 63 microseconds apart, there are 525 of these in a single video frame and 50 frames every second. Opening and closing files during data capture is a common proceedure in many applications. The biggest advantage is data security. Should the data stream be interrupted then only data recorded since the last file close/file open routine will be lost.

I appreciate that this is not always necessary or even desireable for a video application but the concept could easily be applied to the R2 by closing/opening say every 30 minutes. I am not sure what the processor capabilities are but I would guess that the whole operation could be done in the time for say 2 or 3 sync pulses to occur. Even waiting for the next vertical sync pulse to arrive would not be a major problem.

This process would be invisible to the user, increase security and simplify video processing by having smaller file sizes. The current delay between start/stop recording is way too long to be a practical way of splitting the video.




 

[anti_tank_soldier]

Hi! I m just a newbie to OSD.

Regarding the encoding part of the OSD, how many videos OSD can real time encode concurrently using MPEG 4 simple profile?

[tminus]

Hi! I m just a newbie to OSD.

Regarding the encoding part of the OSD, how many videos OSD can real time encode concurrently using MPEG 4 simple profile?

Good question! I have been wondering the same thing actually. Tivo 2 records two, but you have to be watching one of them, so it would be a bummer if it didn't at least match that. Not a deal breaker for me, but definately a plus.