[vlc-devel] Project: Video Barcodes for VLC
mirsal at mirsal.fr
Tue Mar 5 12:41:54 CET 2013
On Tue, 2013-03-05 at 01:20 +0100, Sebastian Morr wrote:
> I'd like to share my progress regarding video barcodes with you.
> This is how it looks like right now: http://files.morr.cc/nemo-barcode.png
> The barcode is generated each time a video file is opened. For a 7.5 GB
> 1080p file on an USB2.0-connected hard drive, with a 2.5GHz Core 2 Duo, that
> takes about a minute. For the screenshot's movie, it takes about 4 seconds.
> The already generated part is updated every second. There's still a lot of
> potential for speed optimizations.
> Implementation-wise, this is a still an early prototype, a proof of
> concept that required a minimum of changes on the code:
> - The barcode generation itself is done by a small external FFmpeg-based
> library .
> - A "mediabarcode" module is introduced that has the "art finder"
> capability. When evoked, it starts generating the barcode, writes it
> to a file each second, and sets the item's art URL to it.
> - The qt4 GUI's SeekSlider gets notified on art changes and reads the
> file to a "barcode" QPixmap member variable.
> - The SeekStyleBarcode draws this QPixmap as the slider's background and
> draws the handle a little different.
> The diff to the current master is here:
This is cool stuff :)
> If you'd like me to send the patches to this list, please tell me, but the
> code isn't ready for review yet, at all. The code requires a UNIXoid right
> now, as it saves the barcode in /tmp.
> To try the code, you will need to build the mediabarcode library , if
> you encounter any problems there, please tell me. I guess many of you
> would appreciate a .deb package?
> Now, here are ideas to implement a barcode functionality properly:
> While video files normaly don't have album art (?),
As a matter of fact, some do.
For instance, many UPnP media servers send cover art among video
metadata for films.
> which would allow
> this "abuse", the barcode generation *could* be extended to audio files
> (like Amarok's moodbar, or just a display of volume). Because of this, the
> barcode information should be stored parallel to the artwork.
> While the file-based approach allows for easy caching, which is very
> desirable here, a purely memory-based method would be generating faster.
> What are your thoughts here? Where could a "barcode frame" be stored? The
> input_item itself doesn't feel like the right place for me.
> So far, the mediabarcode library seeks to keyframes only. This works
> perfectly for movies, not so well for short videos where you can have a
> lot of timestamps seeking to the same keyframe. Using an approach similar
> to ffmpeg-fas , it should be possible to solve this.
> 1: https://github.com/blinry/mediabarcode
> 2: https://github.com/lbrandy/ffmpeg-fas
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part
More information about the vlc-devel