[mythtv] Mythvideo DVD ripping
raymond at wagnerrp.com
Mon May 9 21:20:17 UTC 2011
On 5/9/2011 16:42, Lawrence Rust wrote:
> On Mon, 2011-05-09 at 10:27 -0700, Robert McNamara wrote:
>> I also have long been unhappy with the "spawn all sorts of external
>> command line utilities" method of DVD ripping, and had hoped to
>> restore DVD ripping with a much simpler approach that used a
>> library/API-based method, but haven't been satisfied with what I've
>> seen there either.
> There is one great advantage with an external daemon for ripping -
> parallelism. Without that, when a user exits mythvideo (as is the case
> with mythmusic) then the ripper thread is deleted. Using an external
> process allows the overlap of ripping (which can take minutes) with more
> rewarding activities - TV/video, browsing, slide show, screen saver
> visuals etc. And on return, the latest rip status is shown. It is a
> moot point if/when mythfrontend exits then the ripper daemon should also
> exit too, crashes excluded ;-)
> Conversion to use an in-process transcoding library (like ffmpeg) isn't
> that difficult, but given that a number of utilities already exist to
> convert one file format to another then why bother? The overhead of
> process creation/destruction is insignificant compared with the
Several months ago, another user was interested in re-introducing the
DVD ripping capability. The suggestion for what would be accepted would
be a very simple utility that did nothing but rip the DVD directly to a
decrypted ISO, and insert it into the MythVideo tables as-is. The
utility would have to be backgrounded, either with a widget displaying
the progress, or with a popup that notified a user upon completion.
The ripping process would not take more than a few minutes, and the user
would only have to keep mythfrontend open. In that event, there would
be no advantage of using an external daemon. Transcoding would not be
part of the ripping process at all, but the user could optionally run a
user job through the jobqueue to transcode as they saw fit.
>> Then the above wouldn't be necessary and
>> we could complete the transition to SG-only videos.
> Let's turn this on its head - why can't the myth: protocol become a
> proper OS device? Then libdvdcss would support it directly.
One of the devs worked up something similar to this a few years back.
He had a Sony DVD turntable hooked up to his backend, and added some
protocol commands to select the proper disk, and share it using NBD.
The block device was subsequently mounted on the frontend, and played
just as a local optical disk. The problem is mounting. Doing so
requires root privileges, or sudo set up with the password requirements
removed. If we want to use the existing myth:// protocol, we either
need to write a FUSE implementation, or a new kernel module, to support
While the code itself may be simpler, it would result in a significantly
more complex setup on the part of the user to get the system working,
which goes against the entire purpose of storage groups and streamed videos.
More information about the mythtv-dev