Duration accuracy #314
Comments
|
I ran all of the bipbop segments through ffmpeg/ffprobe and output their durations. I compared our duration with the duration reported by the tool and in each case, we differed by 33ms. This happens to be the PTS interval between the last two tags, which we use to estimate the frame display duration. Related, the frame duration we measure, 33.3555... ms, is very close to the average framerate (tbr) reported by ffprobe, 29.97 or (1000/29.97) = 33.3667...ms. The next question was whether the time value reported by Flash matched the numbers I saw using our segment parser and ffprobe. In the three cases I tested, the video duration reported by Flash matched the ffprobe duration. That is, it was 33ms shorter than the duration number we were calculating. I put together a small playlist and checked the time reported by Flash when it completed to make sure that the final frame duration wasn't re-introduced when the segments were stitched. Strangely enough, Flash reported a total duration of 29.996s, while ffprobe and segment parsing came up with ~30.21s. As a final sanity check, I used high resolution timers to measure the duration of the time between |
|
Interestingly, the m3u8 for the short playlist I used for testing included duration numbers that were closer to the duration reported by Flash and timers. On a hunch, I decided to try calculating the duration numbers for the audio and video streams separately instead of mixing them together. As it turns out, the elementary streams in those files don't have matching durations. The minimum duration between the audio and video streams matches up precisely with the durations the segmenter wrote out in the M3U8. For this playlist, summing the durations in the m3u8 gives a duration of 29.9334s. |
Summary
We should calculate duration the same way ffmpeg does it, without an estimated final frame duration. The duration of video and audio streams in a segment can differ so we should track them separately and use the minimum of the two when we have to report total duration. Actual playback time may vary by hundredths of milliseconds over a relatively short video so we'll have to take this into account when trying to use currentTime to translate to PTS values, or vice-versa. |
|
Another piece of info: the end playback position reported by Flash is consistent across runs. The actual clock time required to hit this position may vary by tenths of milliseconds, however. |
Segment duration can have different interpretations in different contexts. To ensure we have all the information we need to seek accurately, record PTS values for the audio and video streams within a segment. For videojs#314.
Use the time range covered by the union of audio and video track PTS values when calculating duration. For non-live content, this matches the NetStream's duration calculation to within a millisecond or so. Make sure that segment PTS information is preserved when live playlists are refreshed. Remove FlvTag.durationFromTags in favor of Playlist.duration() since the latter handles durations across segments and discontinuities. For videojs#314.
|
After #339, I believe we're calculating duration reliably and accurately. |
When attempting to translate ID3 tags specified at PTS values to playback positions, I realized that the trustworthiness of segment duration calculations can have a big impact on the viability of many implementation strategies. I have done some research into different methods for calculating duration and playback position and will collect that information here.
The text was updated successfully, but these errors were encountered: