[vlc-devel] Project: Video Barcodes for VLC

Sebastian Morr sebastian at morr.cc
Tue Mar 5 01:20:26 CET 2013


Hey,

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 [1].
- 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:

    https://github.com/blinry/vlc/compare/master...mediabarcode

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 [1], 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 (?), 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 [2], it should be possible to solve this.

I'd appreciate any kind of feedback. It has been fun working on this! :)

Kind regards,
Sebastian

1: https://github.com/blinry/mediabarcode
2: https://github.com/lbrandy/ffmpeg-fas



More information about the vlc-devel mailing list