[mythtv] MythTV Recording System Future

Mike Javorski mikej at carmelfly.com
Sat Jul 19 21:24:08 EDT 2003

On Sat, 2003-07-19 at 18:32, Isaac Richards wrote:
> On Saturday 19 July 2003 08:17 pm, Mike Javorski wrote:
> > When I set out on adding the various pieces of IVTV support I had no
> > idea the levels of cruft that had to be used to make it work. It's
> > crazy. There is little bits and pieces all over the place to make it
> > work. I realize this may be partly due to the fact it was added to an
> > existing system which dealt with individual audio/video compression
> > sources, but yikes..
> What cruft?  For the patch you sent in, you modified the mpegrecorder class 
> setup routines, the one bit in the overall tv recorder class that sets the 
> various recording settings (and chooses the recorder class), and the UI setup 
> bits.  It's hardly complicated.  The last two parts could even conceivably be 
> moved into the recorder classes if you really wanted to, so everything would 
> be in one place.

What I meant by cruft (in hindsight, it most likely wasn't the best word
to use to describe the issue), is the way was all the little places that
things had to be changed to modify the codec support. I had to change 3
cpp files (2 of which were core system files) and a h file to simply add
2 options to the codec. I realize that I didn't have to make a lot of
changes, but I looked through a lot of things while trying to figure it
all out. There is little hacks here and there to support different
mechanisms. Special little bits of code to handle the little
eccentricities of the different codecs.  It just seemed to me that a
more "distinct" plug-in system might make it easier to add and modify

Having a separate plug-ins could make managing the code much easier.
Developing additional codecs could be done without having to change
core-system code, thus reducing the chance of one codec interfering with
another. It would also allow for inclusion/exclusion of various codecs.
Say if I didn't want to have MJPEG support, I could exclude that
plug-in, and decrease the size of the system a bit.

> > Well anyway. I am wondering what the general consensus is out there.
> > Should the recording system be made "plug-in" based? I would imagine
> > that in future there might be other "special" devices that people will
> > want to support, and the current mechanism (though it does work) makes
> > it a bit like voodoo.
> >
> > Additionally there should be comparative playback/decoding plug-ins
> > ones that are designed to deal with different stream types. (as
> > recordings should always be stored as some type of stream on the disc)
> >
> > this could possibly be done with extensions:
> >  .mpg => fmpeg decoder mechanism
> >  .nuv => true nuppelvideo decoder mechanism
> >  .divx => some DiVX decoder
> >  .mtvs => the isaac richards nuv format (MythTVStream)
> >  .omf?? => ogg stream format
> >  .avi => longstanding though evil stream format
> All of these, aside from the original .nuv and .ogm, are already playable by 
> mythtv.  I _really_ don't see the point of recording into any other formats 
> than what it currently does.  There's tools available to take it out of the 
> modified .nuv format, and the added complexity and loss of flexibility to do 
> native recordings just isn't worth it to me.  And if you really want 
> something playable by other programs without any work at all, just use a 
> wintv pvr-?50 like you are now =)

I just used these as examples of streams and "codecs" that could be
supported. Basically what exists currently would "become" the mtvs
plug-in. It would support the same options it does now, but in addition
there would be a plug-in to store a plain MPG program file (MPG from the
PVR's now seems to be wrapped in a mythtv-nuv file) or a cross-platform
supported stream file (like omf or avi). How do you see it as losing
flexibility by making this a plug-in architecture? How are you losing
"native recordings"?

> > This system would allow for recording to formats that can be archived
> > and viewed on other platforms. Additionally it would support recordings
> > that were recorded in one format, and then re-encode them with a non
> > real-time encoder to end up with a higher quality file, but still be
> > able to view them through the mythtv interface. (something I want is to
> > record in Huffyuv then transcode to a multi-pass DivX or MPEG)
> You can actually record into a .nuv wrapped huffyuv (or pretty much anything 
> supported by libavcodec) file extremely easily (assuming you've got enough 
> disk speed/space to keep up).  I just don't have the functionality enabled 
> because I _know_ people will start picking random codecs that they shouldn't 
> be using and then complain when things don't work =)

Thats nice, but it doesn't truly solve the problem I have which is that
NOTHING supports the MythTV proprietary .nuv file perfectly, or without
having to patch and recompile the program. I also cannot use it in
Windows where I have to burn my DVD's. That is why I think it would be
useful. For people who want a truly portable stream file format. If you
are using mythtv strictly as a PVR, then the mythtv nuv file is fine.
Having to convert the MythTV nuv file to another format and only then
being able to work with it is a great hassle.

As for the user factor, I agree it could be a problem. It should
probably be handled the same way that the new program scheduling system
is handled. An "Advanced" menu which gives you access to the
non-standard (aka non mythtv-nuv) codecs and their options. At the
moment it's easy to cause the machine to try and burn itself up by
playing with the MPEG4 codec options. 

Does that make any more sense Isaac? Please remember I am not trying to
insult yours, or anyone else's code. I just feel that with all the
add-ons and filters being "plug-ins" for MythTV, that the recording
functionality should not be overlooked. I think it could benefit from
the modularization. 

I do not want to force this idea on anyone. I think it's a great idea
(from my perspective), but I am one person, and a person who hasn't been
developing this thing for a very long for that matter. I will probably
develop something anyways, but if I have to do it alone, it's not going
to be as nice as something that is collaborated on. I wanted to see if
it might be a good idea for inclusion in future MythTV versions.

- Mike

More information about the mythtv-dev mailing list