TPESystem/Media/VideoThumbnail: Difference between revisions
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
<LI>Sometimes seeking takes time <br> | <LI>Sometimes seeking takes time <br> | ||
Current seeking is a precise way which means it decodes from the closest key-frame to the requested seek frame. If the frame at 1/10 duration is far from key frame, it takes longer. | Current seeking is a precise way which means it decodes from the closest key-frame to the requested seek frame. If the frame at 1/10 duration is far from key frame, it takes longer. | ||
<LI>Seek also applies to audio <br> | |||
Video thumbnail has nothing to do with audio. Need to find a way to avoid audio process. | |||
</OL> | </OL> | ||
<LI><b>Use Canvas to draw image and save it as a jpeg file </b><br> | <LI><b>Use Canvas to draw image and save it as a jpeg file </b><br> | ||
Revision as of 09:34, 19 February 2014
This page is intended to have an overall summary of discussions in Bug#942078[1] and webapi mailing list[2].
Background
Currently video thumbnail generation is not a good method and there are some room to improve as described below.
- Seek to 1/10th of the duration
- 1/10th may not be a good choice
A better way is to pick the biggest frame of the first 10 key frames as Android does. That frame should contain much information. - Sometimes seeking takes time
Current seeking is a precise way which means it decodes from the closest key-frame to the requested seek frame. If the frame at 1/10 duration is far from key frame, it takes longer. - Seek also applies to audio
Video thumbnail has nothing to do with audio. Need to find a way to avoid audio process.
- 1/10th may not be a good choice
- Use Canvas to draw image and save it as a jpeg file
There is a full-size memory allocation used in Canvas to hold a decoded frame.