Home : Linux :
Multimedia
On this page:
Xine and Mplayer - Audio/video players
GeeXboX - Small multimedia OS
LIRC - Remote contols
Ripping and Transcoding - Smaller audio/video files
Joining avi files - Stitching together multiple videos.
Playing Music with the CLI - Music without X
Xine and Mplayer - Audio/video players
GeeXboX - Small multimedia OS
LIRC - Remote contols
Ripping and Transcoding - Smaller audio/video files
Joining avi files - Stitching together multiple videos.
Playing Music with the CLI - Music without X
youtube-dl mp4
youtube-dl is a CLI tool for downloading YouTube videos. The default $youtube-dl video_url command just downloads the best video, regardless of format (e.g. .webm which my player cannot play). The download could be large and involve separate video and audio files which are then merged (time consuming). The following are some options (-f ...) for downloading mp4 videos.
Best, single file, mp4 video - 1280x720/192k, if available
$ youtube-dl -f mp4 video_url
Best, merged mp4 video/m4a audio - 1080p/128k, if available
$ youtube-dl -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4' video_url
It looks like 18 (640x360) and 22 (1280x720) are the only mp4 single file options. The following gives the lower resolution priority (-f 22/18 would be the same as -f mp4). I'm not sure how useful this would be, how often only the higher resolution would be available.
$ youtube-dl -f 18/22 video_url
merged mp4 video/m4a audio options:
mp4 video: 160/192p, 133/240p, 134/360p, 135/480p, 136/720p, 137/1080p
m4a audio: 139/48k, 140/128k
If you know what's available, you can pick and download, e.g. 720p and 128k:
$ youtube-dl -f 136+140 video_url
...While the single file options can be prioritized with slash separated options, they don't work when you want to download and merge separate video and audio files. You can download prioritized files, e.g. -f 136/137/135,140/139, but they won't get merged. Using -f 136/137/135+140/139 only downloads the video file. It seems like prioritization should work here, but I haven't figured out how.
Another approach is to limit the earlier bestvideo to a maximum resolution, e.g.480p, and accept any lower resolution ([height<=480]):
$ youtube-dl -f 'bestvideo[height<=480][ext=mp4]+bestaudio[ext=m4a]' video_url
[ comment | link | top ]
Best, single file, mp4 video - 1280x720/192k, if available
$ youtube-dl -f mp4 video_url
Best, merged mp4 video/m4a audio - 1080p/128k, if available
$ youtube-dl -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4' video_url
It looks like 18 (640x360) and 22 (1280x720) are the only mp4 single file options. The following gives the lower resolution priority (-f 22/18 would be the same as -f mp4). I'm not sure how useful this would be, how often only the higher resolution would be available.
$ youtube-dl -f 18/22 video_url
merged mp4 video/m4a audio options:
mp4 video: 160/192p, 133/240p, 134/360p, 135/480p, 136/720p, 137/1080p
m4a audio: 139/48k, 140/128k
If you know what's available, you can pick and download, e.g. 720p and 128k:
$ youtube-dl -f 136+140 video_url
...While the single file options can be prioritized with slash separated options, they don't work when you want to download and merge separate video and audio files. You can download prioritized files, e.g. -f 136/137/135,140/139, but they won't get merged. Using -f 136/137/135+140/139 only downloads the video file. It seems like prioritization should work here, but I haven't figured out how.
Another approach is to limit the earlier bestvideo to a maximum resolution, e.g.480p, and accept any lower resolution ([height<=480]):
$ youtube-dl -f 'bestvideo[height<=480][ext=mp4]+bestaudio[ext=m4a]' video_url
[ comment | link | top ]
Playing Music with the CLI
While I prefer xine for playing videos and music, I wanted a way to play music without needing to have X running (24/7 low power server). I wasn't able to get xine to work without X, apparently I'd have to give up xine-ui.
13 Command Line Tools for Audio on Linux got me started. I'm currently trying mp3blaster and mplayer. Mp3blaster takes less system resources and has a text interface with plenty of options. Mplayer has no visual interface but has plenty of keyboard and remote control (lirc) options. I got the following mplayer playback ideas from one of the article commnets.
$ ls *.mp3 | mplayer -shuffle -playlist - > /dev/null
will work on a directory of mp3's. I've been using
$ find /path/to/music | mplayer -shuffle -playlist - > /dev/null
to get multiple directory playlists. While playback is fine, mplayer will spit out "Seek failed" messages for the odd images and directory names that find sends it... adding -msglevel all=-1 removes all mplayer chatter.
Since my remote is setup with common xine and mplayer buttons, and all I really care about is volume and skipping tracks, I don't mind the lack of a visual interface. Time will tell
...Since my collections are in numerical 1GB collections for my mp3 players, the mplayer setup has worked well. I 'up arrow' on the CLI and change the number to get a new collection to play. 1GB is good for a days worth of tunes.
Interesting aside on system usage
Xine-ui (X)
User%: 18-21
VmS kB: 229,623
VmR kB: 29,964
Mplayer (CLI)
User%: 2.0-2.5
VmS kB: 52,708
VmR kB: 9,032
Mp3blaster (CLI)
User%: 1.5-2.0
VmS kB: 33,108
VmR kB: 3,208
...CLI video: $ ls ~/Video/*.avi | mplayer -fs -playlist - > /dev/null
[ comment | link | top ]
13 Command Line Tools for Audio on Linux got me started. I'm currently trying mp3blaster and mplayer. Mp3blaster takes less system resources and has a text interface with plenty of options. Mplayer has no visual interface but has plenty of keyboard and remote control (lirc) options. I got the following mplayer playback ideas from one of the article commnets.
$ ls *.mp3 | mplayer -shuffle -playlist - > /dev/null
will work on a directory of mp3's. I've been using
$ find /path/to/music | mplayer -shuffle -playlist - > /dev/null
to get multiple directory playlists. While playback is fine, mplayer will spit out "Seek failed" messages for the odd images and directory names that find sends it... adding -msglevel all=-1 removes all mplayer chatter.
Since my remote is setup with common xine and mplayer buttons, and all I really care about is volume and skipping tracks, I don't mind the lack of a visual interface. Time will tell
...Since my collections are in numerical 1GB collections for my mp3 players, the mplayer setup has worked well. I 'up arrow' on the CLI and change the number to get a new collection to play. 1GB is good for a days worth of tunes.
Interesting aside on system usage
Xine-ui (X)
User%: 18-21
VmS kB: 229,623
VmR kB: 29,964
Mplayer (CLI)
User%: 2.0-2.5
VmS kB: 52,708
VmR kB: 9,032
Mp3blaster (CLI)
User%: 1.5-2.0
VmS kB: 33,108
VmR kB: 3,208
...CLI video: $ ls ~/Video/*.avi | mplayer -fs -playlist - > /dev/null
[ comment | link | top ]
Joining avi files
Sometimes movies are split into parts and you want to join them... I prefer transcode for this and for ripping/transcoding.
Transcode seems to be the easiest way (credit)... To prevent possible sync issues I've added the -c switch... now removed, it seems to cause more problems than it solves. Try memcoder if the resulting file is out of sync (see last link).
avimerge -i in1.avi in2.avi -o out.avi
$ man avimerge
"avimerge is a versatile tool. It can contatenate several AVI files
into one. It can also be used to fix an index of a broken file and can
also replace audio tracks or muxes new ones. It can read raw AC3 and
MP3 files for multplexing."
Using mencoder looks relatively complicated (another article), but it seems to get a lot more coverage.
cat in1.avi in2.avi > out_tmp.avi
mencoder -forceidx -oac copy -ovc copy out_tmp.avi -o out.avi
Basically the same info. Differences are wildcard join and -noidx VS -forceidx.
cat in* > out_tmp.avi
mencoder -noidx -oac copy -ovc copy out_tmp.avi -o out.avi
...Yet another option. This is the simplest and most similar to the avimerge command.
mencoder -oac copy -ovc copy in1.avi in2.avi -o out.avi
Converting mkv to avi
Quick, quality not very good, slightly bigger out.avi:
mencoder in.mkv -o out.avi -ovc lavc -oac mp3lame
Much slower, pretty good quality, smaller out.avi:
mencoder in.mkv -o out.avi -ovc xvid -xvidencopts fixed_quant=4 -oac mp3lame
[ comment | link | top ]
Transcode seems to be the easiest way (credit)... To prevent possible sync issues I've added the -c switch... now removed, it seems to cause more problems than it solves. Try memcoder if the resulting file is out of sync (see last link).
avimerge -i in1.avi in2.avi -o out.avi
$ man avimerge
"avimerge is a versatile tool. It can contatenate several AVI files
into one. It can also be used to fix an index of a broken file and can
also replace audio tracks or muxes new ones. It can read raw AC3 and
MP3 files for multplexing."
Using mencoder looks relatively complicated (another article), but it seems to get a lot more coverage.
cat in1.avi in2.avi > out_tmp.avi
mencoder -forceidx -oac copy -ovc copy out_tmp.avi -o out.avi
Basically the same info. Differences are wildcard join and -noidx VS -forceidx.
cat in* > out_tmp.avi
mencoder -noidx -oac copy -ovc copy out_tmp.avi -o out.avi
...Yet another option. This is the simplest and most similar to the avimerge command.
mencoder -oac copy -ovc copy in1.avi in2.avi -o out.avi
Converting mkv to avi
Quick, quality not very good, slightly bigger out.avi:
mencoder in.mkv -o out.avi -ovc lavc -oac mp3lame
Much slower, pretty good quality, smaller out.avi:
mencoder in.mkv -o out.avi -ovc xvid -xvidencopts fixed_quant=4 -oac mp3lame
[ comment | link | top ]
Ripping and Transcoding
K3b is an easy to use video and audio ripper. Its great for quick and dirty converting of DVD's to xvid or divx and music CD's to mp3 or ogg. dvd::rip is has more options than K3b and is probably more useful if you're serious about ripping DVD's. It seems that both tools are only good when a DVD or CD is the source material. Transcoding a file (e.g. a VOB) that is already on the hard drive is another matter.
My bottom line solution is:
transcode -i [input vob] -o [output.avi] -y xvid -x vob -Z 624x -a 1 -w 1800
or 2-pass (1000 2-pass != 1800 1-pass, just experimenting)
transcode -i [input vob] -R 1 -y xvid -x vob -Z 624x -a 1 -w 1000
transcode -i [input vob] -R 2 -o [output.avi] -y xvid -x vob -Z 624x -a 1 -w 1000
Replace the brackets with full paths (or filenames if you run it from the source/destination directory). 1800 kbps is the default, 1000 looks good, I wouldn't go less than 800. You could also change the resize width (624) but keep it divisible by 8. The rest of the article was written as I experimented/learned (using VTS_02_5.VOB as input and movie.avi as output).
Transcode
A quick search turned up TIP Transcode Examples. Without reading the page I tried the following to convert a 274.6MB 720x480 vob to xvid.
transcode -a 0 -b 128,0,0 -i VTS_02_5.VOB -w 1800,250,100 -A -N 0x2000 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 1 -x vob -y xvid4,null
transcode -a 0 -b 128,0,0 -i VTS_02_5.VOB -w 1800,250,100 -A -N 0x2000 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 2 -x vob -y xvid4 -o movie.avi
The first command/pass creates a log that should produce a higher quality output with the second command/pass. The result is a 85MB 624 x 464 24fps xvid/dvm (ac3?)
Some definite inconsistency here. Mplayer plays the source squished top/bottom and plays the output fine. Xine plays the source fine but plays the output squished from the sides. Since both players have an aspect ratio toggle, its not a big deal but doesn't tell me where the problem lies, i.e. the source or the commands (above... the problem is the -B 1,11,8 resize, more later). I'd also prefer mp3 to ac3 for the audio. Anyway, I'm basically clueless at this point but it was nice to see a good quality (less than 1/3 the size of the source) working output from the above commands.
...Switches used (defaults): -M 2 is the transcode "NTSC VOB stream synchronization feature", -Y 4,4,4,4 means to clip 4px from each edge of the video, -R 1 VBR video 1st pass, -R 2 VBR 2nd pass, -a 0 don't extract audio (0/1 false/true), -b 128,0,0 audio bitrate kbps (-a1 vob > xvid/mp3 is 128 by default, i.e. no -b needed), vbr (0/1?, 0 is default), quality (0-5?, 5 is default), mode (0: joint stereo/default, 1: full stereo, 2: mono), -w 1800,250,100 bitrate (6000 for mpeg 1/2 and 1800 for the rest), keyframes (250), crispness (100)
From Tiny Linux / Unix Commandos
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800
results in a 79.8MB 720 (source width, no resize) x 352 (128px smaller) 24fps xvid/mp3.
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800 -j 16,0
results in a cropped/clipped 78.5MB 720 x 320 (160px smaller) 24fps xvid/mp3, i.e. 16px (that added -j 16,0) of video is lost from top and bottom
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800 -I1
results in a deinterlaced 80.4MB 720 x 352 24fps xvid/mp3. The 'I' (-I1) is a capitol i and the 1 means interpolate scanlines (there are 4 other ways to do it, #2-5). The source wasn't interlaced so its not surprising that I saw no visual difference in the output.
From DVD to WAV in Linux
transcode -H 10 -a 0 -x vob -i VTS_02_5.VOB -w 9000,50 -b 128,0,2 -s 2.254 --a52_drc_off -f 30,4 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 2 -y xvid -o movie.avi
results in a 97.5MB 624 x 464 29fps (all previous were the more common, for xvid, 24fps) xvid/mp3 with the same aspect weirdness as the first (2-pass) example (its got the same -B 1,11,8 resize parameters). This one has a few switches I haven't looked up... The -R 2 means this is the command for the second pass and that the example is incomplete. While flawed, I don't think removing the -R 2 would change the output.
Mencoder
I used the HOWTO Mencoder Introduction Guide as the basis for the following examples. Compared to transcode, mencoder is way too verbose. Using -quiet is not an ideal solution because there's no sense of progress.
Quality based, fixed_quant=4 (can be 1-31)
mencoder -quiet VTS_02_5.VOB -ovc xvid -oac mp3lame -xvidencopts fixed_quant=4 -o movie.avi
results in a 51.3MB 720 x 480 29fps xvid/mp3
Bitrate based. The transcode examples were 1800, the above HowTo says 800 is close to DVD quality.
mencoder -quiet VTS_02_5.VOB -ovc xvid -oac mp3lame -xvidencopts bitrate=800 -o movie.avi
comes in at 39.3MB so fixed_quant=4 is a bit higher than 800kbps.
Two pass (essentially the same as the Tiny Linux / Unix Commandos mencoder example) is always bitrate based on second pass (cannot be fixed_quant).
mencoder -quiet VTS_02_5.VOB -oac mp3lame -ovc xvid -xvidencopts pass=1 -o /dev/null
mencoder -quiet VTS_02_5.VOB -oac mp3lame -ovc xvid -xvidencopts pass=2:bitrate=800 -o movie.avi
Like the transcode 2-pass, the first pass creates a log that the second pass uses to encode the output avi. The quality seems to be a bit better than the other two and the filesize is essentially the same as the 1-pass @ 800kbps - 40MB. The problem is that they are all 720 x 480 and 29fps which TTBOMK is not standard xvid and they require a lot more system resources to play than the ~624 x 352 @ 24fps (I get frame-drop warnings on playback). There's probably a solution for this and the command line chatter but I'd rather go
Back to Transcode
The earlier
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800
example was simple and the only problem seemed to be the resize. I don't understand what the resize, -B 4, does. Two of the sources/examples have -B 1,11,8 which means source height - 1 x 8 rows and source width - 11 x 8 columns. Rows/columns (the 8) can be multiples of 8,16 or 32 and the default is 32... So -B 4 means source height - 4 x 32 rows, i.e. 480 (source height) - 128 (4 x 32) = 352 (height of output.avi).
Why unbalance/change the aspect ratio? The -B 4 and -B 1,11,8 switches make no sense. Since I've only worked with one VOB, I could be missing something.
The -Z resize switch looks promising so I'll try using it in place of the -B. I'll try specifying a resize width (-Z 624x) and let transcode determine the proper/proportionate height.
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -Z 624x -a1 -w 1800
results in a 73.7MB 624 x 352 24fps xvid/mp3 which is what I was after. It also solves the aspect ratio weirdness. The 624 (-Z 624x) could be any number divisible by 8 and will work with any aspect ratio. '-Z 624x, fast' would also be worth a try.
Lets see what the rest of the command line switches mean. -i is the input file/directory/device/mountpoint/host name, -o is the output file name (since /dev/null is the default there's no need to specify -o on the first of two passes), -y xvid - filetype export module (there are xvid2, xvid3 and xvid4 modules, 'xvid' = xvid4), -x vob - filetype import module, -a1 extract audio (true/1), -w 1800 encoder bitrate (could be dropped as 1800 is the default bitrate for xvid).
[ comment | link | top ]
My bottom line solution is:
transcode -i [input vob] -o [output.avi] -y xvid -x vob -Z 624x -a 1 -w 1800
or 2-pass (1000 2-pass != 1800 1-pass, just experimenting)
transcode -i [input vob] -R 1 -y xvid -x vob -Z 624x -a 1 -w 1000
transcode -i [input vob] -R 2 -o [output.avi] -y xvid -x vob -Z 624x -a 1 -w 1000
Replace the brackets with full paths (or filenames if you run it from the source/destination directory). 1800 kbps is the default, 1000 looks good, I wouldn't go less than 800. You could also change the resize width (624) but keep it divisible by 8. The rest of the article was written as I experimented/learned (using VTS_02_5.VOB as input and movie.avi as output).
Transcode
A quick search turned up TIP Transcode Examples. Without reading the page I tried the following to convert a 274.6MB 720x480 vob to xvid.
transcode -a 0 -b 128,0,0 -i VTS_02_5.VOB -w 1800,250,100 -A -N 0x2000 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 1 -x vob -y xvid4,null
transcode -a 0 -b 128,0,0 -i VTS_02_5.VOB -w 1800,250,100 -A -N 0x2000 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 2 -x vob -y xvid4 -o movie.avi
The first command/pass creates a log that should produce a higher quality output with the second command/pass. The result is a 85MB 624 x 464 24fps xvid/dvm (ac3?)
Some definite inconsistency here. Mplayer plays the source squished top/bottom and plays the output fine. Xine plays the source fine but plays the output squished from the sides. Since both players have an aspect ratio toggle, its not a big deal but doesn't tell me where the problem lies, i.e. the source or the commands (above... the problem is the -B 1,11,8 resize, more later). I'd also prefer mp3 to ac3 for the audio. Anyway, I'm basically clueless at this point but it was nice to see a good quality (less than 1/3 the size of the source) working output from the above commands.
...Switches used (defaults): -M 2 is the transcode "NTSC VOB stream synchronization feature", -Y 4,4,4,4 means to clip 4px from each edge of the video, -R 1 VBR video 1st pass, -R 2 VBR 2nd pass, -a 0 don't extract audio (0/1 false/true), -b 128,0,0 audio bitrate kbps (-a1 vob > xvid/mp3 is 128 by default, i.e. no -b needed), vbr (0/1?, 0 is default), quality (0-5?, 5 is default), mode (0: joint stereo/default, 1: full stereo, 2: mono), -w 1800,250,100 bitrate (6000 for mpeg 1/2 and 1800 for the rest), keyframes (250), crispness (100)
From Tiny Linux / Unix Commandos
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800
results in a 79.8MB 720 (source width, no resize) x 352 (128px smaller) 24fps xvid/mp3.
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800 -j 16,0
results in a cropped/clipped 78.5MB 720 x 320 (160px smaller) 24fps xvid/mp3, i.e. 16px (that added -j 16,0) of video is lost from top and bottom
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800 -I1
results in a deinterlaced 80.4MB 720 x 352 24fps xvid/mp3. The 'I' (-I1) is a capitol i and the 1 means interpolate scanlines (there are 4 other ways to do it, #2-5). The source wasn't interlaced so its not surprising that I saw no visual difference in the output.
From DVD to WAV in Linux
transcode -H 10 -a 0 -x vob -i VTS_02_5.VOB -w 9000,50 -b 128,0,2 -s 2.254 --a52_drc_off -f 30,4 -M 2 -Y 4,4,4,4 -B 1,11,8 -R 2 -y xvid -o movie.avi
results in a 97.5MB 624 x 464 29fps (all previous were the more common, for xvid, 24fps) xvid/mp3 with the same aspect weirdness as the first (2-pass) example (its got the same -B 1,11,8 resize parameters). This one has a few switches I haven't looked up... The -R 2 means this is the command for the second pass and that the example is incomplete. While flawed, I don't think removing the -R 2 would change the output.
Mencoder
I used the HOWTO Mencoder Introduction Guide as the basis for the following examples. Compared to transcode, mencoder is way too verbose. Using -quiet is not an ideal solution because there's no sense of progress.
Quality based, fixed_quant=4 (can be 1-31)
mencoder -quiet VTS_02_5.VOB -ovc xvid -oac mp3lame -xvidencopts fixed_quant=4 -o movie.avi
results in a 51.3MB 720 x 480 29fps xvid/mp3
Bitrate based. The transcode examples were 1800, the above HowTo says 800 is close to DVD quality.
mencoder -quiet VTS_02_5.VOB -ovc xvid -oac mp3lame -xvidencopts bitrate=800 -o movie.avi
comes in at 39.3MB so fixed_quant=4 is a bit higher than 800kbps.
Two pass (essentially the same as the Tiny Linux / Unix Commandos mencoder example) is always bitrate based on second pass (cannot be fixed_quant).
mencoder -quiet VTS_02_5.VOB -oac mp3lame -ovc xvid -xvidencopts pass=1 -o /dev/null
mencoder -quiet VTS_02_5.VOB -oac mp3lame -ovc xvid -xvidencopts pass=2:bitrate=800 -o movie.avi
Like the transcode 2-pass, the first pass creates a log that the second pass uses to encode the output avi. The quality seems to be a bit better than the other two and the filesize is essentially the same as the 1-pass @ 800kbps - 40MB. The problem is that they are all 720 x 480 and 29fps which TTBOMK is not standard xvid and they require a lot more system resources to play than the ~624 x 352 @ 24fps (I get frame-drop warnings on playback). There's probably a solution for this and the command line chatter but I'd rather go
Back to Transcode
The earlier
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -B 4 -a1 -w 1800
example was simple and the only problem seemed to be the resize. I don't understand what the resize, -B 4, does. Two of the sources/examples have -B 1,11,8 which means source height - 1 x 8 rows and source width - 11 x 8 columns. Rows/columns (the 8) can be multiples of 8,16 or 32 and the default is 32... So -B 4 means source height - 4 x 32 rows, i.e. 480 (source height) - 128 (4 x 32) = 352 (height of output.avi).
Why unbalance/change the aspect ratio? The -B 4 and -B 1,11,8 switches make no sense. Since I've only worked with one VOB, I could be missing something.
The -Z resize switch looks promising so I'll try using it in place of the -B. I'll try specifying a resize width (-Z 624x) and let transcode determine the proper/proportionate height.
transcode -i VTS_02_5.VOB -o movie.avi -y xvid -x vob -Z 624x -a1 -w 1800
results in a 73.7MB 624 x 352 24fps xvid/mp3 which is what I was after. It also solves the aspect ratio weirdness. The 624 (-Z 624x) could be any number divisible by 8 and will work with any aspect ratio. '-Z 624x, fast' would also be worth a try.
Lets see what the rest of the command line switches mean. -i is the input file/directory/device/mountpoint/host name, -o is the output file name (since /dev/null is the default there's no need to specify -o on the first of two passes), -y xvid - filetype export module (there are xvid2, xvid3 and xvid4 modules, 'xvid' = xvid4), -x vob - filetype import module, -a1 extract audio (true/1), -w 1800 encoder bitrate (could be dropped as 1800 is the default bitrate for xvid).
[ comment | link | top ]
Xine and MPlayer
I mostly use xine-ui to play all my videos and music. My primary interface is an old Logitech/AST serial remote. I've been favoring xine over mplayer for some time. MPlayer does have a nicer GUI but it doesn't matter much if you only use a remote... One thing I like about xine is that I can right-click on folders or disks (set drive to mount automatically in properties > mounting) and 'play with xine'. Xine will create a playlist and play the folder or disk. While xine does have a OSD menu where you can browse and select a specific track, its not as simple and straightforward as it should be. I prefer using the remotes next/previous 'track' buttons.
Since I had the remote setup from using GeeXboX (MPlayer) it was easy to set it up to work with MPlayer on my desktop OS's. It was fairly easy to add xine bindings and by that point I had no interest in figuring out if I could do anything with Kaffine and other players.
While there is other stuff that belongs here, I've been giving PCLinuxOS a try and it prompted my writing this note about xine drive settings. For some reason, some are missing from the GUI configuration. There's a config file in ~/.xine where you'll find three device settings (scattered about, search for ".device:") and one setting for the DVD mountpoint (menu related).
# device used for playback, e.g./dev/cdrom, dvd, sr0 (my USB DVD)
media.dvd.device:/dev/sr0
media.vcd.device:/dev/sr0
media.audio_cd.device:/dev/sr0
# directory where dvd device media will be mounted, e.g. /dvd,
# /media for mandriva/pclinuxos
gui.osdmenu.dvd_mountpoint:/media
# For (S)VCDs (works better for me)
media.vcd.autoplay:MPEG track
# Custom snapshot folder
# To dismiss (menu show/hide button) the confirmation pop-up with the remote
# you need to have used the menu before taking the first screenshot
gui.snapshotdir:/home/dave/Pictures/Screenshots
Snapshots are another xine plus. Mplayer needs to be configured to even take snapshots (vf=screenshot in config), the snapshots are named shotnnn.png (VS zine video_name-nn.png) and they are placed in the users home directory (not configurable).
When playing videos I like to start xine in full-screen mode and have it quit when the video is finished. Here I use the -p switch, xine -pfq [file] = play full-screen and quit when done. In Konqueror I setup a custom 'open with' association for my video files with "xine -pfq %U" as the command.
Jul '12: VLC is a pain in some ways (file locations and customization), but it has a lot of features. I've been using it mostly to play SD/SR videos over the LAN (http/tcp). It does quite well with mp4's and OK w/ avi's (better than xine w/ remote files).
[ comment | link | top ]
Since I had the remote setup from using GeeXboX (MPlayer) it was easy to set it up to work with MPlayer on my desktop OS's. It was fairly easy to add xine bindings and by that point I had no interest in figuring out if I could do anything with Kaffine and other players.
While there is other stuff that belongs here, I've been giving PCLinuxOS a try and it prompted my writing this note about xine drive settings. For some reason, some are missing from the GUI configuration. There's a config file in ~/.xine where you'll find three device settings (scattered about, search for ".device:") and one setting for the DVD mountpoint (menu related).
# device used for playback, e.g./dev/cdrom, dvd, sr0 (my USB DVD)
media.dvd.device:/dev/sr0
media.vcd.device:/dev/sr0
media.audio_cd.device:/dev/sr0
# directory where dvd device media will be mounted, e.g. /dvd,
# /media for mandriva/pclinuxos
gui.osdmenu.dvd_mountpoint:/media
# For (S)VCDs (works better for me)
media.vcd.autoplay:MPEG track
# Custom snapshot folder
# To dismiss (menu show/hide button) the confirmation pop-up with the remote
# you need to have used the menu before taking the first screenshot
gui.snapshotdir:/home/dave/Pictures/Screenshots
Snapshots are another xine plus. Mplayer needs to be configured to even take snapshots (vf=screenshot in config), the snapshots are named shotnnn.png (VS zine video_name-nn.png) and they are placed in the users home directory (not configurable).
When playing videos I like to start xine in full-screen mode and have it quit when the video is finished. Here I use the -p switch, xine -pfq [file] = play full-screen and quit when done. In Konqueror I setup a custom 'open with' association for my video files with "xine -pfq %U" as the command.
Jul '12: VLC is a pain in some ways (file locations and customization), but it has a lot of features. I've been using it mostly to play SD/SR videos over the LAN (http/tcp). It does quite well with mp4's and OK w/ avi's (better than xine w/ remote files).
[ comment | link | top ]
GeeXboX
The GeeXboX is no more than an awesome standalone media player.
Very nice. Remote controlled multimedia PC (HTPC) made easy.
Oct '07: Looked at using 1.1 and HD dev version. The former doesn't seem to support 1440x900 and the later doesn't seem to support my serial remote ... So I took another look around and discovered FreevoLive (below)... The GeeXbox serial remote bug was an easy fix (change LIRC_MODULES="8250" to LIRC_MODULES="8250|8250_pnp|8250_pci" in lircd_), the HD version is looking OK.
Oct '06: I've removed some out of date ideas/customization and added my last used AST/Logitech lirc files. While I still maintain a GeeXboX box for a friends TV, I'm mainly using Xine on my primary PC (Madriva) for multimedia (19" WS LCD)... '19: Using the same remote on PCLOS with mplayer (the .lircrc has xine and mplayer controls setup)
Files
lircrc_logitech (> ~/.lircrc)
lircd_logitech.conf (> /etc/lirc/lircd.conf)
...also need /etc/sysconfig/lirc w/ DRIVER="logitech" and DEVICE=/dev/ttyS0
Mplayer slave.txt (local)
Nov '07: A LUG poster wanted to setup a kiosk that would loop a single video file. An edited version of my reply:
You could use Geexbox to build a custom CD/DVD/whatever that includes the OS (8.8MB) and your video. Get the iso generator which includes Linux, Mac and Win executables, stick your video in the /iso directory, add loop=0 to /iso/GEEXBOX/etc/mplayer/mplayer.conf, build and burn. Stick the DVD in the drive and boot (set bios to boot from CD). Geexbox will boot and autoplay/loop the video.
--
Other HTPC distro's:
FreevoLive works and looks promising though its a quite big compared to GeeXboX and doesn't support remote controls out of the box. It looks like installing it (a trimmed down Mandriva '07) and adding at least lirc is the only way to really test it (e.g. w/ a remote). It may be a good minimal multimedia Mandriva that can be built into an all purpose system.
Freepia runs on Via Epia-M motherboards.
"LinuxMCE is a free, open source add-on to Kubuntu including a 10' UI, complete whole-house media solution..." This one looks a little bit much, what is a 10' UI?
HTPC programs (not self contained)
LMBOX (not current/active).
Freevo: I've had nothing but grief installing and trying to setup/use this one. See also: FreevoLive (above)
[ comment | link | top ]
Very nice. Remote controlled multimedia PC (HTPC) made easy.
Oct '07: Looked at using 1.1 and HD dev version. The former doesn't seem to support 1440x900 and the later doesn't seem to support my serial remote ... So I took another look around and discovered FreevoLive (below)... The GeeXbox serial remote bug was an easy fix (change LIRC_MODULES="8250" to LIRC_MODULES="8250|8250_pnp|8250_pci" in lircd_
Oct '06: I've removed some out of date ideas/customization and added my last used AST/Logitech lirc files. While I still maintain a GeeXboX box for a friends TV, I'm mainly using Xine on my primary PC (Madriva) for multimedia (19" WS LCD)... '19: Using the same remote on PCLOS with mplayer (the .lircrc has xine and mplayer controls setup)
Files
lircrc_logitech (> ~/.lircrc)
lircd_logitech.conf (> /etc/lirc/lircd.conf)
...also need /etc/sysconfig/lirc w/ DRIVER="logitech" and DEVICE=/dev/ttyS0
Mplayer slave.txt (local)
Nov '07: A LUG poster wanted to setup a kiosk that would loop a single video file. An edited version of my reply:
You could use Geexbox to build a custom CD/DVD/whatever that includes the OS (8.8MB) and your video. Get the iso generator which includes Linux, Mac and Win executables, stick your video in the /iso directory, add loop=0 to /iso/GEEXBOX/etc/mplayer/mplayer.conf, build and burn. Stick the DVD in the drive and boot (set bios to boot from CD). Geexbox will boot and autoplay/loop the video.
--
Other HTPC distro's:
FreevoLive works and looks promising though its a quite big compared to GeeXboX and doesn't support remote controls out of the box. It looks like installing it (a trimmed down Mandriva '07) and adding at least lirc is the only way to really test it (e.g. w/ a remote). It may be a good minimal multimedia Mandriva that can be built into an all purpose system.
Freepia runs on Via Epia-M motherboards.
"LinuxMCE is a free, open source add-on to Kubuntu including a 10' UI, complete whole-house media solution..." This one looks a little bit much, what is a 10' UI?
HTPC programs (not self contained)
LMBOX (not current/active).
Freevo: I've had nothing but grief installing and trying to setup/use this one. See also: FreevoLive (above)
[ comment | link | top ]
LIRC
LIRC is a program that allows you to use remote controls with your computer. It worked so great with GeeXboX I decided to set it up with Mandrake 10.1. What a PITA...All of the stuff I found online had me on the wrong track.
[root@bar foo]# lircd --driver=?
will give you a list of 'out of the box' drivers. If your serial port remote is listed there all you need in /etc/sysconfig/lircd is:
DRIVER=[your remote]
DEVICE=/dev/ttyS0
Copy/rename /usr/share/lirc-remotes/lircd.conf.[your remote] to /etc/lircd.conf (/etc/lirc/lircd.conf if dir exists). If you want mouse functionality do the same with lircmd.conf.[your remote]
Program controls go in ~/. lircrc, e.g.:
begin
prog = mplayer
button = [on your remote]
config = menu up
end
Start the daemons from Control Center > Services or do
[root@bar foo]# service lircd start
[root@bar foo]# service lircmd start
I'm guessing that lirc_serial is in the 2.6 kernel's because the only place I could find it was in 2.4 kernel modules. There are lirc_serial_foo drivers and this page may help if you have a remote that cannot use any of the stock drivers.
To get an LIRC controlled menu in mplayer you need to include -menu
[foo@bar foo]$ mplayer -menu -fs -quiet vcd://
"xine can self generate a lirc entries draft, using 'xine --keymap=lirc', then you can redirect the output to a file to polish the settings."
Files: xine keymap (local)
[ comment | link | top ]
[root@bar foo]# lircd --driver=?
will give you a list of 'out of the box' drivers. If your serial port remote is listed there all you need in /etc/sysconfig/lircd is:
DRIVER=[your remote]
DEVICE=/dev/ttyS0
Copy/rename /usr/share/lirc-remotes/lircd.conf.[your remote] to /etc/lircd.conf (/etc/lirc/lircd.conf if dir exists). If you want mouse functionality do the same with lircmd.conf.[your remote]
Program controls go in ~/. lircrc, e.g.:
begin
prog = mplayer
button = [on your remote]
config = menu up
end
Start the daemons from Control Center > Services or do
[root@bar foo]# service lircd start
[root@bar foo]# service lircmd start
I'm guessing that lirc_serial is in the 2.6 kernel's because the only place I could find it was in 2.4 kernel modules. There are lirc_serial_foo drivers and this page may help if you have a remote that cannot use any of the stock drivers.
To get an LIRC controlled menu in mplayer you need to include -menu
[foo@bar foo]$ mplayer -menu -fs -quiet vcd://
"xine can self generate a lirc entries draft, using 'xine --keymap=lirc', then you can redirect the output to a file to polish the settings."
Files: xine keymap (local)
[ comment | link | top ]