[mythtv] Mythvideo DVD ripping
lvr at softsystem.co.uk
Tue May 10 19:18:18 UTC 2011
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
> 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
> 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?
More information about the mythtv-dev