[mythtv] Why nuppelvideo mpeg4?

[Reza Naima]

Thanks for all the replies so far.  A few quick questions :

- does the patched mplayer.dll work perfectly?  For me, it only plays
  some of the mpeg4 files, and it seems to die halfway through the bulk
  of the ones it does work for
- mpeg4.nuv seeking in xbmc is way broken, it thinks 30m shows are 3
  minutes long.  the FF, RF doesn't work well for me.  
- i asked this before, and i still need a bit of clarification.  mpeg2's
  from pvr's work fine, and are standard mpeg2's.  Someone replied and
  said mpeg4.nuv's are a whole different beast.  what container does
  the mepg2's use?  and why not use that container for the mpeg4s?  
  or is it in some other aspect that the mpeg4's are different?

And to clarify, I'm not saying that mythtv is broken in the slightest.
I'm just trying to figure out a way to make it more compatible with
external applications so I can migrate content off mythtv for archival
purposes.  And as I don't want to have to convert the content multiple
times based on the yet unkown target I want to watch the content -
especially as it'll be burned on a DVD - I would prefer some standard
encoding format.  I'm reluctant to use mpeg2 for compression reasons (I
can fit a lot more mpeg4 in the same space). 

Reza


On Tue, Aug 09, 2005 at 07:25:58AM +1000, Lincoln Dale sent me this...
> Reza,
> 
> firstly, thanks for compiling up a mplayer.dll with the diff to 
> mplayer's .nuv support i posted.  i have been using an xbox as a 
> frontend for playing back recordings with 100% stability, including 
> content transcoded into mpeg4.
> (note that i only say previous recordings here - even with CVS 
> xbmcmythtv it has issues with "live tv", "status" & various other things 
> - basically i've created a xbmc front-menu which only calls 
> 'mythtvrecordedshows.py'.
> 
> i'll contribute a Wiki on how to set it all up as xbmc makes a pretty 
> awesome frontend for folks that want a quick way of playing back 
> content.  i used to use linux-on-xbox to do it - with the ~2 minutes 
> boot-time - but with xbmc as my dashboard its more like 15 seconds from 
> poweron to viewing a listing of recordings.
> 
> 
> regarding "why not use .avi":
> 
> .avi has numerous problems.  for one, the indexes are at the tail of the 
> file and are only written at the last moment.  therefore 
> partially-recorded files or files-currently-being-recorded have no index.
> 
> likewise its not a very nice 'streaming' protocol if one has to seek to 
> the end to read the index at the beginning of playing back a stream.
> 
> .nuv as a container is just fine - and mplayer's previous inability to 
> play it back is not Myth's fault - but rather mplayer.
> patches have been around for years but never accepted by mplayer folks.
> perhaps we can jointly work on improving those to the point where 
> mplayer folks _will_ accept them?
> 
> i have found that a patched mplayer can play back .nuv files just fine - 
> while you cannot use jump-forward/jump-back (left-arrow / right-arrow) 
> to seek, you can use RW/FF (left-trigger / right-trigger) to RW/FF at 
> 1x/2x/4x/8x/16x/32x.  sure - the picture breaks up until it sees a 
> keyframe - but that isn't so bad - and if we did want to fix something, 
> that'd be one of the things to address.
> 
> it may make sense to extend Myth to add specific containers relating to 
> the information that also goes into a SQL table - jump tables, 
> commercial-detection etc - and i don't think the Myth team would resist 
> having that as an option - but in reality, its up to mplayer to do much 
> of the heavy lifting, not Myth.
> 
> 
> cheers,
> 
> lincoln.
> 
> Reza Naima wrote:
> >I was wondering why we are using the nuppelvideo container for mpeg4? It
> >can't be hard to convert to a different format - nuv2avi works great.
> >Why is it that we're not using avi's (for example) rather than nuv's to
> >store the files?  mplayer (used by xbmc) has a lot of issues with the
> >.nuv files, and unless you have the special codecs installed on windows
> >.nuv mpeg4 files will not play.  
> >
> >How hard would it be (and are there any reasons no to) modify the code
> >such that it will generate more friendly mpeg4 files?
> >
> >Thnx
> >Reza
> >
> >p.s. what is all the seek information in the DB for?  why isn't that
> >in the video file itself?