VCS 1.12.2 released

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:


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/

4 thoughts on “VCS 1.12.2 released

  1. Dean says:

    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

  2. Toni says:

    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.

  3. Dean says:

    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

  4. Toni says:

    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 :)

Comments are closed.


Please note: New comments won't appear immediately, they have to be manually approved (usually done quickly).