jkeagle13
asked on
PVR/DVR Middleware for Embedded Device
Hello,
I am working on an embedded project with the TI DM365 processor running MontaVista Linux. I need to be able to record an audio and video stream in sync for a consumer television STB I am designing. We aren't looking to build a "traditional" DVR solution, but feel that much of the functionality we are looking for would probably be able to be harvested from a DVR code solution.
We need to be able to simultaneously encode and decode synchronized audio and video. We will store it to a buffer, essentially mimicking something similar to a time shift solution.
We have run into problems so far trying to record audio and video together. Also, when we went to play back during recording, we got a message saying it was locked.
Can anyone point me in the right direction of where I might acquire a PVR/DVR code base to work with? Any other help or advice would be appreciated. Having a strong middleware in place will help facilitate the changes we need to make for our unique application.
Thanks,
Joseph Irvine
I am working on an embedded project with the TI DM365 processor running MontaVista Linux. I need to be able to record an audio and video stream in sync for a consumer television STB I am designing. We aren't looking to build a "traditional" DVR solution, but feel that much of the functionality we are looking for would probably be able to be harvested from a DVR code solution.
We need to be able to simultaneously encode and decode synchronized audio and video. We will store it to a buffer, essentially mimicking something similar to a time shift solution.
We have run into problems so far trying to record audio and video together. Also, when we went to play back during recording, we got a message saying it was locked.
Can anyone point me in the right direction of where I might acquire a PVR/DVR code base to work with? Any other help or advice would be appreciated. Having a strong middleware in place will help facilitate the changes we need to make for our unique application.
Thanks,
Joseph Irvine
Take a look at MythTV. http://www.mythtv.org/ It should have all of the components you need to record and play audio/video.
It's a complex project, but you should be able to find the pieces you need.
It's a complex project, but you should be able to find the pieces you need.
ASKER
Hello Eager,
We have actually been prototyping in MythTV on a desktop PC and it has worked very well. The problem is that it doesn't translate well to embedded hardware; it is far too overwrought and was never designed for that environment. As a tertiary issue, we also run into GPL problems.
Essentially, we are looking for something identical to MythTV that is optimized for embedded hardware, specifically the TI DM365 and associated tool chains.
Thanks,
Joseph
We have actually been prototyping in MythTV on a desktop PC and it has worked very well. The problem is that it doesn't translate well to embedded hardware; it is far too overwrought and was never designed for that environment. As a tertiary issue, we also run into GPL problems.
Essentially, we are looking for something identical to MythTV that is optimized for embedded hardware, specifically the TI DM365 and associated tool chains.
Thanks,
Joseph
Yes, MythTV is a big project for designed for big hardware.
You can also look at other ARM processors, like BeagleBoard, which has support for record/playback of video. For example, there are a variety of components such as gstreamer which are used to build applications like Xine and VLC. Also look at mplayer.
Whether you will find any software optimized for ARM or a particular ARM-based processor is a more difficult issue. Sometimes you have to do your own development to make things work the way you want.
What GPL issues?
You can also look at other ARM processors, like BeagleBoard, which has support for record/playback of video. For example, there are a variety of components such as gstreamer which are used to build applications like Xine and VLC. Also look at mplayer.
Whether you will find any software optimized for ARM or a particular ARM-based processor is a more difficult issue. Sometimes you have to do your own development to make things work the way you want.
What GPL issues?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hello @NotLogical,
If you send me an email, joseph (at) irvinemail (dot) org, I can fill you in on a more information off-list that is relevant. I can only discuss high-level aspects in forums.
We are looking for an ARM9 based solution, given our choice of the TI DM365. We know that we won't be able to simply drop in something off of the shelf, wrap up our project, and deliver it to the customer next week. Everything you mention, resource allocation, disk management, buffering, are all acutely on on radar for implementation hurdles.
Our hope was that if we had a DVR middleware package, despite being nothing near what we need, we could salvage bits and pieces and reuse code, removing most of the features that we don't need. If, for example, it had a satisfactory encoding library that provided an audio/video synchronization, we could cut that out and use it in building our solution. We know we are going to need to build from the ground up, but want to be smart and use as much as we can find.
The engine that was locking the files was the provided DVSDK encoding function; which also lacked the AV sync. We are actively pursuing various libraries, but felt that having a complete DVR solution to tear down and scrap for various pieces would solve many issues, such as grabbing a working encoder.
Thanks for your help and pointers. We have our legal counsel who is very familiar with all of the intricacies of GPL. Since this is a product for commercialization, we can't use anything out of MythTV as we can't open it to the public when completed due to the competitive environment this project will operate in. We are seeking for code we can commercially license.
Thanks,
Joseph
If you send me an email, joseph (at) irvinemail (dot) org, I can fill you in on a more information off-list that is relevant. I can only discuss high-level aspects in forums.
We are looking for an ARM9 based solution, given our choice of the TI DM365. We know that we won't be able to simply drop in something off of the shelf, wrap up our project, and deliver it to the customer next week. Everything you mention, resource allocation, disk management, buffering, are all acutely on on radar for implementation hurdles.
Our hope was that if we had a DVR middleware package, despite being nothing near what we need, we could salvage bits and pieces and reuse code, removing most of the features that we don't need. If, for example, it had a satisfactory encoding library that provided an audio/video synchronization, we could cut that out and use it in building our solution. We know we are going to need to build from the ground up, but want to be smart and use as much as we can find.
The engine that was locking the files was the provided DVSDK encoding function; which also lacked the AV sync. We are actively pursuing various libraries, but felt that having a complete DVR solution to tear down and scrap for various pieces would solve many issues, such as grabbing a working encoder.
Thanks for your help and pointers. We have our legal counsel who is very familiar with all of the intricacies of GPL. Since this is a product for commercialization, we can't use anything out of MythTV as we can't open it to the public when completed due to the competitive environment this project will operate in. We are seeking for code we can commercially license.
Thanks,
Joseph
Joseph,
I will definitely contact you off-list, for further discussion. I hope that I can be of further assistance to you there.
Thanks for the opportunity to assist you via EE, and to exchange some ideas. It is definitely good to see that you are aware of the scope of such a project.
In the meantime, I would still invite any other experts to post their ideas and experience. One learns about new projects and solutions all the time!
Regards,
NotLogical
I will definitely contact you off-list, for further discussion. I hope that I can be of further assistance to you there.
Thanks for the opportunity to assist you via EE, and to exchange some ideas. It is definitely good to see that you are aware of the scope of such a project.
In the meantime, I would still invite any other experts to post their ideas and experience. One learns about new projects and solutions all the time!
Regards,
NotLogical
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I presume that you are basing everything around the CE (Codec Engine). You do not mention what is your backing store for the media.
Am I to presume that you use a standard fopen() call to prepare your media files? Or, are you trying to do this with the existing gst-launch application, and this is strictly an evaluation?
Thanks...