Search code examples
androidandroid-youtube-api

YouTube Android API seekToMillis() not working accurately


While using the youtubePlayer.seekToMillis() function, there is a seek delay of 2 seconds. Not exactly 2 seconds, but roughly so. Like if you try to seek any where between 10,000 milliseconds and 12,000 milliseconds (eg: 11,000 11,500, 11,550). The video will be started from 10,000 itself. If you give a value between 12,000 and 14,000 it goes to the 12,000 point.. and so on...

We are developing an app where a YouTube has to start from accurate the time specified. Hence this function is quite crucial for us.

youtubePlayer.seekToMillis(10000);
youtubePlayer.play();

Please show us some hints how we can start a video with the YouTube player from a precise starting time, if possible precisely to the millisecond.


Solution

  • This is not a bug, this is the standard behavior of a seekable-compressed video file.

    Short and super-simplified explanation

    A compressed video file is composed by a sequence of frames. There are two macro-types of frame, full frames (F) and partial frames (p*):

    • full frame: contains the full real frame at a specific time (like a full JPEG image)
    • partial frame is only a set of differences in relation to the previous frame, usually expressed as motion vectors.

    Raw video sequence:

    F F F F F F F F F F F F F F F F F F ... (eof)

    Compressed video sequence:

    F p p p p F p p p p F p p p p p F p p ... (eof)

    A Compressed structure like this allows to create smaller file (because partial frames are smaller than full frames), but also introduces a silly problem: it is not possible to start the playback directly from a partial frame because, in order to decode it correctly, you will need do ascend until the first full frame!

    This is exactly the problem you are experiencing: you are seeking to a specific time which is mapped on a partial frame, so you need to go back to the nearest full frame and start the playback from there.

    In a streming context like YouTube the problem is even more difficult because is header to trick this limitation using, for example, a fast forward approach.

    As written above, this is a very simplified explanation. You can find more information here.