> Date: Fri, 20 Jun 2014 02:12:41 +0100
> From: Ken Moffat <[email protected]>
> To: BLFS Support List <[email protected]>
> Subject: Re: [blfs-support] vlc - anybody got encoded DVDs to play properly ?
>
> On Thu, Jun 19, 2014 at 09:06:22AM +0100, akhiezer wrote:
> > 
> > A few possibly useful handles:
> > --
> > * Do the problems exist if you run vlc as root?
> > 
> root@ac4tv /home/ken #vlc
> VLC is not supposed to be run as root. Sorry.


(Heh, there's a patch for that ... ; fwits.)


> If you need to use real-time priorities and/or privileged TCP ports
> you can use vlc-wrapper (make sure it is Set-UID root and
> cannot be run by non-trusted users first).
>
> > * Do the problems basically not exist if you use xine for the various 
> > tests/tasks?
>
> Correct - provided that /dev/sr0 has a DVD symlink and is writable
> by my a group my user is in - I seem to have lost or broken the
> workaround I used to use for that [ I do not play DVDs very often ]


Does the likes of strace'ing vlc show what it's sticking at?


( Wasn't the alternative/workaround for xine s'thing like telling xine to
use the 'real' device directly; but with some drawbacks or at least extra
steps needed re some device settings.
(( We long ago dd'd all cd/dvd here onto hard-drives: tho', the ol'
plextor optical drives still work fine - they get used to, again, dd any
(increasingly infrequent) cd/dvd media that shows up here and that 's not
really practical/politic to get in alternative media.
))
)


> > 
> > * Have you looked at how other folks build vlc (I kindof guess yes): e.g.:
> >     ==
> >     http://www.slackware.com/~alien/slackbuilds/vlc/build/vlc.SlackBuild
> >     http://www.slackware.com/~alien/slackbuilds/vlc/build/
> >     ==
>
>  I haven't looked at those, for the moment - I use BLFS-based


Wasn't meaning them as mutually-exclusive, but rather the slackware info as an 
additional input stream to what you draw on to design builds. And in the first 
instance, at least/most, is there anything that jumps-out that one might be 
doing differently and might be the (part-)cause of the problems.


> instructions.  I might take a look later, because I've just decided


(Although it may look like a lot and perhaps a bit complex, much of the 
'vlc.SlackBuild' content is 'just' function-defines for builds of deps; it's 
fairly 'clean', just lots of details - usual video stuff.)


> that I _do_ want to keep vlc : it is a better way of looking at my
> work-in-progress movie edits than parole, i.e. scrolling works
> reliably, and it is more capable than xine.  Thanks anyway.
>
>  After two days of intermittent banging my head against a keyboard /
> googling / cursing, I have now got a process of preparing the
> individual clips with ffmpeg to a position where it might be usable.
> I do start to wonder if the time might have been better used looking
> at python-based video editors (I tried avidemux last week, but the
> audio is b0rken for me with alsa, and the python deps for other
> editors looked horrendous - details appear to be in gentoo).
>


(Yeah, although cmdline tools can take some learning - mainly re the array
of video/audio options available - I'd say it's overall a better and more
'learning-ful' path than black-box editors.)


>  I have now cut a 42.5s .mov clip to exactly 42s, and created a 42s
> x264 mp4 video with fade from/to black at the ends (the audio is a
> little longer, and ffmpeg cannot fade it), separated the audio to a
> wav file and used sox to fade that in/out, and then combined them.
>
>  The obvious combination would be to convert the audio to aac in an
> mp4 file, but when I do that the audio becomes 128ms longer than the
> video.  I expect to use parhaps 10 clips to make the complete video,
> so by the end the sound would be out of sync.
>
>  What I have done for now is to keep the audio as .wav, and called
> it a .mkv file because it clearly isn't mp4.  Xine only plays the
> video from this.  The benefit of this is that the although even the
> video has now grown by 67ms, the audio has only grown by 69ms so the
> relative loss of sync is 2ms for this clip.
>
>  Still need to do similar things to at least one other clip (but
> I think I now understand the process, and on a good day I can
> remember how the ffmpeg options fit together), and prepare at least a
> title image, then I will find out if I can successfully convert it
> all to mp4 and upload it to youtube : for the moment, I am sort-of
> expecting that to fail, in which case I will be in mega-sulk mode in
> a few days :-(
>


Ever included mplayer/mencoder in the workflow?


rgds,
akh



> ??en


--
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to