[mythtv] Thoughts on CD/VCD/SVCD burning

[Thor Sigvaldason]

On Friday 23 August 2002 11:01 am, you wrote:
> 
> >
> > 	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.
>

	It's pretty straightforward.

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

	I guess this probably the way to go. The burning menu would have to have a 
"Convert Video" option that would let you move content to suitable formats 
and would operate very low niced, etc. If there's nothing converted, then 
there's nothing to burn. Still .... it just seems a bit cumbersome. Select 
"convert", check back periodically over the course of an hour(s), see that 
it's finally ready and then burn.

	Perhaps there could be a column in the database (with a toggle control on 
the interface) that let's users select whether they'll want to be burning 
this particular content at some point. Then, as soon as the original 
recording is over, the mpeg encoding could spawn in the background.

	This would be much easier for people who are grabbing a whole series and 
know in advance that they'll want to burn it. Just a thought.

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

	Send me that. Me and apache+php+mysql go way back  :-)

BR,

Thor


-- 
----------------------------------------------------------------
Thor Sigvaldason <thor@sigvaldason.com>
For my PGP/GnuPG public key, send an e-mail to thorskey@sigvaldason.com
----------------------------------------------------------------