Re: [Mvpmc-users] VLC setup problems...

[Tom Metro-9]

stuart wrote:
> Find out what happened to Chase's iTouch/iPhone project.  Looked like a

Yes, that proxy sounded like the least effort way to inject real-time
transcoding into the MythTV system while retaining the full
functionality of the client.


> Use VLC to serve up a real-name-linked-list-of-shows to the mvpmc's
> file browser.

Another option, though it's probably more work....Jon mentioned having a
FUSE driver for MythTV, which I think lets you browse a file system and
turns file access requests into MythTV protocol requests. Such a driver
would eliminate the need to symlink shows to human-readable names, and
avoid the multiple storage directories problem, but would need to be
modified to request the video through VLC when needed.

Although that doesn't really buy you anything that a similar
modification to mvpmc's existing MythTV client would get you. (The show
metadata could be modified to incorporate a flag indicating whether
transcoding is necessary. Then mvpmc's client would look at that, and if
yes, request the video from the same server, but via VLC. If not, use
the usual MythTV protocol to stream the video. This might be easier to
do than getting the proxy to work, but probably wouldn't support random
seeking in the video. Unless mvpmc's MythTV client translated seek
commands into the equivalent VLC commands. Probably cleaner to go the
proxy route.)

  -Tom

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On May 13, 2009, at 1:26 AM, Tom Metro wrote:
> stuart wrote:
>> Find out what happened to Chase's iTouch/iPhone project.  Looked  
>> like a
>
> Yes, that proxy sounded like the least effort way to inject real-time
> transcoding into the MythTV system while retaining the full
> functionality of the client.

A quick update on this. I've stopped working on the transcode proxy in  
the form I initially was using. I've been working with a MythTV dev  
who has worked some on getting a libav* encoding solution inside the  
MythTV libraries. I have used his patch to transcode recordings using  
mythtranscode to other video formats and containers. I also modified  
mythtranscode so it can transcode live tv recordings.

My current idea is to have a frontend connect like usual to the  
backend and start a recording. Instead of querying for data from the  
backend, the frontend will then connect to a transcode proxy which  
will simply wrap mythtranscode and shuffle the output to the frontend.

At any point it would be helpful if people could test out my work and/
or contribute. I've got an svn repo with my own branch of MythTV trunk  
at http://svn.assembla.com/svn/legend/mythtv/transcode-br. Note that  
it's still very early, and many issues have yet to be worked out.

Thanks,
Chase

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[stuart-20]

Chase Douglas wrote:

> On May 13, 2009, at 1:26 AM, Tom Metro wrote:
>> stuart wrote:
>>> Find out what happened to Chase's iTouch/iPhone project.  Looked  
>>> like a
>> Yes, that proxy sounded like the least effort way to inject real-time
>> transcoding into the MythTV system while retaining the full
>> functionality of the client.
>
> A quick update on this. I've stopped working on the transcode proxy in  
> the form I initially was using. I've been working with a MythTV dev  
> who has worked some on getting a libav* encoding solution inside the  
> MythTV libraries. I have used his patch to transcode recordings using  
> mythtranscode to other video formats and containers. I also modified  
> mythtranscode so it can transcode live tv recordings.
>
> My current idea is to have a frontend connect like usual to the  
> backend and start a recording. Instead of querying for data from the  
> backend, the frontend will then connect to a transcode proxy which  
> will simply wrap mythtranscode and shuffle the output to the frontend.
>
> At any point it would be helpful if people could test out my work and/
> or contribute. I've got an svn repo with my own branch of MythTV trunk  
> at http://svn.assembla.com/svn/legend/mythtv/transcode-br. Note that  
> it's still very early, and many issues have yet to be worked out.
>
> Thanks,
> Chase

I'm in such a hurry right now, I'll ask better questions later...  For
now: many of us who use mythtv hesitate loading up the SVN version.  The
released mythtv is difficult to stabilize to the point of general user
acceptance.  In my case, I've over a T-byte on MBE/SBE machines yet the
ReplayTV is still the preferred PVR.

Has anyone dealt w/this issue here and resolved it?

-thanks



------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On May 13, 2009, at 9:17 AM, stuart wrote:

> Chase Douglas wrote:
>> On May 13, 2009, at 1:26 AM, Tom Metro wrote:
>>> stuart wrote:
>>>> Find out what happened to Chase's iTouch/iPhone project.  Looked  
>>>> like a
>>> Yes, that proxy sounded like the least effort way to inject real-
>>> time
>>> transcoding into the MythTV system while retaining the full
>>> functionality of the client.
>> A quick update on this. I've stopped working on the transcode proxy  
>> in  the form I initially was using. I've been working with a MythTV  
>> dev  who has worked some on getting a libav* encoding solution  
>> inside the  MythTV libraries. I have used his patch to transcode  
>> recordings using  mythtranscode to other video formats and  
>> containers. I also modified  mythtranscode so it can transcode live  
>> tv recordings.
>> My current idea is to have a frontend connect like usual to the  
>> backend and start a recording. Instead of querying for data from  
>> the  backend, the frontend will then connect to a transcode proxy  
>> which  will simply wrap mythtranscode and shuffle the output to the  
>> frontend.
>> At any point it would be helpful if people could test out my work  
>> and/ or contribute. I've got an svn repo with my own branch of  
>> MythTV trunk  at http://svn.assembla.com/svn/legend/mythtv/transcode-br 
>> . Note that  it's still very early, and many issues have yet to be  
>> worked out.
>> Thanks,
>> Chase
>
> I'm in such a hurry right now, I'll ask better questions later...  
> For now: many of us who use mythtv hesitate loading up the SVN  
> version.  The released mythtv is difficult to stabilize to the point  
> of general user acceptance.  In my case, I've over a T-byte on MBE/
> SBE machines yet the ReplayTV is still the preferred PVR.

I completely understand. I would much rather be doing development work  
on non-trunk mythtv. However, the devs have stated they won't accept  
any new features outside of trunk, and the change from qt 3 to 4 would  
make it a huge hassle to do non-trunk development and then a port to  
trunk when it's ready. Right now we're all stuck in a rough spot.

I also don't absolutely need testers yet, I only mentioned it in case  
anyone was interested in trying it out.

Thanks

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Tom Metro-9]

Chase Douglas wrote:
> I've been working with a MythTV dev who has worked some on getting a
> libav* encoding solution inside the MythTV libraries. I have used his
> patch to transcode recordings using mythtranscode to other video
> formats and containers.

In real time?


> I also modified mythtranscode so it can transcode live tv recordings.

And it's able to keep up?

I used to be under the impression that VLC used some magic to pull off
it's real time transcoding, like specially optimized codecs, but that's
not necessarily the case, right? Although it must be doing something,
because with most tools a transcode to MPEG2 runs at far less than real
time (unless you have a really fast machine).


> My current idea is to have a frontend connect like usual to the backend
> and start a recording. Instead of querying for data from the backend,
> the frontend will then connect to a transcode proxy which will simply
> wrap mythtranscode and shuffle the output to the frontend.

If you're working with a MythTV dev and modifying MythTV internals is
practical, why not take the approach of directly integrating real-time
transcode into the protocol, rather than requiring a proxy?

An idea that's been mentioned on this list a few times is extending the
MythTV protocol such that the connecting client communicates to the
back-end what it's capabilities are, and then the back-end provides it
with appropriately transcoded video.

  -Tom

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Tom Metro-9]

stuart wrote:
> many of us who use mythtv hesitate loading up the SVN version.  The
> released mythtv is difficult to stabilize to the point of general user
> acceptance.
>
> Has anyone dealt w/this issue here and resolved it?

If you're doing playback-only testing, perhaps run the SVN version in a
VM, with in imported copy of your database (which the SVN version will
undoubtedly alter the schema of) and your recordings directory mounted
read-only.

Though a VM is going to degrade the performance of any real time
transcoding you're trying to test.

I stopped following the MythTV dev list about 9 months ago. There seem
to be too many barriers to development. This issue with trunk
development (made worse by their infrequent releases resulting in a
wider gap between the stable version and trunk) is one problem. The
attitude they take towards bugs (they don't really want to know about
them unless you've also got a patch in hand) is another. Plus the
architecture is a mess. It wouldn't surprise me to see one of MythTV's
open source competitors surpass it in a few years.

I do have a few nuvexport patches to give to them, but an email to the
author went without a response.

  -Tom

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Roger Heflin-3]

On Thu, May 14, 2009 at 2:49 PM, Tom Metro <tmetro+mvpmc-devel@...> wrote:
> Chase Douglas wrote:
>> I've been working with a MythTV dev who has worked some on getting a
>> libav* encoding solution inside the MythTV libraries. I have used his
>> patch to transcode recordings using mythtranscode to other video
>> formats and containers.
>
> In real time?
>
If you machine is fast enough....

>
>> I also modified mythtranscode so it can transcode live tv recordings.
>
> And it's able to keep up?
>
> I used to be under the impression that VLC used some magic to pull off
> it's real time transcoding, like specially optimized codecs, but that's
> not necessarily the case, right? Although it must be doing something,
> because with most tools a transcode to MPEG2 runs at far less than real
> time (unless you have a really fast machine).
>

I don't believe vlc does any major tricks, if I was unable to
transcode stuff with
mencoder at close to real time, then vlc appeared to have difficultly  with
the same stuff.   And I believe both vlc and mencoder and mythtv use the
same underlying libraries to do their work...

I currently have a AMD 7750 overclocked to 3.1ghz and it is able to transcode
1080i to 720x480 at almost 2x real time just using a single cpu.  And that cpu
and a cheap MB and 4GB of ram is (65+65+40=$170-find a case/ps/hd/video).

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On May 14, 2009, at 3:49 PM, Tom Metro wrote:
> Chase Douglas wrote:
>> I've been working with a MythTV dev who has worked some on getting a
>> libav* encoding solution inside the MythTV libraries. I have used his
>> patch to transcode recordings using mythtranscode to other video
>> formats and containers.
>
> In real time?

Yes

>> I also modified mythtranscode so it can transcode live tv recordings.
>
> And it's able to keep up?
>
> I used to be under the impression that VLC used some magic to pull  
> off it's real time transcoding, like specially optimized codecs, but  
> that's not necessarily the case, right? Although it must be doing  
> something, because with most tools a transcode to MPEG2 runs at far  
> less than real time (unless you have a really fast machine).

It all depends on how you are transcoding and what your machine is  
capable of. For example, my main mythtv server is an athlon 64 box, 4  
years old, and it can barely transcode to libx264 and libmp3lame using  
ffmpeg for the iPhone. However, my Thinkpad T60 core duo can transcode  
at twice real-time, or ~60 fps. These numbers are for SD input though.  
FFmpeg puts out invalid stuff when I try to transcode HD input, so  
I've got to work on that.

>> My current idea is to have a frontend connect like usual to the  
>> backend and start a recording. Instead of querying for data from  
>> the backend, the frontend will then connect to a transcode proxy  
>> which will simply wrap mythtranscode and shuffle the output to the  
>> frontend.
>
> If you're working with a MythTV dev and modifying MythTV internals  
> is practical, why not take the approach of directly integrating real-
> time transcode into the protocol, rather than requiring a proxy?
>
> An idea that's been mentioned on this list a few times is extending  
> the MythTV protocol such that the connecting client communicates to  
> the back-end what it's capabilities are, and then the back-end  
> provides it with appropriately transcoded video.

The reason they aren't interested in doing this is that ffmpeg can be  
rather unstable. If your client requests a recording encoded in a  
certain format, and that causes a segfault inside mythtv's libavcodec,  
that will take down the entire backend. Using a proxy as a separate  
process means a segfault will kill your transcode and connection, but  
at least it won't kill mythbackend.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On May 14, 2009, at 4:18 PM, Roger Heflin wrote:

>> I used to be under the impression that VLC used some magic to pull  
>> off
>> it's real time transcoding, like specially optimized codecs, but  
>> that's
>> not necessarily the case, right? Although it must be doing something,
>> because with most tools a transcode to MPEG2 runs at far less than  
>> real
>> time (unless you have a really fast machine).
>>
> I don't believe vlc does any major tricks, if I was unable to
> transcode stuff with
> mencoder at close to real time, then vlc appeared to have  
> difficultly  with
> the same stuff.   And I believe both vlc and mencoder and mythtv use  
> the
> same underlying libraries to do their work...

If you use libx264 or libfaac or libmp3lame or any other external  
library, then they all use the same code. However, mencoder uses  
ffmpeg's libav* libraries while VLC uses its own libraries. For  
instance, right now you won't be able to transcode to the iPhone using  
Apple's http live streaming standard (just submitted to ietf) by using  
VLC as its mpeg-ts encoder won't encode things quite up to spec. It  
doesn't handle H.264 content in an mpegts stream correctly I think.  
However, if you check out an svn copy of ffmpeg (cause I just got some  
code committed to it that fixes their mpeg-ts encoder) and build the  
libraries, you'd be able to transcode using ffmpeg or mencoder.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel