Another minor update, although the last few versions have contained a really stupid bug that prevented the temporary files from being removed (leading to a lot of stale, possibly big, files), so upgrading is highly recommended. Thanks to Jason Tackaberry for pointing the bug.
Note though I'm still on holidays so this is a quick and dirty release (with little testing).
Changes:
- Bugfix: Fix cleanup of temporary files (regression introduced in 1.11.2)
- New configuration variables: fg_all, bg_all, font_all and nonlatin_filenames.
- Identification of VP8 video codec (WebM)
- Initial manpage (work in progress)
- vcs 1.12.2
- http://p.outlyer.net/vcs/files/vcs-1.12.2.gz (script only)
or
http://p.outlyer.net/vcs/files/vcs-1.12.2.tar.gz (script, sample configuration, manpage and profiles) - deb, rpm, PKGBUILD & bz2
- as usual at http://p.outlyer.net/vcs/
Discover more from OutlyerNet
Subscribe to get the latest posts to your email.
Hi Toni,
Thanks for this script, it's useful AND educational!
Couple of things; First, is there a typo on line 1075 in the "hash_string" function?
hv=$(( ( ( $hv << 1 ) + $c ) % $HASH_LIMIT ))
…Emacs thinks that everything after the "<<" is a "here document delimiter". If it's correct as is, i'd like to learn its purpose and possibly fix emacs accordingly.
Second, my dvd-drive is useless atm, but i remember previously piping dvd-ouput from mplayer into ffmpeg via a fifo and finding the info generated to be much better than mplayer-alone – for one thing, it won't 'downmix' 6-channel audio automatically. Don't know if that would be useful to you. The syntax was something like:-
mkfifo piped.vob &&
mplayer dvd:// -dumpstream -dumpfile piped.vob & \
ffmpeg -i piped.vob
…See what you think…
Dean
Hi Dean, thanks for your input.
The line you mention is correct although I guess the nested parentheses make it hard to parse.
Emacs is assuming the '<<' starts a heredoc but the '$(( … ))' parentheses are bash's mathematical operator, so what's inside is actually a math operation and not some text.
The '<< 1' in this context means "shift left by one bit". In case you've never seen it, it is a funky way some crazy programmers like me might use to multiply by 2, i.e. "$hv << 1" is equivalent to "$hv * 2". It also means the rightmost bit in the number becomes 0 which is why it's used often in hashing functions (although not in the way I use it).
As for the mplayer+ffmpeg DVD parsing, thanks for the idea, on first look I think I'll be able to use it 🙂
Again, thanks for your input and don't hesitate to ask / suggest anything else.
Thanks for the reply Toni,
"…The '<< 1' in this context means 'shift left by one bit'…"
Ahh, of course! I only looked it up on the 'Advanced Bash Scripting Guide' _INDEX_ page, and apparently they overlooked that usage there. Thanks for the clarification. 😉
I've actually been planning some 'bit-banging' of my own lately, so as to swap the field-order in 'd2v-files' used by 'Avisynth' (through 'Wine'), so i should have realised…
The main reason i started digging into your script was to try to modify it to deal with 'anamorphic' video, which includes _ALL_ DVD's as well as any rips made with 'PAR' honoured (like my own x264-encodes). Besides the actual screenshot-resolution being incorrect as things stand, the 'Dimensions' listed in the header also need consideration – atm all PAL-DVD's are listed as 720×576 and all NTSC-ones as 720×480, without honouring the disc's programmed 'display-aspect-ratio', 4:3 or 16:9.
Calculating the correct 'display' width is easy enough – it's either 'frame-width * PAR' or 'frame-height * DAR', but some of those variables appear to only be available through ffmpeg, as is the ability to scale the screenshots as they're taken with the '-s' option (i just realised mplayer might be able to do scaling too, but i haven't tried yet)…
I'd be interested to hear your thoughts on the subject.
On an unrelated note, i have an idea on how to get rid of GNU-getopt, but it might need a long explanation, and this post is too long already, so if you'd like to hear it 'off-site', you have my email-address, or i could post it here at a later date…
Dean
Hmm, anamorphic video should be handled correctly with aspect ratio honored in the capture size, I think I'm not ignoring PAR though, and only paying attention to DAR. But it does work right in my tests.
Be sure you're not using the '
--autoaspect' option by the way, since it hardwires 4/3 aspect ratio for DVD dimensions.Yep, as far as I know mplayer shows a single "aspect ratio" which is the aspect ratio at which the video would be played (i.e. DAR). PAR and DAR in ffmpeg can become quite puzzling since, I guess, both the container and video stream can be reported simulatenously.
mplayer can scale with the appropriate options (i.e. "
-vf scale=640:480").As for the reported dimensions, it displays the video dimensions (actual pixels) not the playback dimensions, which I think is the way to go, since in this context I don't think it matters if the pixels are square or not. If it displayed e.g. 1024×576 for widescreen PAL DVDs it would be lying since 304 of these pixels would be virtual (conversely if reporting 720×405, 171 pixels would be lost in translation). That's just my way of thinking.
I'm sending you an email about the getopt stuff 🙂