[mythtv] Thoughts on CD/VCD/SVCD burning

[Isaac Richards]

On Friday 23 August 2002 05:30 am, Thor Sigvaldason wrote:
> All,
>
> 	I've spent the last 4 or 5 days trying to figure out a workable way to
> burn disc's of video content from MythTV. I have cobbled together some code
> to do it, but it's far from ready for primetime.
>
> 	So .... before I fold anything back into the tree, some thoughts/questions
> for open discussion:
>
> 	1. To burn a VCD and/or SVCD compliant disc (ie. something yu can stick in
> another computer, stand-alone DVD player, etc), the machine will need
> processor time. The former requires strict MPEG-1 (video) compliance, and
> needs specific resolutions (NTSC or PAL) to be compliant. The latter also
> requires adherence to standards (MPEG-2) that demand even more processing
> time.
>
> 	2. The tools to do this are all readily available. In particular, the
> mpegenc program from the mjpegtools effort will swallow a myth-style
> Nupple-encoded stream and spit out a compliant mpeg-1 or mpeg-2 (for VCD or
> SVCD) stream.

Well, they'll have to be modified -- the original Nuppelvideo didn't compress 
the audio, used a different version of rtjpeg.  Oh, and didn't use mpeg4 as 
an option, either =)  But, yes, the framework's there, and those should be 
relatively minor changes to the existing tools to get them to grok the 
changes.

> 	3. Compliance is not the problem. CPU time is the problem. The logic of
> "Fix Scheduling Conflicts" gets a heck of a lot more complicated when you
> need to allocate CPU time to re-encode content/burn discs. Do you want to
> not record a program because the CPU needs time to encode something you
> (Nuppel) recorded two weeks ago?

Obviously, recording something _should_ be more important than reencoding.  Do 
you think that spawning off a re-encode process reniced to lowest priority 
would impact a recording that much?  I'm thinking the biggest impact is going 
to be to harddrive speed, and that can be fairly easily fixed by limiting the 
reencode process to a certain number of frames/sec or whatnot.

> 	4. One workaround would be to be build a nice web interface to the Myth
> mysql system, and let all encoding/disc-burning happen on another machine.
> That's nice for performance, but greatly hinders end-user simplicity.

Heh, actually, someone started working on a web interface to the scheduler 
(which would be nice to have).  Of course, he's since stopped and I'm left 
with some half working php.  Would anyone be interested in working with me to 
finish it up?  I just basically need someone with a little more php knowledge 
than me (ie, more than none), and the ability to make it look halfway decent.  
Or any other of the common scripting languages, just the existing code 
(displays a static program grid) is in php.

> 	5. Another option would be to let users burn well identified
> "multi-session" CD's that just contain the raw Nuppel-codec'd video. You'd
> need 1-2 discs per half hour, so the whole thing would be more like an
> offline backup and restore operation than a "watch from disc" way of
> operating.

Yeah, that's kind of a waste of CDs, really.

> 	The knee jerk reaction is, of course, to allow all of the above. But, if
> Myth is ever (eventually) going to get taken seriously, then the end-user
> options need to be constrained. This is not about power hacking, it's about
> controlling streaming media with a remote that only has 20 or so buttons.

'zactly.

> 	I am happy to work on the logic that would extend mythfrontend to the
> point where it understands its computational (as well as time slot)
> constraints, but I'm interested in feedback w.r.t whether this is a good
> idea before I plunge in.

If you think it's needed, go for it, but I'd think testing a secondary encode 
process appropriately rate-limited and re-niced would be the way to go first.

Isaac