July 24, 2014, 08:03:35 am
News:
Pages: [1] 2 3 4
Print
Author Topic: OSD 3  (Read 25739 times)
JoeBorn
Neuros Audio Team
Administrator
Hero Member
*****
Posts: 1376



View Profile WWW
« on: July 15, 2009, 02:21:36 pm »

Even though the OSD2 is not even out of the developer kit stage, and the OSD is still going, it's time to start thinking about the OSD3, and here's why:

1. This our chance to get our configuration included in the "motherboard" that TI is designing
2. By getting started early, we can catch the initial launch of the silicon (which is a lesson we learned from missing it with the OSD2)
3. We can be included in the inital discussions about OS porting, etc. (another lesson we learned from missing it with the OSD2 and the issues over Montavista, etc)
4. By launching early we can create a Neuros community that is the defacto open source device and community for this new architecture (ie, the goal is for Neuros to be the official "beagleboard" type site and community for this architecture.
5. TI is driving activity on this NOW, they will be active in these discussions (including this very thread) and we have an opportunity to get integrated in the discussion today that won't be available to us, once we get further down the road.  At this point in the design cycle, there's more attention and resources applied than once the design gets more solidified and mature, so now is the time.

All this naturally begits the question "what is this new architecture?" and we're in the process of rolling out information as we have it.  Here's what we know today:

1. We're probably a good 18 months away from a consumer product (minimum/optimistic I'd say)
2. It will be full 1080p/60 capable on both encoding and decoding (h.264, etc) with *official* support for that performance from TI
3. It will combine a solid ARM core as well.  As you'd expect it will only be a step up from Cortex A8 OMAP 35x
4. Its targeted at the high end, the initial spec we're talking about 2GB of DDR3 memory so this is a full HD solution, not a $99 Roku device.
5. A full solid web browser is a pre-requisite.  This means HTML5, Full Adobe flash support, including Hulu HD and the like.

In a nutshell, the OSD3 is intented to be a quiet, embedded device with full Web support as well as full fledged, embedded recprding and playback of HD content.  Now its your turn, what are your requirements for such a device?  How would you spec it?  What are the must haves?  the nice-to-haves, both on the software side as well as hardware.


 
Logged

jborn (at) neurostechnology.com
#neuros on freenode.net
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #1 on: July 16, 2009, 06:50:19 am »

This is exciting, I can't resist chiming in!

Solid playback and record are an absolute must. These are core features that simply must work perfectly.
We need well optimised codecs at the alpha release stage of the board, the community can help ironing out the bugs.

Waiting for official support for a device in the kernel is a long wait. Even now, I don't think the OSD2's DM6446 is fully supported in 2.6.31. I'm not how to get around this, this is a reason why many go for Montavista's kernel I guess. But if the docs are open, drivers will be written.

Connectivity that are essential: 802.11n <- the fasted wireless possible. Ethernet, gigabit better. USB2 needed, USB3 would really future-proof the device. eSATA? SD cards. High def videos are large files, we need fast ports to move them around.

I still rather having noisy hard drive storage being supplied from a NAS in another room, but I won't deny other people the ability to have a hard disk plugged directly into their board. Make it SATA! PATA is old now.


Bluetooth would be great for next-generation remote-controls. This is something I feel needs a lot of thought. For standard navigation of menus, only about 8 buttons are really needed, up, down, left, right, back, ok, Xim and home. Then playback controls add another 6. That is a decent remote. But web navigation needs something else. I find the Link's trackball is a step in the right direction, but still not brilliant. Something like
http://www.amazon.co.uk/Keysonic-540BT-bluetooth-keyboard-touchpad/dp/B0017BQL2W
would be better (except that it does not need full-sized keys and could be far more compact. Cross this with this maybe).

The reason I go for a trackpad is because of the acceleration parameter is has. When you move your finger slowly, the cursor moves only a small amount. But if you move your finger quickly the cursor covers a far greater distance. While the trackball probably has this too, I didn't think it worked so well, because you had so little physical space to move your finger.


Modern devices today needs a pretty UI. And IMO, pretty means animated. I don't think (but would love to be shown otherwise) that an ARM chip with an unaccelerated frame-buffer is up to that job. However the new OMAP3 chips do have an SGX hardware graphics accelerator supporting OpenGL ES, on which I've seen XBMC running (not very well, but it's early days yet).

Such hardware acceleration will make web browsing more pleasant, including smooth pans and zooms. Also it will make the UI more responsive. It opens up the avenue for gaming too.

The Beagleboard has really opened up the possibilities that an embedded board can achieve, and it has a large hacker base. However in my eyes it is still very much a hacker device, and a more flexible board, with more inputs/outputs could tempt many of those guys over. And by taking advantage of the large software stack that now exists (OpenEmbedded, Gstreamer to name the big two), the learning curve for new hackers is much lower.
-G
Logged
chase.maupin
Global Moderator
Newbie
*****
Posts: 15


View Profile
« Reply #2 on: July 16, 2009, 08:31:50 am »

Greyback,

Let me put a couple of answers here from the TI side of things.

This is exciting, I can't resist chiming in!

Solid playback and record are an absolute must. These are core features that simply must work perfectly.
We need well optimised codecs at the alpha release stage of the board, the community can help ironing out the bugs.

We are also working to release our simulator for this processor to the community so that you can begin checking out our software and the device before silicon even arrives.  I will keep you up to date on this effort as I know more going forward.  We would love any feedback you have on how useful this might be and on the software we release.

Waiting for official support for a device in the kernel is a long wait. Even now, I don't think the OSD2's DM6446 is fully supported in 2.6.31. I'm not how to get around this, this is a reason why many go for Montavista's kernel I guess. But if the docs are open, drivers will be written.

TI has changed strategy about Linux from targeting MontaVista to targeting the opensource kernel first.  We have established git trees for OMAP and DaVinci processors which is where we are staging our processor support for pushing to the kernel mainline.  As you mentioned devices like DM6446 are not yet fully there since they are being moved up over time, but you will see that for new devices we are pushing to the git kernel first.  This should help us to keep more up to date.  Likewise, I am working to make sure that we open enough documentation to allow others to write drivers if they wish but we also have a driver team that will be putting drivers in the git kernel.

Connectivity that are essential: 802.11n <- the fasted wireless possible. Ethernet, gigabit better. USB2 needed, USB3 would really future-proof the device. eSATA? SD cards. High def videos are large files, we need fast ports to move them around.

USB3 is not planned, but we will have SATA/eSATA support, Gbit Ethernet, SD/MMC and PCIe.

I still rather having noisy hard drive storage being supplied from a NAS in another room, but I won't deny other people the ability to have a hard disk plugged directly into their board. Make it SATA! PATA is old now.

Agreed.  SATA is what we have planned.

Modern devices today needs a pretty UI. And IMO, pretty means animated. I don't think (but would love to be shown otherwise) that an ARM chip with an unaccelerated frame-buffer is up to that job. However the new OMAP3 chips do have an SGX hardware graphics accelerator supporting OpenGL ES, on which I've seen XBMC running (not very well, but it's early days yet).

Such hardware acceleration will make web browsing more pleasant, including smooth pans and zooms. Also it will make the UI more responsive. It opens up the avenue for gaming too.

The Beagleboard has really opened up the possibilities that an embedded board can achieve, and it has a large hacker base. However in my eyes it is still very much a hacker device, and a more flexible board, with more inputs/outputs could tempt many of those guys over. And by taking advantage of the large software stack that now exists (OpenEmbedded, Gstreamer to name the big two), the learning curve for new hackers is much lower.

Like the beagleboard and OMAP3 this device will have a hardware graphics accelerator. 

Thanks,
Chase Maupin
Logged
vu3rdd
Newbie
*
Posts: 1


View Profile
« Reply #3 on: July 16, 2009, 08:36:29 am »

First of all I have afew questions.

1. Is the hardware being designed by TI for Neuros? Will it be open as well? Open as in Free Schematics, PCB layout etc?
2. Will the specs of accelerators be open? DM644x IMX specs are not open. I don't know what else is not open.
3. Will there be a DSP at all inside the chip?
4. How much of the DSP engine is Open ? (whether it is s/w based running on the DSP or h/w accelerator based)

I would like to have the following features for the OSD3.

1. 1080p/30  capture and playback. 1080p/60 desirable.
2. Provision to scale down/up to various resolutions.
3. Ogg Theora support (a precondition to support Theora is a programmable DSP engine if community is going to add support for this and hence my above questions). It is very important that an Open STB has support for an open video format.
4. Ogg Vorbis support.
5. Analog capture support at all resolutions (component input and output).
6. H.264 Main Profile support
7. All kinds of exposed Knobs to the codec (ability to change bitrate, framerate, switch on/off various codec tools etc).
8. Non complicated way to use the codecs from application.
9. Complete access to "buildable" source code. Otherwise it will be a misnomer to call it Open. (eg: codec engine provided by TI to the external world is *not* buildable).
10. Ability to use the OSD3 device as a USB peripheral with full USB speed. Current DM35x/DM644x musb has got issues in ISOC mode to stream beyond ~60Mbps.

disclaimer: I am speaking for myself and not for my employer.
« Last Edit: July 16, 2009, 08:39:32 am by vu3rdd » Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #4 on: July 16, 2009, 09:49:01 am »

Chase,
thanks for your reply, this is fascinating stuff.

Quote
We are also working to release our simulator for this processor to the community so that you can begin checking out our software and the device before silicon even arrives.
This is the first I've heard of a simulator. While the ARM side can be tested quite easily in Qemu say, does this simulator emulate the DSP side stuff? If so, that is very interesting. It would allow open source codecs to be developed, without the handicap of expensive debugging hardware, should the full capabilities of the chip be known (i.e. as vu3rdd asks, if the accelerators specs are open).

I will keep a close eye out for more details on this development, please keep us in the loop!

Quote
I has changed strategy about Linux from targeting MontaVista to targeting the opensource kernel first.  We have established git trees for OMAP and DaVinci processors which is where we are staging our processor support for pushing to the kernel mainline.
Your point that the OMAP and Davinci git trees are more up to date is a good one, I shall revoke my concern. I see new hardware being supported very quickly there, which will eventually trickle into linus' tree. For those that are curious, the following link shows a hopefully-recent status report of the davinci tree:
http://wiki.davincidsp.com/index.php/DaVinci_GIT_Linux_Kernel
Video support is still lacking, but I am confident it will get there in time for an OSD3 Smiley

Quote
USB3 is not planned, but we will have SATA/eSATA support, Gbit Ethernet, SD/MMC and PCIe.
I assume you are including USB2 though. PCIe is interesting, that will offer the use of expansion boards.

Quote
Like the beagleboard and OMAP3 this device will have a hardware graphics accelerator.
I am very happy to hear that.

I also share vu3rdd's requests for Ogg support, however I accept that some DSP-side code will not be opened. Codecs are hard things to write, so I accept that TI would hold onto those. But I think it is fair to have a way for the community to write their own codecs which can interoperate with TI's closed ones.
-G
Logged
av500
Newbie
*
Posts: 2


View Profile
« Reply #5 on: July 16, 2009, 09:55:31 am »

3. Ogg Theora support (a precondition to support Theora is a programmable DSP engine if community is going to add support for this and hence my above questions). It is very important that an Open STB has support for an open video format.
4. Ogg Vorbis support.

theora and vorbis can be played back on the OMAP3 already, using only the ARM, this one being presumably faster, so no issue there, at least for SD resolution.
For HD, you wouldn't want to use theora, now would you  Wink

6. H.264 Main Profile support

not enough, a lot of "internet backups" are high profile, so why limit to MP?

9. Complete access to "buildable" source code. Otherwise it will be a misnomer to call it Open. (eg: codec engine provided by TI to the external world is *not* buildable).

codec engine is BSD now, no issue.
Logged
chase.maupin
Global Moderator
Newbie
*****
Posts: 15


View Profile
« Reply #6 on: July 16, 2009, 09:59:22 am »

First of all I have afew questions.

1. Is the hardware being designed by TI for Neuros? Will it be open as well? Open as in Free Schematics, PCB layout etc?
2. Will the specs of accelerators be open? DM644x IMX specs are not open. I don't know what else is not open.
3. Will there be a DSP at all inside the chip?
4. How much of the DSP engine is Open ? (whether it is s/w based running on the DSP or h/w accelerator based)

1.  The base hardware is being designed by TI and will be open.  If Neuros adds features beyond the base hardware then they may be done as a seperate daughter board.  In this case it depends on who designs the hardware.  So the general rule would be that if TI designs it we plan to open it (as in Free Schematics).
2.  We at TI are working to open the specs.  There are accelerators on this platform that are used by codecs.  How to best open these is still in discussion but I will be pushing to get them open.  Having feedback from people like you that you want this information open (and any ideas on what you want to do with that information) is useful in pushing for the specs to be released.
3.  There will be a DSP on the chip.  It will be a C67x DSP which is a floating and fixed point DSP (similar to the OMAP-L137 DSP).
4.  This depends.  For audio codecs I believe they will be mostly software based on the DSP to take advantage of the floating point capabilities.  Video uses the DSP and accelerators.  As we have more software information I will be sharing it so keep an eye out.  In general though the DSP can be programmed to do whatever you want, the accelerators are there to help with doing it real-time Smiley

I would like to have the following features for the OSD3.

1. 1080p/30  capture and playback. 1080p/60 desirable.
2. Provision to scale down/up to various resolutions.
3. Ogg Theora support (a precondition to support Theora is a programmable DSP engine if community is going to add support for this and hence my above questions). It is very important that an Open STB has support for an open video format.
4. Ogg Vorbis support.
5. Analog capture support at all resolutions (component input and output).
6. H.264 Main Profile support
7. All kinds of exposed Knobs to the codec (ability to change bitrate, framerate, switch on/off various codec tools etc).
8. Non complicated way to use the codecs from application.
9. Complete access to "buildable" source code. Otherwise it will be a misnomer to call it Open. (eg: codec engine provided by TI to the external world is *not* buildable).
10. Ability to use the OSD3 device as a USB peripheral with full USB speed. Current DM35x/DM644x musb has got issues in ISOC mode to stream beyond ~60Mbps.

To answer a couple of these:
1080p60 support will be there
scaling/resizing will be available
Planning component input as well as HDMI output (maybe component output)
Source code should be buildable.

As for the rest I'll take that feedback to our software teams.  As we get more components together we will work on releasing them to the community so you can see what we are doing and provide feedback.
Logged
chase.maupin
Global Moderator
Newbie
*****
Posts: 15


View Profile
« Reply #7 on: July 16, 2009, 10:06:09 am »

Greyback,

The simulator will include support for the ARM, DSP, accelerators, etc.  It is a full system simulator.  Currently it runs using CCSv4 from TI not QEMU.  What is the interest in QEMU going forward as we are trying to guage that effort?  The CCSv4 version today runs on Windows (please don't shoot the messenger) but should be running on Linux by the end of this year Smiley

USB 2.0 will be supported so no worries there.

The community should be able to write their own codecs to run on the DSP.  To incorporate with TI's codecs they would need to be xDM complaint (so that they don't stomp on each other).  We already have people in the community interested in ffmpeg on the DSP so perhaps by the time silicon is out you would see libavcodec running on the DSP.
Logged
av500
Newbie
*
Posts: 2


View Profile
« Reply #8 on: July 16, 2009, 11:44:01 am »

The simulator will include support for the ARM, DSP, accelerators, etc.  It is a full system simulator.  Currently it runs using CCSv4 from TI not QEMU.  What is the interest in QEMU going forward as we are trying to guage that effort?  The CCSv4 version today runs on Windows (please don't shoot the messenger) but should be running on Linux by the end of this year Smiley

making QEMU fully support the ARM (e.g. it does not support CortexA8 atm) would help people a lot that write algorithms and dont want to run a full system just to check/benchmark some optimized code. Also it goes with the open source spirit, though I am not sure how that clashes with ARM releasing CPU specs only under the rule that you may not use them to write an emulator. Is the CCS part that emulates the ARM open source? If yes, QEMU will pick that up fast anyway....

Logged
chase.maupin
Global Moderator
Newbie
*****
Posts: 15


View Profile
« Reply #9 on: July 16, 2009, 12:54:25 pm »

making QEMU fully support the ARM (e.g. it does not support CortexA8 atm) would help people a lot that write algorithms and dont want to run a full system just to check/benchmark some optimized code. Also it goes with the open source spirit, though I am not sure how that clashes with ARM releasing CPU specs only under the rule that you may not use them to write an emulator. Is the CCS part that emulates the ARM open source? If yes, QEMU will pick that up fast anyway....

I do not believe the CCS part for ARM emulation is open source.  There is still a lot to work out here but I am pushing towards putting this functionality in QEMU going forward for long term viability.  However, resource limits may dictate this stays in CCS for now.  Luckily, with this emulator you can select which parts of the system you want to model.  For example, a codec developer may only care about the DSP and accelerators and nothing about the display subsystem or ARM.  Or an open source developer may only want to model the ARM and not the DSP, etc.  So there is flexibility to reduce the complexity of what is getting modeled.
Logged
ChadV
Administrator
Hero Member
*****
Posts: 1611


View Profile WWW
« Reply #10 on: July 16, 2009, 04:26:36 pm »

What I would like to see is an honest video "HUB".

Multiple inputs for me would be a must.  Say a model with HDMI, Component, S-Video, each switchable, and one multi-input switch, and a second model with 3-5 HDMI, 3-5 Component, 3 S-Video/Composite, and the ability to upscale each to a single HDMI/Component output with your choice of analog (1/8" w/RCA adapter) or TOSLINK (or copper S/PDIF) audio out.

The main reason for this is that I have a 8-port video switch from Pelican.  When I use my PS2, I press the "PS2" button on the front, and change the TV to "Component" input...  Then to use my Dreamcast, I have to change the Pelican switch to "Dreamcast", but I still have to change my TV since it does no signal conversion at all...

Integrating a multi-input switch like that into the OSD3 would allow for signal conversion, and would allow people with lots of different signal sources (I, for example, have a Cable Box, Wii, PS2, Dreamcast, Genesis, Super NES, NES, VCR, and LD Player, all hooked up to a TV with one SD Component input, two Composite inputs, and an S-Video input...) to have the ability to switch between, record, and playback from any of those sources.
Logged
mgao
Neuros Audio Team
Jr. Member
**
Posts: 94


View Profile
« Reply #11 on: July 16, 2009, 10:35:59 pm »

It is always exciting to look forward (if I may, This Is Really Big!), regardless of the challenges ahead of us.

Here is a few things I can think of in order to make a TI chipset based truly opened OSD3 not only a dream.

1. the 'right' HW

1.1 full featured OSD support for user interface overlay with video
1.2 both up-scale and down-scale resizing support
1.3 both component and HDMI video I/O
1.4 wired AND wireless network
1.5 USB2.0 and SDHC
1.6 Low power consumption and flexible individual subsystem power control

2. mature software stack

2.1 production quality codecs for both audio and video decoding/encoding
2.2 fully functional peripheral drivers
2.3 fully functional A/V framework
  - A/V capturing/rendering
  - A/V synchronization
  - A/V pre/post process data chain
  -A/V demuxing/muxing
2.4 fully functional GUI framework

and yes, this is/will be a lot of work to be done, yet all of this is really the very basic stuff that OSD3 is going to be built on, again look at how quickly Neuros LINK was prototyped and how much was/is yet to be done, with the already mature x86 platform. And this really brings up the last and actually the most import part, openness.
   
3. open platform

3.1 open specifications for both ARM and DSP subsystem, and the video co-processing system
3.2 complete toolchains for both ARM and DSP
3.3 hacker friendly source code and build system access
   - please, no more extra steps for codec engine/DSP bridge stuff, huge difference can be made by removing little inconvenience in developer's regard.
3.4 centrally organized development and user community

last but not least,
3.5 hacker friendly HW from both development setup AND price point of view.

The hope (never underestimate what the community can do) is, 2 can be achieved relatively fast (nor to underestimate the time it may take) with 3 in place. Only with 2 ready, can OSD3 start being real. This is not to say that Neuros can not start with building some developer version early-phase HW, but that is not OSD3.
Logged
ganeshncm
Newbie
*
Posts: 31


View Profile
« Reply #12 on: July 18, 2009, 12:01:15 pm »

My 2c.

Are we bound to have TI / ARM processors? Why not make OSD firmware somewhat independent of the hardware ? Give users the option to choose TI ARM or Intel/AMD ATOM kind of processors.

Enable OSD to run some flavour of MythTV, Freevo or probably Linux MCE (Extend the scope to cover beyond playback and record)

is it asking too much?




Logged
JoeBorn
Neuros Audio Team
Administrator
Hero Member
*****
Posts: 1376



View Profile WWW
« Reply #13 on: July 21, 2009, 01:58:18 pm »

Are we bodund to have TI / ARM processors? Why not make OSD firmware somewhat independent of the hardware ? Give users the option to choose TI ARM or Intel/AMD ATOM kind of processors.

well, to some extent that's likely to happen automatically since we are currently developing for x86, but don't underestimate how much ends up not being truly extracted.  The HW still matters, at least it still does in 2009.

Quote
Enable OSD to run some flavour of MythTV, Freevo or probably Linux MCE (Extend the scope to cover beyond playback and record)

off the shelf software, absolutely, but focusing on a DVR I think is the wrong way to go, it's just too crowded a space.  The operators (cable and sat) have the lions share and TiVo has the bulk of the crumbs that they've left behind. To have a two channel DVR, you are looking at a minimum $100 cost upper, so we're likely to be looking at a $500 box that's not as smooth as a tivo, thats a pretty rough position to be in IMHO.




[/quote]
Logged

jborn (at) neurostechnology.com
#neuros on freenode.net
srobertson
Administrator
Newbie
*****
Posts: 4


View Profile
« Reply #14 on: July 27, 2009, 03:28:44 pm »

The simulator will include support for the ARM, DSP, accelerators, etc.  It is a full system simulator.  Currently it runs using CCSv4 from TI not QEMU.  What is the interest in QEMU going forward as we are trying to guage that effort?  The CCSv4 version today runs on Windows (please don't shoot the messenger) but should be running on Linux by the end of this year Smiley

This sounds fantastic. Simulation of the DSP and accelerators is far more important to me than which architecture the simulator runs on; while I really do hate working in Windows, solid developer tools are absolutely worth the pain for the few developers who need DSP simulation. Personally, 'built on QEMU' is in the 'nice to have' category only.

Quote
The community should be able to write their own codecs to run on the DSP.  To incorporate with TI's codecs they would need to be xDM complaint (so that they don't stomp on each other).  We already have people in the community interested in ffmpeg on the DSP so perhaps by the time silicon is out you would see libavcodec running on the DSP.

Can you provide links to these discussions?
Logged
Pages: [1] 2 3 4
Print
Jump to: