All Projects

Due to the use of ~ in the revision tag

finger is not installed/enabled by default in at least FC12. Replace it with something better like grepping /etc/passwd

The spinner, used to show progress adds a lot of overkill just to give some feedback while working

The chunked transfer encoding is necessary to serve files of unknown size (created dynamically)

Should provide an easy way to generate a new configuration file based on the provided command-line arguments.

Great feature, implemented in mtn

http://moviethumbnail.sourceforge.net/

See also FS#126

The available configuration options need a serious review and renaming. Old names will be accepted with warnings for either two releases or six months.

Also, should provide a sample configuration file so that the syntax and options are clearer.

This is necessary for ZIP files constructed on the fly.

The current webserver implementation doesn’t support that.

Originally reported by Pär: https://outlyer.net/2019-11-26:vcs-1-13-4-released/comment-page-1/#comment-60674

Recently got an update of ImageMagick:

$ magick --version
Version: ImageMagick 7.1.1-33 Q16-HDRI x86_64 22263 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP(4.5) 
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype heic jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png raqm raw rsvg tiff webp wmf x xml zip zlib zstd
Compiler: gcc (14.1)

Because of that, the "convert" command now gives a deprecation warning:

WARNING: The convert command is deprecated in IMv7, use "magick"

Trying to do that, replacing all the calls to 'convert' for 'magick', the temp images seem to be problematic (I've added a few printouts of the suspected code blocks):

[i] Capturing in range [04:49.49-19:17.95]. Total length: 20:25.35
[i] Generating capture #1/4 (04:49.49)...
magick: no images found for operation `-geometry' at CLI arg 7 @ error/operation.c/CLIOption/5479.
magick: magick -background 'transparent' -fill 'transparent' '/dev/shm/vcs.SGteWR/vcs-ZQ0dJj-cap-000001.png'   \( -geometry 267x200! \)  -flatten   \( -box '#000000aa' -fill 'White' -stroke none -pointsize '9'     -gravity 'SouthEast' -font '/usr/share/fonts/TTF/DejaVuSans.ttf' -strokewidth 3 -annotate +5+5     ' 04:49.49 ' \) -flatten -gravity None  -flatten  \( -background black +clone -shadow 50x2+4+4 -background none \) +swap -flatten -trim +repage  -flatten  '/dev/shm/vcs.SGteWR/vcs-zQhKDd.png'

If I try to cp those two temp images on the line below the 'magick' command, they become 0 byte files.

The video renderer ffmpeg has also gone through a couple of steps of upgrades over the years, I now have:

$ ffmpeg -version
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 13.2.1 (GCC) 20230801

So commands like '-vframes' is now '-frames:v' and so on. No errors, just friendly suggestions in the man page. I replaced those also, but still the same problem.

I should have listened more carefully when our kindergarten teacher went through Bash. ;) IOW, I'm sure it's something simple I am not understanding.

N.b. I can still use vcs with the normal 'convert' command, but depending on how "militia force" serious the ImageMagick gang is going to be about deprecation warnings and removal of old code, it might stop working at some point in the future and I think that would be sad.

Any ideas? Thanks! :)

Originally suggested by Dogn Redhammer

Possibly using a dynamic ZIP file

See http://developer.android.com/reference/java/util/zip/ZipOutputStream.html

Reported by Vendetta 18/09/2016 on Google Play

Dejó de funcionar Desde la actualización d mi Huawei P8 lite a android 6 ya no sale el tipo d conexión en la barra d notificaciones.

P8 lite / Marshmallow / r14034

Reported by Oncewarriors 9/08/2017 through email

[...]the bar icon is vanishing after a while

Originally reported by Pär: https://outlyer.net/2019-11-26:vcs-1-13-4-released/comment-page-1/#comment-60689

Another thing that is a little bit annoying, but isn't a very big deal, is the fact that videos made from a phone where the image is rotated in metadata, doesn't produce a correct aspect ratio. For example, a video that is stored as 1920×1080 (16:9), but shown as 1080×1920 (9:16), due to metadata rotation, vcs will create thumbnails in 1920×1080 aspect ratio (16:9) but show them rotated correctly, which means the image at 9:16 gets squashed to fit into 16:9. Like I said, not a very huge deal, but it looks somewhat silly and it would be great if it was possible to fix.
I've tried to see if I could set the aspect parameter but it doesn't seem to do much when the rotation is made in metadata. Metadata usually state something like:
>
> "`bash
Side data:
displaymatrix: rotation of -90.00 degrees
"`

When the resulting contact sheet is too thin, the meta-information header is cramped and fields overlap.

Fails on some files (gets stuck forever while capturing the first frame).

Happens often with Matroska. 1.0.7a introduced a workaround (-Wo) with ffmpeg’s argument order that worked with other file types.

Originally reported by Phil Grundig

Version of ffmpeg: ffmpeg (CVS-060515)

Originally reported by Phil Grundig

Version of mplayer: mplayer (1.0pre8cvs)

-o is a GNU extension, supported in Linux and FreeBSD

Unsupported in SunOS, OpenBSD?

Originally reported by Tomasz Strózik

Example given:

$ find $DIR \(-name "*.avi" -o -name "*.wmv" -o -name "*.mpg" -o -name "*.mp4" \) -exec vcs -dt -ds -n 12 -c2 -H 200 --jpeg --quiet {} \;

Works on avi, mpg and mp4 but fails on wmv with
Failed to capture frame (at second xxx.000)

Processing the same file directly works:

$ vcs -dt -ds -n 12 -c2 -H 200 --jpeg --quiet File.wmv

No need for description

Originally reported by Dougn Redhammer

No need for description

Original report by Dougn Redhammer

vcs hangs with some RM files.

Tracing shows it gets stuck in mplayer_identify.

MPlayer can play the files fine from the terminal. Although it exits with «MPlayer interrupted by signal 11 in module: uninit_vcodec».

I can reproduce the abrupt termination, it happens when using Real’s native decoder (w64codecs, /usr/lib/codecs/drvc.so). Using FFMpeg’s decoder (MPlayer’s -vc ffrv30) MPlayer exits normally.

I can’t reproduce the hang either way.

Running in Fedora Core 10 i686 (KVM) yields one 128k frame less and a different “theoretical size” than in Debian amd64, in one sample, and the same number of frames but 2 bytes less in another.

No need for description