[lug] dvd::rip and transcode

[John Hernandez]

He's ripping and encoding, not burning.  In this case, Ed's comments 
about nice level are on target.  When it comes time to burn, yes, 
priority and kernel latency can play a significant role.

Back to the original question- in the audio world, the speed of the 
ripping operation has lots to do with the level of "paranoia" (error 
correction) used and the speed and jitter properties of the drive.  In 
DVD-Video land, I think it's mostly a function of audio/video 
synchronization paranoia.  I *believe* the raw video data is reliably 
read from the disc.  Can anyone confirm?

D. Stimits wrote:
> Ed Hill wrote:
> 
>>On Tue, 2002-05-14 at 17:11, D. Stimits wrote:
>>
>>>j davis wrote:
>>>
>>>>has been running for 13 hours and claming another 15 is still needed. Is
>>>>this normal?
>>>>dvd::rip and transcode are also deinterlacing and running "nice 10". Is it
>>>>the nice 10 that is killing me? I have looked at the chapters that are
>>>>already done...look good and they work!
>>>
>>>Can't say for sure, but you are doing cpu-intense work, and telling it
>>>to offer almost no cpu time to the task. With audio/video, you would
>>>actually be risking gaps if the app doesn't know how to deal with it.
>>>I'd be tempted to run it at -1, and just try it out.
>>
>>I don't do dvd ripping so I have no idea what typical times are...
>>
>>However, I can say that if you have only *one* cpu-bound process running
>>on your system then the priority will have a negligible effect on the
>>cumulative time it takes the process to complete.  So ignore Dan's
>>advice.  Go ahead and run your ripper with normal or even nice-ed
>>priority.  If you are simultaneously using the machine for interactive
>>tasks (email, web browsing, whatever), then running the process with a
>>lower priority (as you did) is generally a good idea as it will tend to
>>improve system responsiveness for interactive tasks.
> 
> 
> When it comes to audio and video (realtime with lots of data bandwidth),
> there can be a problem without the preemption and low latency patches
> (unless you run SMP). The reason I suggest a -1 is not just in hope of
> getting a bit more cpu time, but also to give it a bit higher priority
> in the amount of time the cpu spends away, time during which buffers
> fill or empty (which reminds me, perhaps the app has configurable buffer
> size). Imagine that you get a steady number of regular context switches
> that regularly deal with whatever is in a buffer, before it fills, and
> always starting its new cycle with at least some data in the buffer,
> versus the same total time, in which the buffer sits there filled or
> empty during longer bursts of time. The guys on audio dev list would
> probably think it is nuts to burn audio at a nice of 10 and no
> preemption or low latency patch.
> 
> 
>>The reason why priority has essentially no effect in this case is
>>because, given just only one cpu-bound process, there is no significant
>>competition for the cpu cycles.
> 
> 
> It isn't always about cpu cycles, but it isn't worth talking about. All
> it takes is a test burn to see if there is any difference.
> 
> D. Stimits, stimits at idcomm.com
> 
> 

-- 

   - John Hernandez - Network Engineer - 303-497-6392 -
  |  National Oceanic and Atmospheric Administration   |
  |  Mailstop R/OM12. 325 Broadway, Boulder, CO 80305  |
   ----------------------------------------------------