[mythtv] MythTV Recording System Future

[Mike Javorski]

On Sat, 2003-07-19 at 22:40, Isaac Richards wrote: 
> 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.

I use the word "core" to represent the fact that they are binding files.
tv_rec is part of the "core" of the TV system. It holds the "core"
functionality related to TV recording. Currently, in order for a codec
to run, it has to be initialized inside tv_rec. There is several dozen
lines of code  (basically all of TVRec::SetupRecorder) that are codec
dependent.  Granted this could be moved around, but it hasn't been yet.
It would be a good first step towards generalization of the
recording/playback system. I will start to work on this once I get some
time.

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

Yes that would satisfy my def. of plug-in in this instance. 

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

I am going to have to do more reading before responding to this.




> > 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 used it as an example. 

> > 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. =)
Yeah that is confusing. It also is confusing down the line. Why are they
not just given .mpg extensions if thats what they are? From what I can
tell, the system would support it just fine.


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

The point is not to replace the current system, the point is to add
support for alternate systems. I am talking about allowing people to
easily use alternate file formats if they want to without having to
re-engineer the system. your "nuv" system would be the "stock-default"
system, but if you wanted to you could also have other systems. All you
would have to maintain is the mythtv proprietary nuv code. If others
wanted to add support for something else, it would be separate files
that could easily be removed if they stopped functioning/being
maintained.



-Mike