broken video clip has extremely blurry icon when navigating to the camera roll

[Bill Filler]

from design:
If for some reason thumbnail was not able to be generated after taking a video, the placeholder thumbnail is very blurry. Guessing that thumbnailer is not providing a thumbnail for this at needed size requested.

[Michi Henning (michihenning)]

Can we have a copy of the offending video? That would help a lot.

What sort of video is this? One that was taken with the camera, or was it added to the device from somewhere else?

If the video was copied from somewhere else and contains cover art, that cover art will be used. Because the thumbnailer never up-scales, if the embedded cover art is small, it ends up getting up-scaled by display widget, which might be what causes it to look blurry.

We really need an example file to figure out what is going on.

[Michi Henning (michihenning)]

Also, why does it say "broken" video clip in the title. Is there something wrong with the clip?

[Michi Henning (michihenning)]

This sets full trace for the thumbnailer:

gsettings set com.canonical.Unity.Thumbnailer log-level 2

If you want to start out with a cold cache, you can run

thumbnailer-admin clear

Then run a trace on ~phablet/.cache/upstart/dbus.log

The trace shows the requested dimensions for each thumbnail. Check whether the dimensions being asked for are correct. If too small, the problem is outside the thumbnailer. If dimensions are as expected, and the video contains embedded cover art, the embedded cover art will be returned scaled down to the requested size; if the dimensions of the embedded cover art are smaller than the requested dimensions, the cover art will be returned at the size it was found in the video.

Otherwise, if the video does not contain cover art, the thumbnailer will extract a still frame and return that still frame, scaled down to the requested size. In this case, the only way the image would be blurry if the still frame itself is blurry, or if the video has ridiculously small dimensions.

To confirm what's going on, run

/usr/lib/x86_64-linux-gnu/thumbnailer/vs-thumb <absolute/path/to/video> video.tiff

Then check video.tiff by looking at it with a browser or image viewer. This completely bypasses the thumbnailer and verifies whether the image is being extracted correctly and omits any scaling; the command simply dumps whatever image was found as cover art, or whatever screenshot was extracted.

You can also talk to the thumbnailer:

thumbnailer-admin get <absolute/path/to/video>

This drops the thumbnail at the largest available resolution into the current directory.

To request a specific size, use

thumbnail-admin get --size=200 <absolute/path/to/video>

This adds the image to the cache and returns it (or returns it from the cache if it was cached earlier) after running it through the scaler.

man thumbnailer

and

man thumbnailer-service

provide more detail.

[Florian Boucault (fboucault)]

No need to go through all this debugging: just launch the camera, go to the photo roll and make sure a broken video is available.

[Florian Boucault (fboucault)]

Result above ^

[Michi Henning (michihenning)]

Ah, so *that's* what a broken video is :-)

I guess the fallback image that is returned is just really low quality. We have branch waiting to be merged for this:

https://code.launchpad.net/~jamesh/thumbnailer/no-fallback-albumart/+merge/263216

Once that merges, each app and scope can provide its own fallback art.

[James Henstridge (jamesh)]

The removal of fallback art is currently in silo 45. When that lands, the blurry icon will disappear and you'll be left with a blank rectangle.

If you want to display something other than an empty rectangle set an onStatusChanged handler on the Image component, and if status changes to Image.Error, set source to the desired fallback image. This will allow you to pick a fallback that is appropriate to your app.

We're removing the fallback feature because (a) it is impossible to return a fallback image that is optimal in all situations (where some apps use a light background and others dark), and (b) it is currently impossible for applications to detect when a fallback image has been substituted other than reading the pixels of the Image component.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gallery-app - 0.0.67+16.04.20160225.1-0ubuntu1

---------------
gallery-app (0.0.67+16.04.20160225.1-0ubuntu1) xenial; urgency=medium

  [ Arthur Mello ]
  * Add a timer to make sure all taken photos are added into collection
    in a batch (LP: #1521365)
  * Add missing pkg dependency for qtdeclarative5-ubuntu-thumbnailer0.1
    (LP: #1531604)
  * Fix action button calls on AP tests
  * Following some changes on thumbnailer image provider we need to
    handle Image.Error status for videos that are unable to load
    correctly (LP: #1542083)
  * Make sure to request a thumbnail big enough to handle all the
    possible sizes that way media items will not request a new one every
    time it changes its position. (LP: #1529452)
  * Remove photo-image-provider to use the one provided by ubunut-ui-
    extras Move photo-metadata from photoeditor to photo folder (LP:
    #1541210)
  * Set albums created from PopupAlbumPicker as not new, so they will
    not be deleted after editing (LP: #1483870)
  * Show a checkered background as a background for transparent images
    (LP: #1548855)

  [ Ken VanDine ]
  * Register with the content-hub for deb installs

 -- Bill Filler <email address hidden> Thu, 25 Feb 2016 18:01:21 +0000