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.
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?
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.
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.
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.
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.
BR,
Thor
--
----------------------------------------------------------------
Thor Sigvaldason <thor@sigvaldason.com>
For my PGP/GnuPG public key, send an e-mail to thorskey@sigvaldason.com
----------------------------------------------------------------
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.
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?
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.
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.
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.
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.
BR,
Thor
--
----------------------------------------------------------------
Thor Sigvaldason <thor@sigvaldason.com>
For my PGP/GnuPG public key, send an e-mail to thorskey@sigvaldason.com
----------------------------------------------------------------
