[mythtv] Mythvideo DVD ripping

[Lawrence Rust]

On Mon, 2011-05-09 at 17:20 -0400, Raymond Wagner wrote:
> 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
> > transcoding.
> 
> 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.

AFAIK copying an encrypted DVD block by block and thereby preserving the
encryption is acceptable use for backup purposes, However. creating a
decrypted iso image is not.

The current dvdrip could easily be adapted to only offer iso image
copying

>   The 
> utility would have to be backgrounded, either with a widget displaying 
> the progress, or with a popup that notified a user upon completion.

This is the current state.

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

Given that it's already implemented that way then a daemon is no
disadvantage.


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

This change could be made to the current code.

> >>    Then the above wouldn't be necessary and
> >> we could complete the transition to SG-only videos.

Modifying dvdrip to store in a SG is not too difficult.

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

Agreed, writing a fuse or nbd handler is not productive and restricts
the solution to Linux.

What about modifying the SG code so that an iso image is mounted as a
loop device, thereby allowing libdvdcss to do its work during read and
then presenting myth: protocol clients with the component files?

-- 
Lawrence