Since current seek is precise seeking, the performance would be dominated by the seeking time. If the frame of the seeking time is close to key-frame, then seeking will be done quickly. If not, seeking will take some time for decoding from key-frame to the frame of seeking time which depends on the size of GOP as well. At application layer, seeking is at time base, not frame base. So if application can find the corresponding time of key-frame and take it to seek, the performance would be better. This may benefit video thumbnail generation, normal seek, fast forward, and rewind. Also this parse module may be able to be reused cross-platform. But I am not a JavaScript expert, not sure if it is doable or not and how is the parsing performance :)

Hi John, As we discussed offline, maybe this is the one you can take for getting performance improvement by parsing the i-frame position before calling seek.

Can't we just implement [1] ? Bug 778077 is about implementing it. [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-media-fastseek

Hi Paul, Thanks for your information! I was aware of Bug 778077, but not aware that whatwg has put it in the living standard. BTW, do you know how to set approximate-for-speed flag? Which attribute is for it? I didn't find it in the standard.

Blake, the approximate-for-speed flag is `true` when you seek using the fastSeek method, `false` if you seek by setting the `currentTime` property to a value. This flag exists only in the context of the spec, and is not part of the HTMLMediaElement interface. It is merely a way for the spec author to factor part of the seeking algorithm.

Hi Marco, Yes Sir, I will start to write it. Hi David, I think this bug should also be under your radar. We will try to write a javascript version metadata parser for MP4 to get the largest I-frame for thumbnail generation. I will leverage the version at Music app that is written by Dominic. The largest I-frame means two things: 1. It's fast to seek that frame and we can use normal seek to have the equivalent performance of fastseek 2. The screen is relative richer than others and is not all black, white, or other too simple frame. Your suggestion will be very helpful.

Change the title to be more specific to find the biggest key-frame for video thumbnail.

This may be doable for parsing the "stss" box (section 8.20 of ISO/IEC 14496-12). The following is C++ implementation in Android. http://androidxref.com/4.4_r1/xref/frameworks/av/media/libstagefright/MPEG4Extractor.cpp#1439

Long term, I think it makes sense to have an API in gecko that just returns a thumbnail of the largest i-frame or keyframe in a video. We could do that in C++ the MP4Reader, but it will need to wait until we add non-fragmented MP4 demuxing support, which will take a while. So in the short term, doing this in JavaScript is an acceptable solution. Maybe there's some C/C++ code to do this that you can run through Emscriptem?

Hi Chris, I also agree with you to have an API for thumbnail to let gecko do it. But some people in web API mailing list seem not agree to have a new one and try to find some ways or other apis to achieve the goal. One raised idea is to do parsing files in application layer and the advantage of this is cross-platform reusability . I will loop you in the mailing list. Maybe you can give us some feedbacks.

This sounds like a useful feature, but from the standpoint of Gaia media apps, I don't know that it is a high-priority feature. Is there a user story or product requirement or blocking bug in the Video app that requires this? John: please make sure that any work on NFC takes priority over this. In addition to MP4 parsing code in the metadata parser, there is also shared/js/media/get_video_rotation.js file that includes a MP4Parser() utility class that you might find helpful. Note also that I don't think you should find the biggest i-frame in the entire movie... I suspect that finding the first non-small one would give better results because it would tend to give a poster image from near the beginning. Of course "non-small" would have to be a tuneable parameter. Maybe the first one that is above average size?

Thanks David. The NFC is higher than this one, of course. They are under QA testing now. Hope everything OK. If anything wrong, I will jump back to NFC again. And you are correct at finding the biggest I-frame. At the implementation of Android, it finds the biggest I-frame at the first 10 frame. I will also try to create both if possible and evaluate them. I don't know if this feature has any the user story or product requirement or blocking bug. Maybe, Macro can answer it.

(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #11) > I don't know if this feature has any the user story or product requirement > or blocking bug. Maybe, Macro can answer it. Hi, There is no such requirement to push this work. From my point of view this work not only improve the speed performance but also get more quality on thumbnail. So I didn't see any reason preventing us from doing better. Of course, things always have priorities. And please evaluate and arrange your works based on priority. Thanks for John's effort on it.

De-assign myself, since this goes to backlog.

Mass closing do to inactivity. Feel free to re-open if still needed.