20714 2013-01-20 16:32:10 +0000 timestampOffset in live case 2013-03-25 19:14:49 +0000 1 1 1 Unclassified HTML WG Media Source Extensions unspecified PC Windows NT RESOLVED LATER P2 normal --- 1 cyril.concolato adrianba acolwell mike public-html-media strobe public-html-bugzilla oldest_to_newest 81608 0 cyril.concolato 2013-01-20 16:32:10 +0000 When joining a live session, the timestamp of the first coded frame received is typically not zero. To have proper playback (not have the player stall), the web apps needs to set the timestampOffset attribute of the SourceBuffer. In some cases, such as using MPEG-DASH, an approximate timestamp might be provided in the manifest. However, in many cases, the web app will have to parse the media data in JavaScript, which is not optimal. It would be preferable to be able to force an automatic offset, or to set/force the timestamp to zero. Alternatively, it could be interesting to have a method to ask the media engine to parse and return the timestamp range of some data, so that the app can then transfer the data to the sourcebuffer with the right timestampOffset. 81611 1 strobe 2013-01-20 19:03:29 +0000 I think the assumption that playback must begin at t=0 may be wrong here. Are you encountering problems when you append media data starting at t>0, and then seeking to that time to begin playback? If so, that's an implementation bug, not a spec issue. Note that you can append media data and then examine the buffered ranges to determine the timestamps of the media data that was appended. By what means are you fetching media data? In most scenarios (e.g. DASH, HLS) the timestamp of the media data being fetched is provided in the manifest which describes chunk URLs, so you don't even need to wait for parsing to finish. (IMHO, t=0 should be the natural start time of the stream, not the join time. This lets users watching on multiple devices (or users who refresh the page) have the same timestamps; it allows users to rewind to before they started watching a stream; it allows people to talk about and link to particular timecodes in a stream, and have them be consistent; and it allows the same content to be used in a VOD setting after the live presentation has concluded without different player logic. Of course, all of that is application-level policy, but it has bearing on this issue because it suggests that the proposed "force the timestamp to zero" functionality may not be widely used.) 81627 2 1316 cyril.concolato 2013-01-21 11:31:55 +0000 Created attachment 1316 exemple of timeline after joining a live stream 2h after the start 82256 3 adrianba 2013-01-29 04:08:45 +0000 (In reply to comment #2) > Created attachment 1316 [details] > exemple of timeline after joining a live stream 2h after the start Apps can draw whatever custom UI they like for the seek buffer. It's probably quite likely that apps with live content will want a custom UI indicating whether it is possible to seek back and by how much. 82266 4 cyril.concolato 2013-01-29 07:35:00 +0000 Had problems replying the first time. Replying again. (In reply to comment #1) > I think the assumption that playback must begin at t=0 may be wrong here. > Are you encountering problems when you append media data starting at t>0, > and then seeking to that time to begin playback? If so, that's an > implementation bug, not a spec issue. I'm not having problems appending, the problem is mostly with the UI as depicted in the attachement. > > Note that you can append media data and then examine the buffered ranges to > determine the timestamps of the media data that was appended. Yes, but you cannot change the timestamps anymore. I think it's a general problem that in order to append properly (i.e. without creating gap) you need to parse the data first to get the time stamp. > > By what means are you fetching media data? In most scenarios (e.g. DASH, > HLS) the timestamp of the media data being fetched is provided in the > manifest which describes chunk URLs, so you don't even need to wait for > parsing to finish. In my understanding HLS does not provide such a timestamp. DASH provides, only in some cases, the presentationTimeOffset attribute, but not always. In my case, I'm also envisaging simple chunk-transfer delivery of live data without manifest, similar to IceCast and ShoutCast. > (IMHO, t=0 should be the natural start time of the stream, not the join > time. This lets users watching on multiple devices (or users who refresh the > page) have the same timestamps; it allows users to rewind to before they > started watching a stream; it allows people to talk about and link to > particular timecodes in a stream, and have them be consistent; and it allows > the same content to be used in a VOD setting after the live presentation has > concluded without different player logic. Of course, all of that is > application-level policy, but it has bearing on this issue because it > suggests that the proposed "force the timestamp to zero" functionality may > not be widely used.) I agree that your use case make sense but you assume that a live event is a one shot event for which the streaming starts at the beginning of the event (timestamp = 0). If you record a single program in 24/7 TV channel, the timestamp of the first AU won't be zero. You'd have the same problem. On second thoughts, maybe the problem is not about shifting the timestamps but about indicating properly to the browser that it will never be able to seek before the first data received, so that it can adjust the timeline UI. I'm unclear about how the buffered and seekable attributes are filled in with MSE (and HTML 5 Media Elements in general). 82267 5 cyril.concolato 2013-01-29 07:37:21 +0000 (In reply to comment #3) > (In reply to comment #2) > > Created attachment 1316 [details] > > exemple of timeline after joining a live stream 2h after the start > > Apps can draw whatever custom UI they like for the seek buffer. It's > probably quite likely that apps with live content will want a custom UI > indicating whether it is possible to seek back and by how much. Why wouldn't it be possible for the app to indicate direclty to the built-in UI that seek is not possible (either before the first data or outside of a seeking window), without requiring custom UI? 82276 6 adrianba 2013-01-29 14:26:27 +0000 (In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > Created attachment 1316 [details] > > > exemple of timeline after joining a live stream 2h after the start > > > > Apps can draw whatever custom UI they like for the seek buffer. It's > > probably quite likely that apps with live content will want a custom UI > > indicating whether it is possible to seek back and by how much. > Why wouldn't it be possible for the app to indicate direclty to the built-in > UI that seek is not possible (either before the first data or outside of a > seeking window), without requiring custom UI? Everything is possible if it is specified. There are lots of different options that people might want - our goal for v1 has been to keep it simple and address the most common goals intrinsically, gain implementation experience and see what is common in sites and libraries, and then consider enhancements subsequently. 82277 7 cyril.concolato 2013-01-29 15:26:07 +0000 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > Created attachment 1316 [details] > > > > exemple of timeline after joining a live stream 2h after the start > > > > > > Apps can draw whatever custom UI they like for the seek buffer. It's > > > probably quite likely that apps with live content will want a custom UI > > > indicating whether it is possible to seek back and by how much. > > Why wouldn't it be possible for the app to indicate direclty to the built-in > > UI that seek is not possible (either before the first data or outside of a > > seeking window), without requiring custom UI? > > Everything is possible if it is specified. There are lots of different > options that people might want - our goal for v1 has been to keep it simple > and address the most common goals intrinsically, gain implementation > experience and see what is common in sites and libraries, and then consider > enhancements subsequently. I understand. Consider this bug report as a feedback from using the current spec for live cases. I think enhancements are needed, whether or not they should be part of v1 ... maybe. 82318 8 acolwell 2013-01-30 00:24:35 +0000 Hi Cyril, If I understand correctly, I think you are bringing up several different issues. 1. The default UI for streams that don't start at 0 is suboptimal. 2. There is no way to disable seeking. 3. Media data has to be parsed in JavaScript to force a 0 start time. For items 1 & 2, I think you have competing requirements for display that may be specific to your personal preferences for live controls. Like Adrian says, custom UI controls can make it easier for you to control seeking and display the timeline however you wish. In the case of live, it could be considered a feature that you can seek back into the buffered data. For item 3, you don't have to parse the data in JavaScript. You could do the following to make the timeline start at 0 w/o parsing the data in JavaScript. sourceBuffer.append(firstMediaSegment); sourceBuffer.timestampOffset = -sourceBuffer.buffered.start(0); sourceBuffer.remove(sourceBuffer.buffered.start(0), sourceBuffer.buffered.end(0)) sourceBuffer.append(firstMediaSegment); You only have to do this once at the beginning and it will make the timeline start at 0. I think this will make the default UI look closer to what you want, but the displayed time will be 0 based instead of starting at the join time. I've used this trick with some internal MSE live demos I've written so I know it works. I would prefer to keep things as is for v1. I don't think what I propose here will be too high of a burden for web developers. If it is then we'll use their feedback to craft a solution for v2. 83190 9 cyril.concolato 2013-02-15 10:55:28 +0000 Hi Aaron, (In reply to comment #8) > Hi Cyril, > > If I understand correctly, I think you are bringing up several different > issues. > > 1. The default UI for streams that don't start at 0 is suboptimal. > 2. There is no way to disable seeking. > 3. Media data has to be parsed in JavaScript to force a 0 start time. I think you've summarized the issues quite well. > For items 1 & 2, I think you have competing requirements for display that > may be specific to your personal preferences for live controls. 'Competing' between each others or with someone else's requirements? The latter I presume. > Like Adrian > says, custom UI controls can make it easier for you to control seeking and > display the timeline however you wish. In the case of live, it could be > considered a feature that you can seek back into the buffered data. I agree, although it is not clear to me reading the spec that when buffered range is seekable. The 'seekable' given its name is clearer. Anyway, there are cases where you know that you won't be able to seek outside of the range that has been passed to the SourceBuffer. There should be a way to inform the built-in UI about it. > > For item 3, you don't have to parse the data in JavaScript. You could do the > following to make the timeline start at 0 w/o parsing the data in JavaScript. > > sourceBuffer.append(firstMediaSegment); > sourceBuffer.timestampOffset = -sourceBuffer.buffered.start(0); > sourceBuffer.remove(sourceBuffer.buffered.start(0), > sourceBuffer.buffered.end(0)) > sourceBuffer.append(firstMediaSegment); > > You only have to do this once at the beginning and it will make the timeline > start at 0. I think this will make the default UI look closer to what you > want, but the displayed time will be 0 based instead of starting at the join > time. I've used this trick with some internal MSE live demos I've written so > I know it works. This might have consequences on the media element state, trigger events ... which you might not want. 84313 10 acolwell 2013-03-12 22:01:16 +0000 I believe calling abort("timestampOffset") before appending anything will allow an application to always make sure the presentation starts at zero now without having to do the elaborate dance I outlined in a previous comment. The timestampOffset attribute will reflect the offset being applied once the first append completes so custom UI's can adjust the display of the current playback time if necessary. We could add the following attribute if you really want to be able to signal that HTMLMediaElement.seekable should return an empty TimeRanges. partial interface MediaSource { attribute boolean seekable; } - Initially set to true. - If true then existing behavior will be used. - If false then an empty TimeRanges object will be returned by HTMLMediaElement.seekable. 84935 11 adrianba 2013-03-25 17:56:04 +0000 (In reply to comment #10) > We could add the following attribute if you really want to be able to signal > that > HTMLMediaElement.seekable should return an empty TimeRanges. > partial interface MediaSource { > attribute boolean seekable; > } > > - Initially set to true. > - If true then existing behavior will be used. > - If false then an empty TimeRanges object will be returned by > HTMLMediaElement.seekable. I think applications are going to want more control than seekable or not seekable. As I said before, I don't think this is necessary as a v1 feature. Applications can build custom UI with whatever seek logic they want. Once we get more implementation experience of what people commonly want to build, especially for the Live scenario, we can consider what platform support this requires. I recommend RESOLVE, LATER. 84938 12 acolwell 2013-03-25 19:14:49 +0000 sounds reasonable to me. 1316 2013-01-21 11:31:55 +0000 2013-01-21 11:31:55 +0000 exemple of timeline after joining a live stream 2h after the start timeline.png image/png 4183 cyril.concolato iVBORw0KGgoAAAANSUhEUgAAA10AAAAhCAIAAACtEVYvAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA/sSURBVHhe7Z15zBXVGcap/7YIqKgY60IEF9Qo YABxB3cwiigaE0GIiEtAxB1RQeqKW8VgJJiYgDECaoiCSwjUBRAIra3FqIC0FfcVXEDB9idPe3Kc +e69M/PdW77LfU7MZL5zzpzlmZH53fc975lWbZ2sgBWwAlbAClgBK2AFrEDbtq0sghWwAlbAClgB K2AFrIAVQAFzoR8DK2AFrIAVsAJ1oECbNm35jxRO6mDQHmK9KWAurLc75vFaAStgBayAFbACLUaB du3a7bTTTjvvvDPHJpOKqLYNh5y996xcuMcee/z+f2n33XdPzI2cUErNbThzd20FrIAVsAJWYPtQ oE3OtH3Muo5mAe3lHW12PivVcvv8KdcgK3PhIYccsmjRog8//PDjjz/+5JNPOHL+xBNP7Lbbbkyv Q4cOTz/9dKL09ddfP/DAA3ONw5WtgBWwAlbAClgBKZATCH9V3RomFNh7772vuOKKI488shbKYAvs 3bv34MGDx44de//99z/22GMA0syZM2fNmvXkk08+/vjjDz/88G233Xb55Zefeuqp++67b3PG0LVr 19dee+2fW9M/osSf/yqRVPmtt94655xzMnZdjgsFwiNGjPh3U+noo4+mtE+fPk2WDhkyhNICKJ1x 3K5mBayAFbACVmD7UyBBhKVck3E+Npo0R25/yhSb0X777QexTZ48+brrrkvY6o477rhdd921WLO6 6pprrnnvvfd+/vnnJkEonfnZZ59Nnz4dTs3bqWjq7rvvzthRuhpAmbHTclwoBS+55JLNmzdv2rSJ 45YtWzgqQYSUnnLKKZz/9NNPoVQ1xYXNt5dmnIarWQErYAWsgBWodwVivGuS9krZEXfcccd0/XpX o/njP+CAA2699VZw6s4774ThYlvVeeedd/vtt+P5LNCL2CZYzWCeH3/8MUYxQAguInPjxo1pRHvx xRfzdqoe77nnHvX19ddfr1q1as2aNWvXrn377be//PJL4RnHdKI+RQsXLszYaSYuZFYJLoSOTzjh BPo4+eSTOU9wIfXNhRlvgKtZAStgBayAFUCBNPOxdv/ss8++6aab/lA6UUodaupyADFup5GFZRUc Dty77rprwoQJcCFWw8CFF1xwARbEW265JR0vkVGxXXbZZfXq1UDYDz/8IPLDr4tNbvny5VAaf1Ik O+Lnn3++ZMmSxYsX4+nlTxEkNrVctjNxYbAXPv/888ccc8yZZ555/PHHDx8+HDNkGS6E3+ixOlwY +5FhXsEfRxJ9BC7UPEOp6Piiiy5iDvYjZ3zCXM0KWAErYAUaXIGY58A7lsRhEMroN3z//fdHjhwp KCyMhm+++aa6410/cODA9O046KCD1q1bpzpQUVwhXPvFF18AK+lrceMKHhJdlMpv5sNw+OGH33HH HeAgUAgdPvDAAxgIaROeGzp06EMPPUQmdQr30qtXL1AM+AH+PvjgA0AzBN127twZjKeU+Y4fPx5H tnohPHfQoEGY+ihibLkYSTSFvRD16PG5555D5BNPPPHCCy8k8EMYFty5iRNRWfW58Pvvvwc56Zij 2DP4kTmn11BKzeZwIfB+7LHH9uvXD/mcrIAVsAJWwApscwX+XPu0YsWKpUuXEuX5p60JzhM/AQGl 3vdxvipPmzYNKAQgYjTMiD4B7MqgYaJOQMNS+XHXjzzySMy4AT1L5WccdqIaCIFrGGiDCHETg2Xw H+Egirqg6LLLLsNSOG7cOBi3WBcy3Z1//vncGsjnm2++6dGjR6Ip2meykH0in4EJJQlJyWUvTHDh 3Llze/bsyRiIKaEjbJY0WyqJynioMs63VZl6sb3w22+/pWP4j6OspjEX0msopWZhLuSeQYQHH3ww RP9bJytgBayAFbACLUABnIC1TrggeXO//PLLCxYswBcpo128pr88Hcpqw1WjR48ugIaQDS9xusPr GoyCTz31lPLFcDLs6TzOz3IOabzwwgtqP0EdpfIzQkyotueee8JhuIZxrAOFWOxYWQgU3nffff37 96caFUaNGkV08PXXX9+xY8e87Yf6QiP4Um7iSZMmqWjAgAE8JNxBQo9xGa9cuVIWwUMPPRTz3htv vHHjjTfOnj1bV7300ku5BhBzIZcT7Ny3b19CXjgHumCzMklU9sorr2TsMSsXrl+//rvvvoP/dExw IZmhlJqUFotHxlIITbeAfwQ8BCtgBayAFbAC/1WAl3pNE+vP2N8NTx9UwdIxXrKyRcVuOv1ZJgns WGqGhQU0zGUyFPMFFzD2PzFczHwy7MU2QtVRPpbOBHbE18YOaCGv/NSl8jMSTFyNPVLkHSbhO775 5ps5AdqIgqDaPvvsQ9wJUAg3488t0H64RPZC2mEiiAa38CchxqwjjA2iDECXPPvss3H+hg0b+DN7 dLAaieOR6XTevHmvvvoq7UBcPC3lk6ismvZC4pFp8auvvqJp5qNjggvJDKX4zgvbC8866yzWRvif IitgBayAFbACLUcBDHg1TcuWLcPUhEWHlz2AKM+gUqWX/q/KMdBw7RlnnCGTYViwmAuDxHnpZYIJ /pPvGJui8gmP1fLBJtcmihFjPIrtjun8XANWZbgQCsSBi8mQ48SJE1mNJ2jr1KnTDTfcABRi5CsW gByPR4g2ZswYhv3pp59q+eDpp58uUiIhHViPk5d8Fh2yIhOaJxgFOgKfqEApdznXHGN7IU3RDgZC uAtbYMUkKqsmFyoSm3nSNH50HRNcSGYoVSROsbgTFpG0nH8IPBIrYAWsgBWwAijA4r+aJqATkyFc CC6It+Sj4/WfK4k5QBZtWxNMhtkRRJDXpMO3PBeWZ7vYHhn7qUvlZx9wqAkX4jLGiUwCCnEl436k lJVpkCJrCsES9qAu0HLiEiHa1VdfzZSJQdZmhFAgosE/ABJH7gLBwuRDjdgRgffASNAUF/IzINdI 1Cngy7U0yOOhBismqonKqs+FmKZpmmdOzJvgQjJDqUypxPsEy2f2yeOet73Q/wpbAStgBaxAi1Lg LzVOQCd+aoyFeGPFhbxtZYjJlXhTQyRXXXVVgSWGvKlZ6lcKCikt70eWfzlmvjKvfnWUdj2Xys9C EbIXsnaQlYVEnPBpEK4i4hhGxL8s611VUsJeiDGSZk866SRmpG/CcRc4J0KZfOJgWGsIF/JZOOgI 257uUXru5ccW2wsxUsowWTEBZvSogOVqri+89NJLaVFTZVYcRbtx3InyddQIitkLMfkedthhLeqf Aw/GClgBK2AFGlyBv9U4wYKYDGEFJdmEeNWSOMmeIAauJcyidevWiQ1rKiKRmKzUDjVcXiruRPmJ 2GT8y3GPsW86ZsdS+RVHm64AF7IZDVDI4kJshFQgYpftYB588EGZ7qqVtL7wyiuvBO8I95GrGn8x nnQZTbV/DVEv6pEv4wVjKoCIqY8L+Q2QazwxF8JjejaaTHpyOPIw4Gvm8yr85KiJvRDUBfjohqNY OOZC5ev40UcfFbYX4vjHZNilSxfHIzf4v8KevhWwAlag5Sjw9xonsJOdcHAlKyRZKwt5mYYXKycV E+vYcD1z5NtucGEcelIRQdLr/3iPJ+KRaSTjPjWlYpZjX7PWL6b7LbX9YcUp7LXXXkSWEPMrAx7b PrMLNJ5l7SBNOu2005r51Tu1E7ZqUWTxvffeSyaw2K1btz9uTXwHec6cOQQLqzJhLjDi1KlTiccl WkUx5lC4rqo4r7hT+ZG5xeBW+QSzwaB8pvmoo45i9SpXVXP/QtkLMYTSDY8pR/0iiblQ+TqywWNh LmT+GF35ZCE/d7b5hlUegBWwAlbAClgBFMAUVNMEQ/A1M6gL0w67GAq/AEG9ecPrVS/ZRI4y2cdO O04TElDAWJjYRFAAl+bCLPtaB4tjHI/Myz1GwBj+SuVnBKa4GhDWvn17ctjDBSIk7gQ6FH5dfPHF wYBXoOX4EsEc8dRIhJmMBaCYKhNtSk8c+ol8LJcyKM6YMaMwF/JUYDIsk8AwRsXmOEwfKXiiamIv ZHElPfHYMSBZBOPvnQgHKeWoXRaL+ZGbebd8uRWwAlbACliBulMgBA6HdYF4P3mTsoCMDa5x0Zah UkqpQ03qE10RoDDXPjV1p1iZAbMLMurhQT7iiCOoBinCyiwxJFIku32uoiCsecNZDBGxgA/xWdfY vXt3vnTCx/fOPfdcDMDYbuE/ABFH8/777w9S83kSUBvfLoZGIqaD6bFiX6Gm7IV8ExncKpUYEitT 2R8RSCOx8JGVCfRYnfWF4cvQtMg46EzYBwUmvo8sXqSUIwRJqbiwivcgi3CuYwWsgBWwAlagHhVI oyHbI2f/Dh41qS/3sY4N+JVk7IXsdgccs8SQ3aR5DAgWZiEgjMhugqBbdZkE/yxoiKFXQRdsRsOJ NvLjHFjCpCfLqwJEQCMWYioGI/2JlPIPrUau7+DxMwDcajLRKe2zFAEixFjIEWe9dj6qTjyyxsF+ P8zk3Xff5UcJTx6/WmBEDMUYJynFj865ftBQyhF7OPWHDRuWi4Xr8X9jj9kKWAErYAWsQFUUSHwc WasDsXXheQRoCLAFbtKJfEqpQ80YChvTWIjFbsqUKWPHjsVup5uCoY4Na4BC1h0ilJYGNj+Jjli5 CBeCXAR5yOMPk2EmA5PeeecdjuAQJxjLyFeMiD49gvEy7xjUI/ZC+Io2wa10AsBIEBoIyMbX8+fP BxBJGC8ZZ3XshVKQHWdEu1gmtWWOds7s3bs3paAo50xVpdpKhxx9oLq6bJ5XR9e3AlbAClgBK1Av CiTQkGGH8BFOKqa4fgMaC5k+5jG2KtSGgiHhwCVImRgUtrauOpPgGubTdpBfYtdumQnjBM+xGJHP nPAtvgIPpHgMxqVNYVg6aYtz8ulLn9XGkU0SlWWPgG5VcXx8PeaZZ56BfDEZAr8cYVX2Ddf+kPxG efTRR8kMpdQhBIYPEVZs2RWsgBWwAlbAClgBKRDDnHaZ0fbUFHEslXStKifcxzTSUNqymUkCCjV9 fMoQFS7mGqlBmDMbJeI+Zc9CQnUJOr722mvZvocVjXyymTBkvkCDKa3JseUaEvvvYAjE/kdk0l9L JJWGxM6bVGSJIcsuM/ZVmQvVUKBsThrtUcsopatZAStgBayAFWimAk3SYcC+MieJC/2mjm9Ehw4d mnlfmrwcIsrrm85bvxbDLt9mJi5Mm17jnPKl//8puUcrYAWsgBWwAvWrQJrwCuTU7/TrdORiRCUc qqTwp2y923Ze2QeQiQu37WTcuxWwAlbACliBRlOgAAvqkkYTyvOtrgLmwurq6dasgBWwAlbAClRT gYyAWM0u3VYDK2AubOCb76lbAStgBayAFbACViBSwFzox8EKWAErYAWsgBWwAlbgFwXMhX4OrIAV sAJWwApYASvQ8Aq0adv6d61b7fCbHfyfFbACVsAKWAErYAWsgBUwFxqLrYAVsAJWwApYAStgBX5R 4D8E9flo9q3TAQAAAABJRU5ErkJggg==