- From: Kevin Marks <kevinmarks@gmail.com>
- Date: Tue, 11 Jan 2011 15:46:36 -0800
These goals are orthogonal though - stepping between frames is valuable whether they are regularly spaced or not. Timecode is a representation that comes from the legacy video world that does assume a uniform frame rate On Tue, Jan 11, 2011 at 2:40 PM, Rob Coenen <coenen.rob at gmail.com> 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. >> >> >
Received on Tuesday, 11 January 2011 15:46:36 UTC