W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Dirk-Willem van Gulik <Dirk-Willem.van.Gulik@BBC.co.uk>
Date: Wed, 12 Jan 2011 00:23:59 +0000
Message-ID: <FEC20560-C846-4B2B-BF2F-429F5989157F@BBC.co.uk>
Right - but that foregoes a bit how subtle the SMPTE timecode definition is (http://en.wikipedia.org/wiki/SMPTE_time_code is a good start) - and this is exactly why it is defined in such odd a manner (as you do have exactly this tautology problem between, say, NTSC and PAL).

So yes - you want do express this - knowing full well that once you have less than one frame/second the interpretation is a bit odd. But ultimately it does let you define exactly where a cut/splice/etc is - and how exactly two things are overlaid, etc.

Dw.

On 11 Jan 2011, at 22:51, David Singer wrote:

> OK, but it does seem kinda a tautology if you say "I want to use a time-expression that represents fractions of seconds as frame numbers, and it's not very accurate if there aren't very many frames/second..." !
> 
> On Jan 11, 2011, at 23:40 , Rob Coenen wrote:
> 
>> Hi David- that is b/c in an ideal world I'd want to seek to a time expressed as a SMPTE timecode (think web apps that let users step x frames back, seek y frames forward etc.). In order to convert SMPTE to the floating point value for video.seekTime I need to know the frame rate.
>> 
>> -Rob
>> 
>> On Tue, Jan 11, 2011 at 10:35 PM, David Singer <singer at apple.com> wrote:
>> why does the frame rate make any difference on the accuracy of seeking to a time?  Imagine a video that runs at 1 frame every 10 seconds, and I seek to 25 seconds.  I would expect to see 5 seconds of the third frame, 10 seconds of the 4th, and so on.
>> 
>> On Jan 11, 2011, at 18:54 , Rob Coenen wrote:
>> 
>>> just a follow up question in relation to SMPTE / frame accurate playback: As
>>> far as I can tell there is nothing specified in the HTML5 specs that will
>>> allow us to determine the actual frame rate (FPS) of a movie? In order to do
>>> proper time-code calculations it's essential to know both the video.duration
>>> and video.fps - and all I can find in the specs is video.duration, nothing
>>> in video.fps
>>> 
>>> -Rob
>>> 
>>> 
>>> On Mon, Jan 10, 2011 at 9:32 PM, Kevin Marks <kevinmarks at gmail.com> wrote:
>>> 
>>>> If you really want to test timecode, you need to get into SMPTE drop-frame
>>>> timecode too (possibly the single most annoying standards decision of. all
>>>> time was choosing 30000/1001 as the framerate of NTSC video)
>>>> 
>>>> Eric, can you make BipBop movie for this? - Like the ones used in this
>>>> demo:
>>>> 
>>>> 
>>>> http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html
>>>> 
>>>> http://devimages.apple.com/iphone/samples/bipbopgear3.html
>>>> 
>>>> 
>>>> On Mon, Jan 10, 2011 at 11:18 AM, Rob Coenen <coenen.rob at gmail.com> wrote:
>>>> 
>>>>> Thanks for the update.
>>>>> I have been testing with WebKit nightly / 75294 on MacOSX 10.6.6 / 13"
>>>>> Macbook Pro, Core Duo.
>>>>> 
>>>>> Here's a test movie that I created a while back. Nevermind the video
>>>>> quality- the burned-in timecodes are 100% correct, I have verified this by
>>>>> exploring each single frame by hand.
>>>>> 
>>>>> 
>>>>> http://www.massive-interactive.nl/html5_video/transcoded_03_30_TC_sec_ReviewTest.mp4
>>>>> 
>>>>> Please let me know once you guys have downloaded the file, I like to
>>>>> remove
>>>>> it from my el-cheapo hosting account ASAP.
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> Rob
>>>>> 
>>>>> 
>>>>> On Mon, Jan 10, 2011 at 2:54 PM, Eric Carlson <eric.carlson at apple.com
>>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 9, 2011, at 11:14 AM, Rob Coenen wrote:
>>>>>> 
>>>>>> I have written a simple test using a H264 video with burned-in timecode
>>>>>> (every frame is visually marked with the actual SMPTE timecode)
>>>>>> Webkit is unable to seek to the correct timecode using 'currentTime',
>>>>> it's
>>>>>> always a whole bunch of frames off from the requested position. I reckon
>>>>> it
>>>>>> simply seeks to the nearest keyframe?
>>>>>> 
>>>>>> WebKit's HTMLMediaElement implementation uses different media engines
>>>>> on
>>>>>> different platforms (eg. QuickTime, QTKit, GStreamer, etc). Each media
>>>>>> engine has somewhat different playback characteristics so it is
>>>>> impossible
>>>>>> to say what you are experiencing without more information. Please file a
>>>>> bug
>>>>>> report at https://bugs.webkit.org/ with your test page and video file,
>>>>> and
>>>>>> someone will look into it.
>>>>>> 
>>>>>> eric
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
Received on Tuesday, 11 January 2011 16:23:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC