[mythtv] MythTV Recording System Future

[Isaac Richards]

On Saturday 19 July 2003 11:24 pm, Mike Javorski wrote:
> 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
> codecs.

Those really weren't core system files.  Also, you were adding user 
configurable options to a codec that didn't have any such options before.

And as I said before, those other bits could fairly easily be included into 
the recorder class, if you wanted to do the work.  Then, everything dealing 
with capturing from a source type would be in one place, pretty much 
completely separate from everything else.  Would that satisfy your definition 
of a 'plug-in'?  Only thing it's not is dynamically loadable, but that's 
silly for such a tiny bits of code anyway.

The decoder bits are already completely separated like that -- all .nuv 
parsing is in nuppeldecoder.cpp, support for everything libavcodec decodes is 
in avformatdecoder.cpp.

> 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.

You'd use more space with the plugin system and the overhead of multiple 
shared libraries than you would excluding, the what, 200 lines of code 
hardware mjpeg capture support is?

> 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"?

Data from the pvr cards is plain mpeg.  It's not wrapped in anything.  For 
some reason, people get confused by the fact that I name it .nuv. =)

I would be losing the flexibility that having my own file format gives by 
having to support other random formats.  Not all formats are equal, they 
can't all support the same things.

> 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.

All it needs to be supported natively in windows is for someone to write a, 
what is it now, DMO? DirectShow filter?, for it.  I can't imagine it being 
very difficult -- this isn't a very complicated video format here.

Isaac