** Changed in: thumbnailer (Ubuntu)
Status: Confirmed => Won't Fix
** No longer affects: canonical-devices-system-image
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1391286
Title:
Fails to
Pragmatically, there is probably nothing we can do about this, short of
finding someone who is willing to dig into the codec and figure out why
it fails (which, in turn, might involve fixing some problem in the
Android media elements.
For what it's worth, the thumbnailer will recover gracefully
** No longer affects: thumbnailer
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1391286
Title:
Fails to generate thumbnail for small videos recorded with camera-app
To manage notifications about
** Changed in: canonical-devices-system-image
Importance: Undecided => High
** Changed in: canonical-devices-system-image
Status: New => In Progress
** Changed in: canonical-devices-system-image
Milestone: None => backlog
** Changed in: canonical-devices-system-image
Switching to the software codecs is the right answer as the setup time
of a hardware codec is currently much slower than with an equivalent
software codec. I'd like to do some profiling of the hardware codec
setup process some time in the near future to see if it's just how it
will always be
No, 1.5.2 has the same problem. It isn't really gstreamer that's at
fault here, but the hardware codecs underneath it.
James has been doing a lot of work isolating the problem. Current plan
is to switch to software codecs which, going by James's benchmark
results, should improve speed massively.
@michihenning it just landed in image 75, devel-proposed in arale (and
in latest images for the other phones I guess). I am also under the
general impression that gstreamer 1.5.2 greatly reduces the time needed
for creating a thumbnail, it would be good if you can confirm this :-).
--
You
** Also affects: canonical-devices-system-image
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1391286
Title:
Fails to generate thumbnail for small videos
It looks like gstreamer 1.5.2 (about to land in wily) solves the issue
for the video attached to the bug. I have also rechecked that 1.4.5 is
not able to create a thumbnail for it.
** Changed in: gst-plugins-bad1.0 (Ubuntu)
Status: Confirmed = In Progress
** Changed in: gst-plugins-bad1.0
Nice one, thanks! I'll try it once it lands (or do you have a silo I can
pull it from?)
Note that, with the new thumbnailer, the failure no longer delays
everything that's queued up behind it. In general, the new thumbnailer
achieves much better isolation and concurrency.
--
You received this
** Changed in: thumbnailer (Ubuntu)
Assignee: Jussi Pakkanen (jpakkane) = (unassigned)
** Changed in: thumbnailer (Ubuntu)
Assignee: (unassigned) = Michi Henning (michihenning)
** Changed in: thumbnailer
Assignee: Jussi Pakkanen (jpakkane) = (unassigned)
** Changed in:
@James I don't have any ideas offhand right now without digging further,
but I do know that there indeed is some optimization that is needed for
gstamc-hybris to help with situations like this as well as to greatly
increase the speed of thumbnailing in general. I've got an item on my
team's
This seems to be related to the androidmedia elements from
gstreamer1.0-hybris, so changing the source package link: I can't
reproduce it with the standard elements.
In the hope that this might be a quirk of the pipeline used by vs-thumb,
I've ported the utility over to using the standard playbin
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: thumbnailer (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1391286
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: gst-plugins-base1.0 (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1391286
What happens here is that thumbnailer calls the
gst_app_sink_pull_preroll function which fails. The documentation
(http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-
base-libs/html/gst-plugins-base-libs-appsink.html#gst-app-sink-pull-
preroll) says that this returns null if EOS
** Changed in: thumbnailer
Importance: Undecided = High
** Also affects: thumbnailer (Ubuntu)
Importance: Undecided
Status: New
** Changed in: thumbnailer (Ubuntu)
Importance: Undecided = High
** Tags added: rtm14
--
You received this bug notification because you are a member
The troubling part is that when a thumbnail like this is encountered, it
seems to invalidate all of the other thumbnails that have already been
loaded. For example, open the Photos tab of the gallery app and wait for
the thumbnails to load, scroll up and down. Everything gets loaded. Then
copy in
It seems that when gallery requests the thumbnail for this file, even if
it was generated before, all the process of getting new thumbnails for
gallery collection, or getting pointers for the previous generated ones,
get a lot of time to complete. That seems to be the reason why all the
thumbnails
19 matches
Mail list logo
