Mailing List Archive: MythTV: Users

Mythstreamtv nuppel divx

Index | Next | Previous | View Threaded

netslayer at hotmail

Feb 9, 2005, 12:11 AM

Post #1 of 5 (1445 views)
Permalink

Mythstreamtv nuppel divx

Alright so i've heard mythstream doesn't support nuppel divx files recorded
using bttv cards because videolan doesn't support it. Well why can't
mythtranscode be added as a layer here? nuppel divx -> mythtranscode ->
mythstream -> videolan -> Me

I might have forgotten a step here < nuvexport workings > as I haven't
really looked to see how mythtranscode works yet.

Yes the processor requirements would be high, but we're talking low bitrate
divx files anyway, and I believe using mythtranscode to do nuppel divx ->
normal divx is around 1:1 live encoding speed last time i did one.

I need to look into this when I have time, but wouldn't mind if someone else
did it :-P
Wouldn't this be feasable?...

I've been the guy mentioning on and off the list every year that videolan +
mythtv needed to be integrated lol guess someone finally did it.

jcaputo1 at comcast

Feb 9, 2005, 10:36 AM

Post #2 of 5 (1405 views)
Permalink

Re: Mythstreamtv nuppel divx [In reply to]

On Wednesday 09 February 2005 3:11, Chris Germano wrote:
> Alright so i've heard mythstream doesn't support nuppel divx files
> recorded
> using bttv cards because videolan doesn't support it. Well why can't
> mythtranscode be added as a layer here? nuppel divx -> mythtranscode
> -> mythstream -> videolan -> Me
>
> I might have forgotten a step here < nuvexport workings > as I haven't
> really looked to see how mythtranscode works yet.
>
> Yes the processor requirements would be high, but we're talking low
> bitrate
> divx files anyway, and I believe using mythtranscode to do nuppel divx
> -> normal divx is around 1:1 live encoding speed last time i did one.

Umm, last time I checked, mythtranscode can't output 'normal' divx (if
by that you mean a standard mpeg or avi container). Mythtranscode can
output 2 things: a Myth .nuv container format (containing either
RTjpeg or MPEG-4 encoded Myth content), or raw *decoded* audio/video
frames (for passing to an external encoder program for re-encoding into
another codec/container).

That's not to say that what you propose isn't technically possible;
mythtranscode has the potential to write any container format supported
by libavformat, and any codec supported by libavcodec. However, I
believe Isaac has said in the past that Myth will never support
(direct) output to other formats. Hence the need for an external
utility like nuvexport.

That said, there is one thing that might be feasible... the ability to
transcode Myth content on the fly as it's being served from the
backend, while still keeping the Nuppel container format. This would
be very handy for watching on remote frontends over a slow link, or
with different video output setups. For instance, my G3 iBook might be
able to handle 352x240 MPEG-4 at a low bitrate, but I don't want to
record all my shows at that resolution because my main frontend/backend
is in the family room on a 60" TV. Don't know if it would be feasible
to use it to 'downgrade' HD content (CPU reqs?), but if videolan can do
it for DVD-resolution MPEG-4 avi/mpeg files, then Myth should be able
to handle it for PAL/NTSC resolution recordings.

-JAC
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

papenfuss at juneau

Feb 9, 2005, 10:57 AM

Post #3 of 5 (1404 views)
Permalink

Re: Mythstreamtv nuppel divx [In reply to]

> Umm, last time I checked, mythtranscode can't output 'normal' divx (if
> by that you mean a standard mpeg or avi container). Mythtranscode can
> output 2 things: a Myth .nuv container format (containing either
> RTjpeg or MPEG-4 encoded Myth content), or raw *decoded* audio/video
> frames (for passing to an external encoder program for re-encoding into
> another codec/container).
>
> That's not to say that what you propose isn't technically possible;
> mythtranscode has the potential to write any container format supported
> by libavformat, and any codec supported by libavcodec. However, I
> believe Isaac has said in the past that Myth will never support
> (direct) output to other formats. Hence the need for an external
> utility like nuvexport.
>
That's pretty much what I'd come up with a few days ago. The
.nuv/.sql format works fine for an MPEG2-type stream, since it's not
Nupplevideo to begin with. If transcoded and commercial-cut, you're
basically screwed to reencode *AGAIN* with nuvexport. I've not found
anything that will extract sync-intact NUV-encapsulated DIVX into a plain,
standard *anything* without reencoding with nuvexport. nuv2avi should
work, but sync has always been off in the resulting avi file.

My question is how funky is the mythtv-modified .nuv file? It's
not normal nuppelvideo, since even mplayer can't play it directly.

-Cory

*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************

jcaputo1 at comcast

Feb 9, 2005, 11:28 AM

Post #4 of 5 (1404 views)
Permalink

Re: Mythstreamtv nuppel divx [In reply to]

On Wednesday 09 February 2005 13:57, Cory Papenfuss wrote:
> My question is how funky is the mythtv-modified .nuv file? It's
> not normal nuppelvideo, since even mplayer can't play it directly.

Not sure; that question's out of my league. IIRC, the original
NuppelVideo container was designed around a single codec (RTjpeg, or
something similar). I'm pretty sure MP3 audio wasn't in it either.

Here's a thought: maybe we've been going about this backwards. What
if, instead of trying to get Myth to output/support all kinds of
different formats, we took the opposite approach... split out all of
Myth's Nuppel-decode/playback code into an independent library
(libmythnuv ?) and make it available for other projects (Xine, MPlayer,
VideoLAN) to incorporate as a decoder engine. Or maybe integrating the
core Myth Nuppel code into libmythavformat/libmythavcodec and
contributing it back to the FFMpeg? Question is: how much of Myth's
internal playback (specifically seeking) is dependent on stuff in the
database?

Just thinking out loud...

-JAC
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

papenfuss at juneau

Feb 9, 2005, 11:39 AM

Post #5 of 5 (1402 views)
Permalink

Re: Mythstreamtv nuppel divx [In reply to]

> Here's a thought: maybe we've been going about this backwards. What
> if, instead of trying to get Myth to output/support all kinds of
> different formats, we took the opposite approach... split out all of
> Myth's Nuppel-decode/playback code into an independent library
> (libmythnuv ?) and make it available for other projects (Xine, MPlayer,
> VideoLAN) to incorporate as a decoder engine. Or maybe integrating the
> core Myth Nuppel code into libmythavformat/libmythavcodec and
> contributing it back to the FFMpeg? Question is: how much of Myth's
> internal playback (specifically seeking) is dependent on stuff in the
> database?
>
> Just thinking out loud...
>
Good idea, and I just realized that what you are describing is
exatly what I've been looking for... just didn't realize it. I've never
wanted my actual Mythbox to do the crunching for export/archival purposes.
In fact, I don't even want MPEG2->MPEG4... just commercial cutting. Any
other format (archival to VCD, SVCD, DVD, DIVX for computer, etc) should
be done *LATER* on the single, master *CUT* file. It shouldn't be rolled
into Myth, since there are a lot of other tools that do a better job. The
fundamental problem seems to be that you either need:

A) A general purpose transcoding widget that understands the cutlist
(read: nuvexport)

OR
B) Get MythTV to do rudimentary lossless cutting of the master (doesn't
exist)

Anything else appears to be using the wrong tool for the job. I
don't know about inventing another format library, but at least using B)
option and making a "normal" file would allow for all possibilities.

Just thinking out loud too...

-Cory

*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads