__group__,ticket,summary,component,version,type,owner,status,created,_changetime,_description,_reporter Backlog Release,1889,Chrome issue detecting mouse pointer location,embedding,,bug,jeroen,new,2013-01-15T10:24:01-05:00,2013-06-06T14:11:50-04:00,"This seems to be a small bug with the way we detect the mouse pointer location. If the player is inside a relative body, the coordinates are offset, leading to strange behaviour for both the rightclick and the seekbar. A simple example is attached. Note this only happens with Chrome in HTML5. ",ed Backlog Release,1961,LoQ streams play only audio,streaming,,bug,jeroen,new,2013-04-18T16:54:12-04:00,2013-06-11T17:47:49-04:00,"We encountered a few HLS test stream that only plays audio - no video. The issue seems related to the videos being low quality/bitrate (Baseline), but the exact cause is unclear. The streams are available in our HLS test set under: * ''440k/playlist'' * ''bartone/playlist'' * ''nih/playlist'' * ''sermon/playlist''",jeroen Backlog Release,1967,Video in HLS stream behaves like slide show,streaming,,bug,jeroen,new,2013-04-19T13:57:58-04:00,2013-06-11T17:48:59-04:00,"For some streams, HLS in Flash plays back the video like a slide show. It's uncertain what causes this issue. We looked into items like PES overflow (--optimize), B-frames, multiple NALU slices per PES and 2-pass H264 specific issues. None seem to be the issue. Test streams can be found here: * [http://playertest.longtailvideo.com/adaptive/gogo/manifest.m3u8 gogo/manifest] (zencoder) * [http://playertest.longtailvideo.com/adaptive/haze/manifest.m3u8 haze/manifest] (zencoder) * [http://playertest.longtailvideo.com/adaptive/pbs/playlist.m3u8 pbs/playlist] (zencoder) * [http://playertest.longtailvideo.com/adaptive/tvy7/playlist.m3u8 tvy7/playlist] (ffmpeg) We also exported FLV files of these files. These indeed have playback artefacts on FLV. The files can be found here: * [http://playertest.longtailvideo.com/adaptive/gogo/gogo.flv gogo] (zencoder) * [http://playertest.longtailvideo.com/adaptive/haze/haze.flv haze] (zencoder) * [http://playertest.longtailvideo.com/adaptive/pbs/pbs.flv pbs] (zencoder) * [http://playertest.longtailvideo.com/adaptive/tvy7/tvy7.flv tvy7] (ffmpeg) [http://s3.amazonaws.com/jeroenw/slideshow.html Visit this page] to see the slideshow issue for yourself.",jeroen Backlog Release,1973,Small volumeProgress/volumeThumb issues in HTML5,skinning,,bug,jeroen,new,2013-05-03T09:30:44-04:00,2013-05-03T09:30:44-04:00,"There's two small skinning issues with the volume slider in HTML5 mode: * volumeProgress and volumeThumb are not centered horizontally * volumeProgress is not stretched vertically In Flash, both work fine. See attached screenshot and skin for an example.",jeroen Backlog Release,1974,Flash player doesn't show divider left of CC button,skinning,,bug,jeroen,new,2013-05-03T09:43:55-04:00,2013-05-03T09:43:55-04:00,"If a player has only a CC button and on HD one, the Flash player doesn't show the divider left of the CC button. The HTML5 player does so. See attached screen and skin for an example.",jeroen Backlog Release,1979,playIcon not hiding in HTML5 when removed from skin,skinning,,bug,jeroen,new,2013-05-09T12:21:56-04:00,2013-05-09T12:21:56-04:00,"When removing the (re)playIcon assets from a skin, the (re)play icon should be removed from the player. * This works great in Flash * However, in HTML5, the edges are still displayed. They should get hidden as well. Note the buffer and error icon would still show up for this skin, which is indeed the case in both Flash and HTML5.",jeroen Backlog Release,1980,Controls option + API ignored by inStream,advertising,,bug,jeroen,reopened,2013-05-09T12:41:21-04:00,2013-06-11T13:24:14-04:00,"The instream API ignores the ''controls=false'' configuration option and the ''setControls()'' API call. It should honor these though, showing/hiding the controlbar just like with regular videos. Note the banner at the top of the screen doesn't have to be toggled for visibility. We're removing that banner and putting that text in the controlbar for 6.6.",jeroen Backlog Release,1991,"In HTML5, over/active listbar description colors are not picked up",skinning,,bug,jeroen,new,2013-05-23T16:43:50-04:00,2013-05-23T16:43:50-04:00,"... In Flash mode, they do work. This can be verified e.g. with Bekle.",jeroen Backlog Release,1998,"When removing a dockbutton, the tooltip sticks around in Flash",scripting,,bug,jeroen,new,2013-06-03T09:27:43-04:00,2013-06-03T09:27:43-04:00,"When a dock button is programatically removed in Flash mode, the tooltip sticks around. This does not happen in HTML5. See attached HTML for an example. Removal of dock buttons is often used, e.g. when swapping buttons (slomo/fastmo). ",jeroen Backlog Release,1999,Override max-width:100% CSS property on video tags,embedding,,bug,jeroen,new,2013-06-03T14:04:47-04:00,2013-06-18T17:56:32-04:00,"A common CSS rule with responsive setups is a ''max-width'' of '''100%''' on video tags (we've seen this on e.g. some WordPress sites). This setup breaks scaling the video tag in JW Player in HTML5 mode in certain setups though. Therefore, we should reset this ''max-width'' property for JW Player video elements. Attached is an example setup that demonstrates the issue.",jeroen Backlog Release,2001,Issue decoding specific HLS AES stream,streaming,,bug,jeroen,new,2013-06-04T16:44:01-04:00,2013-06-04T16:44:01-04:00,"The test stream ''class/playlist'' is AES decrypted, but does not work in JW Player. It does work in both iOS, Safari and VLC though. The stream contains an HTTP key file and custom IV.",jeroen Backlog Release,2003,VAST/HTML5 breaks on bare bones tags,advertising,,bug,jeroen,new,2013-06-06T14:46:51-04:00,2013-06-11T17:57:20-04:00,"I've noticed a few bugs having to do with Vast responses that do not contain some optional elements. Our testing was using feature-rich Vast responses, hence these bugs slipped through. When the Vast response doesn't have them, it results in a null dereference in the plugin. Missing elements that cause errors include: * no Impression tracking * no Companions * empty VAST (i.e. no ad to show) We should setup a couple of test tags that mimick these items and fix the implementation. There's also [http://ox-d.ad-mesh.net/v/1.0/av?auid=420749 this] live OpenX tag. ",alex Backlog Release,2004,IMA AdSense overlay tags appears as linear,advertising,,bug,jeroen,new,2013-06-11T18:28:51-04:00,2013-06-11T18:28:51-04:00,"The attached AdSense tag appears as a takeover linear one in the IMA client, but it should be shown as an overlay (as the last parameter in the tag suggests). It looks like we're detecting something wrong here in this tag - maybe related to that this tag can be used for both linear and nonlinear. ",jeroen Backlog Release,2005,Specific onAdError setup has two issues,advertising,,bug,jeroen,new,2013-06-17T14:24:39-04:00,2013-06-17T14:24:39-04:00,"Attached VAST waterfall setup seems to highlight two issues in our VAST parser: 1. The fastclick tags both somehow seem to break our fallback logic. This can be seen in the console (""error calling back an event handler""). The result of this is that the fallback chain breaks. 2. The doubleclick tag (a wrapper for an adtech VPAID ad) actually seems to trigger onAdError, while it's not empty. The result of this is that the video (or next ad) plays on top of the VPAID. ",jeroen Backlog Release,2006,M3U8 parsing issue playing specific HLS live stream,streaming,,bug,jeroen,new,2013-06-18T16:49:38-04:00,2013-06-18T16:49:38-04:00,"Some live HLS streams from avvion ([http://31.45.244.233/Content/HLS/Live/Channel(Kanal1)/index.m3u8 example]) break after 10 seconds because the player tries to load a URL like this: {{{ http://31.45.244.233/Content/HLS/Live/Channel(Kanal1)/Stream(03)/#EXT-X-PROGRAM-DATE-TIME:2013-06-17T13:19:17Z }}} It seems this is due to a small manifest parsing issue, triggered by the following sequence of data: {{{ #EXTINF:10, #EXT-X-KEY:METHOD=NONE #EXT-X-PROGRAM-DATE-TIME:2013-06-17T18:32:00Z Segment(13714939200000000)/segment.ts }}}",jeroen Backlog Release,2007,Some VAST tags from DFP not working on Android 4.0,advertising,,bug,jeroen,new,2013-06-18T17:48:52-04:00,2013-06-18T17:48:52-04:00,"The ''visacard'', ''earthzoom'' and ''xxxgold'' tags from our VAST test suite don't work on Android devices with the ''Browser''. Not sure what's up though - looks like an issue with the XML parsing? On Android/Chrome and iOS/Safari the tags work great.",jeroen Backlog Release,1618,Only reload active HLS playlist for live streams,streaming,,enhancement,jeroen,new,2012-03-27T08:38:46-04:00,2013-05-15T14:25:30-04:00,"For live, all manifests are currently re-fetched during playback. With many quality levels, this leads to a lot of overhead. It's better to only reload the current level and do just-in-time reloads for the new level upon switches.",jeroen Backlog Release,1661,Clear timeouts and intervals on destroy,embedding,,enhancement,pablo,new,2012-05-31T13:15:13-04:00,2013-05-24T15:01:16-04:00,"If the player is destroyed, the internal intervals and timeouts are not automatically cleared. This can cause problems with event listeners and other integrations.",pablo Backlog Release,1738,Support custom quality labels for SMIL/M3U8,streaming,,enhancement,jeroen,new,2012-10-17T06:14:37-04:00,2013-05-30T16:19:47-04:00,"Right now, it's only possible to set a quality label using playlists. We should update this, supporting custom labels in all scenarios: * SMIL manifests * M3U8 manifests We can do this by supporting: * ''NAME='' for M3U8, per [https://developer.apple.com/library/ios/#technotes/tn2288 this Apple tech note] * ''''title='' for SMIL, per the [http://www.w3.org/TR/REC-smil/#media-object SMIL 1.0 spec] This would not allow publishers to set the labels if they have no control over the manifest rendering. However, it would nicely package the labels along with other quality info. === M3U8 Example === {{{ #EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1600000,RESOLUTION=1280x720,NAME=""720P HD"" 1280/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=832000,RESOLUTION=640x360,NAME=""360P SD"" 640/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=320000,RESOLUTION=320x180,NAME=""180P 3G"" 320/prog_index.m3u8 }}} === SMIL Example === {{{ }}}",jeroen Backlog Release,1849,"Use ""heading"" for sharing/related dock button tooltip",interface,,enhancement,jeroen,new,2012-12-14T16:48:14-05:00,2013-06-03T21:01:13-04:00,"Right now, the sharing/related dock buttonlabels are hardcoded. We should however re-use the ""heading"" texts for these labels. It would make the labels configurable.",jeroen Backlog Release,1857,HLS: extract aspect ratio from VUI parameters,streaming,,enhancement,jeroen,new,2012-12-15T17:18:14-05:00,2013-05-24T14:55:01-04:00,"The H264 SPS VUI parameters store the dimensions of a stream. Currently, we don't read those in our HLS provider, using the manifest RESOLUTION tag instead. Parsing the VUI would remove that dependency. Note the VUI parameters are [http://en.wikipedia.org/wiki/Exponential-Golomb_coding Exp-Golomb encoded]. Fun!",jeroen Backlog Release,1862,Follow FCC or WebVTT recommendations for scaling captions,interface,,enhancement,jeroen,new,2012-12-18T09:58:07-05:00,2013-06-03T20:50:04-04:00,"Scaling of captions now sometimes result in breaking out of the player. See this example: http://courses.mindedgeonline.com/jwplayerexample.html I think what's needed to correct this is a removal of some of the ""auto scaling"" logic that's part of the captions now. Instead, we should adhere to the FCC requirements around this. Needs some defining first.",jeroen Backlog Release,1899,Uninterrupted playback of (repeating) videos,interface,,enhancement,jeroen,new,2013-01-31T09:10:28-05:00,2013-06-18T17:54:44-04:00,"Currently, repeating/advancing videos result in some interruptions around transition moment: 1. When repeating a video, a black screen is displayed shortly before replay starts. 2. When advancing from one playlistItem to the next, the poster image is shortly flashing in between. 3. (Flash only) The buffer icon is flashing shortly during the advance. It'd be nicer to only fade in the bufferIcon after e.g. 1s. As a publisher, I would want videos to advance or repeat smoothly, without any poster images, black frames of buffer icons flickering in. ",jeroen Backlog Release,1903,Force a switch when going to/from Auto quality,streaming,,enhancement,jeroen,new,2013-02-05T06:21:10-05:00,2013-05-24T14:55:50-04:00,"For both RTMP and HLS, we currently do a smooth switch in response to the following actions: * The quality is not set to ''Auto'' and the viewer selects the ''auto'' option. * The quality is set to ''Auto'' and the viewer selects the bitrate option that currently happens to be selected by the auto-algorithm. Instead of a smooth switch, we should do a ''hard'' switch for these two situations as well. This will result in re-buffering, but: * It's then clear to the viewer something happens in response to their selection. * The switch in response to the viewer selection won't disrupt the adaptive heuristics (which is the case right now). Note that, after this update, every quality selection will result in a ''hard'' refresh of the stream. The only ''smooth'' switches occur during playback of the stream in ''auto'' mode. As part of this, we should also fix the problem that right now, after coming from a cookie, it's not possible to set a stream to Auto. This issue can be checked [http://www.longtailvideo.com/support/jw-player/29393/hls-adaptive-stream on our demopage] with these steps: 1. set 360p 2. refresh the page 3. try to set Auto (fails) 4. set 180p or 720p 5. set Auto (works) ",jeroen Backlog Release,1933,Support HLS 302 redirects on M3U8 manifests,streaming,,enhancement,jeroen,new,2013-03-11T08:52:09-04:00,2013-05-24T14:56:05-04:00,"At present, JW Player doesn't support 302 redirects on M3U8 manifests. The issue is that the 302 isn't taken into account when generating the URLs to the TS fragments. Attached screenshot shows what's going wrong. We should figure out a way to detect the redirects in Flash to create the correct the URLs to the TS fragments.",jeroen Backlog Release,1935,Ignore 404 HLS playlists instead of error out,streaming,,enhancement,jeroen,new,2013-03-12T10:38:27-04:00,2013-06-03T20:56:41-04:00,"Sometimes (Akamai in particular), several M3U8 playlists in a manifest give a 404 error. The iOS player quietly discards these playlists, but JW Player actually errors out the entire stream. We should follow what iOS does here and discard the 404 playlists. As long as there's at least 1 playlist in the manifest that does work, the stream can be played. See the attached screenshot for more details on the error.",jeroen Backlog Release,1938,Investigate patch for better RTMP bitrate switching,streaming,,enhancement,jeroen,new,2013-03-12T10:47:00-04:00,2013-05-23T16:30:10-04:00,"A publisher sent us a patch to improve bitrate switching for RTMP (attached). We should investigate his changes to see which ones are good to incorporate. Note RTMP switching in JW6 is definitely more conservative than JW5. Basically, if bandwidth increases, JW6 will still be very reluctant to switch up.",jeroen Backlog Release,1948,Load fragment N-2 for HLS live streams,streaming,,enhancement,jeroen,new,2013-03-26T11:08:25-04:00,2013-05-24T14:54:18-04:00,"For HLS live streams, the player should load fragment N-2 instead of N-1. This issue was overlooked in ticket [1811]. The player should follow the HLS spec to determine which media segment is played: [http://tools.ietf.org/html/draft-pantos-http-live-streaming-05#section-6.3.3 HLS Specification] ",ed Backlog Release,1984,Correct for drifts between playlist and mediastream in HLS,streaming,,enhancement,jeroen,new,2013-05-15T18:40:44-04:00,2013-05-15T18:40:44-04:00,"With certain streams, the fragment durations reported in the M3U8 are different from the actual durations of the TS fragments. This can lead to issues on both the vod and live side: * For VOD, the timeSlider may over-report or under-report for the duration of the stream. In the first case, the video stops half-way. In the second case, the timeThumb runs beyond the right side of the timeSlider. * For Live, the player is slowly but surely under- or overbuffering, leading to an ''infinite buffer'' loop in both cases. I created two VOD test playlists to check this issue: * ''oceans/toolong.m3u8'' * ''oceans/tooshort.m3u8''",jeroen Backlog Release,1990,Sharing UI: new FB/TW icons and no labels,interface,,enhancement,jeroen,new,2013-05-22T17:11:34-04:00,2013-05-22T17:11:34-04:00,"Good feedback from customers on Sharing: * The Facebook and Twitter icons we use are a bit outdated. We should use the latest versions (attached). * A small redesign of the input elements allows us to remove the labels (attached) We should implement both, e.g. with a newt update of the Sharing functionality. ",jeroen Backlog Release,1994,Improve 404 fragment skipping for HLS live,streaming,,enhancement,jeroen,new,2013-05-24T09:24:02-04:00,2013-05-24T09:24:02-04:00,"At present, for live HLS we always try to re-fetch the active segment if it 404s. This makes the player always go into an infinite loop if there's a 404 fragment. Instead, if there's a 404 fragment, we should keep reloading the manifest. If the current fragment is the last, we re-try that one. If it's not the last, we skip the 404 and load the next fragment.",jeroen Backlog Release,2000,Support or disable HTML5 fullscreen in iFrame,interface,,enhancement,jeroen,new,2013-06-04T16:20:46-04:00,2013-06-04T16:20:46-04:00,"Currently, JW Player does not officially support HTML5 fullscreen inside an iFrame. This leads to strange behaviour, such as: * The player attempting to go ""full iframe"" on IE and Safari. * The player going fullscreen, but with an offset controlbar on Chrome/FF. We should detect if the player is in an iFrame and then either have actual working fullscreen or hide the FS button. Attached are two HTML files to test HTML5 iFrame fullscreen behaviour. Note the iframe tag in the container HTML file does contain the '''allowfullscreen=true''' attribute that's needed to support actual fullscreen. If it's not set, Firefox/Chrome will also go ""full iFrame"". Also see [http://brad.is/coding/BigScreen/ this JavaScript library] for some tricks on e.g. detecting if allowFullScreen is set or working around a bug with FS in Safari.",jeroen Backlog Release,782,Cuepoint functionality,scripting,,feature,jeroen,reopened,2010-03-21T23:38:51-04:00,2013-06-14T15:51:35-04:00,"Proposal to include the ability to add cuepoints to playlist items, which would be visible in the controlbar, and would result in an event being fired when they are played. If possible, we should conform this mechanism to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-track-element track element] (should that move forward swiftly). === Cases === Here's a couple of applications for cuepoints: * subtitles, captions, karaoke (like DVD) * chapter or slide markers (like Hulu) * annotations/descriptions (like Youtube) * metadata (programmatical 'custom' data) Note we are only talking about the mechanism to add these cuepoints to the player. The logic and UI to process and/or display these cues is not part of this mechanism. However, on top of this mechanism one could build something like: * A multilanguage subtitles plugin. This plugin would listen to cuepoint events and display the description of the event at the bottom of the screen. * A powerpoint slide-sync plugin. This plugin would listen to cuepoint events and display the thumbnail and description of the event in a separate area, next to the video. Markers in the controlbar show the slide transitions. When hovering a marker, a thumb of the slide is shown. * A mid-roll advertisement plugin. This plugin would listen to cuepoint events to pause the main video and play a midroll advertisement. When the ad is completed, the video is resumed. Markers in the controlbar show the advertisement. When hovering a marker, the description (e.g. ''Old Spice Advertisement'') is displayed. * A user annotation plugin. This plugin would listen to cuepoint events to display info bullets on top of the video. === Data === A cuepoint would contain the following data: * ''type'': description of the type of event (e.g. ''caption'' or ''powerpoint''). Has no programmatical consequences - just for keeping track. * ''position'': position of the cuepoint in the mediafile, in seconds. * ''marker'': Add marker to the controlbar. Can be ''true'' or ''false'' (the default) * ''text'': description of the cuepoint, as (HTML) text. Displayed in the controlbar if marker==true. * ''thumb'': URL to a thumbnail of this cuepoint. Displayed in the controlbar if marker==true. * ''data'': Data of the cuepoint, for the plugin that uses it. For example, the text for a caption, or the position, color and contents of an annotation balloon. === API === The API for managing cuepoints is: * player.addCuepoint(playlistItem, {cuepoint}); * player.removeCuepoint(playlistItem, {cuepoint}); * player.getCuepoints(playlistItem); Cuepoints can also be added to a video (playlistitem) by means of an XML file, loaded with the flashvar or playlist item element ''cuepoints''. For example: {{{ chapter 23 true Chapter 1: Takeoff http://www.mysitecom/chapter1.png }}} === Event === Plugins and tools can get cuepoint data to listen to a new event. For example: CuepointEvent..JWPLAYER_CUEPOINT:: Note that, when a user jumps beyond a cuepoint, the cue will be fired. For example: * Cuepoint is set at 05:00. * User starts video. * User jumps to 6:00. * Cuepoint event is fired. * User jumps to 5:30. * User jumps to 4:30. * User jumps to 5:30. * Cuepoint event is fired.",pablo Backlog Release,1214,Add YouTube support for HTML5,embedding,,feature,jeroen,new,2011-01-25T16:26:43-05:00,2013-06-18T17:55:07-04:00,"I was reading this (http://apiblog.youtube.com/2011/01/introducing-javascript-player-api-for.html) and noticed that there's now an iFrame API: http://code.google.com/apis/youtube/iframe_api_reference.html It's missing a bunch of stuff, but I think we could make it work assuming we a.) stick with the native controls on iOS and b.) the player resizes to fill the iFrame. They don't guarantee all of the functions work, but perhaps enough do?",zach Backlog Release,1644,"Support ""sliding window"" DVR in HLS",streaming,,feature,jeroen,new,2012-04-27T04:34:41-04:00,2013-05-20T11:32:23-04:00,"With HLS, live streams are implemented using a ''sliding window'' model. If this window is large (e.g. >5min), we could layer additional UX on top of the player to support seeking into this window and jumping back to the ''Live'' playhead. * Attached are screenshots from other DVR interfaces. Note that some of these don't work for us, since the interface presumes knowledge of the start + duration of a DVR stream. * Also attached are mockups of the timeslider playback state for different stream types. In order to implement this correctly, we have to make updates to the providers, API and controlbar. === Providers === On a provider level, we should ensure that the correct ''onTime()'' and ''getDuration()'' events are fired: * For VOD, we do what we do today: ''duration'' is the media duration and onTime() is fired multiple times / second when playing. * For live (RTMP + HLS + HTML5 iOS/Safari), we set ''duration'' to -1 for live streams and fire a single ''onTime()'' event every time the PLAYING state is entered. * For DVR (only HLS in Flash), HLS, we: * Set ''duration'' to -(dvr seeking range), where the DVR seeking range is defined as the duration from the oldest fragment until N-2 (the live head). This because we shouldn't allow users to seek beyond the live head and trigger buffer underruns. * Set ''position'' to -(distance from live head) * Fire time ticks every fragment load (not multiple times/second), in both PLAYING and PAUSED state (not just PLAYING). Note the difference between HLS Live and DVR is the window size. Live playlists that have > 60s data are DVR, others are live. === API === On an API level, we can support the different playback states as follows: * ''Idle'' (before playback starts): getDuration() returns 0 and no time ticks. * ''Ondemand'': getDuration() > 0 and multiple time ticks / second on playing. * ''Live'': getDuration() = -1 and only a single time tick on playing. * ''DVR'': getDuration() < -60 and time ticks every fragment load on playing AND paused. Note that components and scripts shouldn't have to listen to the onMeta() call to determine which stream type a playlistItem is. simply listening to the first onTime() tick will tell them enough. === Controlbar === A mockup of the controlbar for the 4 stream states is attached. The ''live'' and ''dvr'' states are new: * For ''live'', we display the text with the same styling as elapsed/duration texts. Note a separate ticket (#1690) is available for this. * For ''dvr'', we can re-use all existing skinning elements. Since timing is only updated every fragment load, it should feel like a ''slow'' version of the ''vod'' state. If the fragments are always the same length, nothing should move during playback and the thumb should jump backward every fragment load when pausing.",jeroen Backlog Release,1673,Define keyboard focus and shortcuts,interface,,feature,jeroen,new,2012-07-13T11:51:33-04:00,2013-06-18T17:54:50-04:00,"At present, there's no clear model for managing mouse/keyboard focus in the player. This leads to such issues as: * When keyboard tabbing through an idle HTML5 player, the hidden buttons are actually accessible and working, leading to un-anticipated player states. * When tabbing in a playing HTML5 player, buttons are disappearing again. * When a Flash player with visible controlbar completes, the controlbar stays visible. The logo does hide though. * In HTML5, the controls stay visible when hovering them. In Flash the controls hide after a timeout. * In both Flash and HTML5, the controls still hide when the mouse hovers the display. * In Flash, the ''play'' icon highlights when hovering the controls or sidebar. We should define and implement an easy to understand model for focus and keyboard control. Next, we can implement a set of shortcut keys that are available to the viewer when the player is in focus: * Space: play/pause toggle * Left/right: seek forward and backward 10 seconds * Up/down: raise or lower the volume by 10 percent ",pablo Backlog Release,1695,Display chapter markers in controlbar,general,,feature,jeroen,new,2012-08-30T05:12:21-04:00,2013-06-03T21:00:00-04:00,"Splitting up long-form media in chapters improves its discovery and navigation. We should support this in JW Player: * VTT is used as a metadata format. It already describes a specific ''chapters'' function. * We solely support chapter titles in the cues. * Chapter points are marked on the controlbar with a distinct ''dot''. * When hovering these dots, the chapter title can be displayed. * When clicking a dot, the media seeks to that chapter start position. * We can also provide an option to display the chapters in the listbar.",jeroen Backlog Release,1729,Closed Captions support in HLS,streaming,,feature,jeroen,new,2012-10-10T08:32:08-04:00,2013-06-03T20:56:08-04:00,"iOS supports closed captions in HLS, as 708/608 data packed in AVC SEI RBSP units: HTTP Live Streaming supports adding closed captions to streams. If you are using the stream segmenter, you need to add CEA-608 closed captions to the MPEG-2 transport stream (in the main video elementary stream) as specified in ATSC A/72. We should investigate support in Flash for these. Some references: * http://en.wikipedia.org/wiki/CEA-708 * http://en.wikipedia.org/wiki/EIA-608 * http://www.atsc.org/cms/index.php/standards/standards/57-atsc-a72-standard Here's some constraints for the initial round of support: * Only one track needs parsing (like RTMP), since we target CC and not multi-language. * All text positioning and styling date can be ignored (again like RTMP). Only the textcues + timing are needed. We have one example stream (''captions/playlist''), plus [http://content.bitsontherun.com/videos/D9rygobt-eE9soefF.mp4 an example stream] containing 608 data (to load into Wowza).",jeroen Backlog Release,1753,Expose ID3 metadata embedded in HLS streams,streaming,,feature,,reopened,2012-10-31T11:57:05-04:00,2013-06-14T15:48:06-04:00,"As [http://jmacmullin.wordpress.com/2010/11/03/adding-meta-data-to-video-in-ios/ this blog post describes], it is possible to embed ID3 metadata in HLS streams and use that to setup video-page interaction. Overall, this is a feature we are tracking (#782), but our implementation will likely standardize around VTT files. This works for all formats, on desktops and devices, in HTML5 and Flash. ID3 data in HLS is a valid additional use case for live streams though, since in such a setup it's nearly impossible to live-update a separate VTT file (and also keep timing right). We've seen the same reasoning with XMPP data in RTMP.",jeroen Backlog Release,1992,Support elementary audio streams for HLS,streaming,,feature,jeroen,new,2013-05-23T17:34:13-04:00,2013-06-04T16:51:25-04:00,"Currently, our HLS provider solely supports MP3 or AAC audio inside TS. Elementary audio is more efficient though, plus fairly frequently used. According to Wowza, supporting this shouldn't be a big deal: It is pretty simple. ID3 tag at the beginning with the starting timecode for the chunk. That is followed by the raw samples. The AAC samples have ADTS headers: http://wiki.multimedia.cx/index.php?title=ADTS You can get the packet size from the header. For MP3 they are MP3 (4-byte headers) one after another. So no big deal. We have two example raw AAC streams: * ''guitar/prog_index'' * ''jazzy/prog_index'' Plus the ability to stream raw MP3/AAC with our Wowza testserver.",jeroen Player 6.6 Release,1687,"Add ""basic"" listbar layout option",interface,,enhancement,jeroen,new,2012-08-23T08:29:39-04:00,2013-06-03T20:43:39-04:00,"This option allows publishers to easily set a more nimble playlist. Fits more items per pixel and doesn't require publishers to provide images/descriptions. Requirements: * New ""listbar { layout:'basic|extended' }"" configuration option. * Default is the 6.0 state (""extended"") * New is ""basic"" state * In ""extended"" state, items are 76px high * Change from 6.0, where height of the ""item"" element was used * Works with all LT skins though, plus with spot-checked 3rd party skins * So instead, the ''item'' elements are vertically stretched. * Allows for lower bytesize ""item"" elements (1px high) * Thumb element is still placed on left, with same values for top/left/bottom margin. * Title and description elements are placed with 10px margin. * Title is always 1 line, the text baseline is y-positioned at 24px from top. * Description is always 2 lines, with line-height of 18. The first line text baseline is y-positioned at 44px from top. * In ""basic"" state, listbar items are 32px high * Only the title is displayed, image and description are not * Title is vertically centered (e.g. line-height:32) and left-aligned with 10px left-margin. * The ''item'' elements are again vertically stretched to 32px.",jeroen Player 6.6 Release,1690,Live streaming controlbar state,interface,,enhancement,jeroen,new,2012-08-26T07:49:01-04:00,2013-06-03T20:54:25-04:00,"In the JW6 wireframes, we specced out a state for the controlbar in ''live streaming'' mode, that differs from regular streaming: * Elapsed time, time slider and duration are hidden. * To the right of the ""play"" icon, the title of the playlist item is displayed. * Using exactly the same skinning options (font, color, etc) as the ""elapsed'' time * If no title is set in the config, we default to the string '''Live broadcast'''. Note that live streams are supported for both HLS and RTMP. They can be detected by a duration of ''-1'' that's sent along with ''onTime'' events.",jeroen Player 6.6 Release,1805,Display dock buttons in IDLE state,interface,,enhancement,jeroen,new,2012-11-21T07:52:16-05:00,2013-06-03T20:45:00-04:00,"In the IDLE state, dock buttons should be visible 100% of the time (just like in the COMPLETED state). This because: 1. Many dock button features should be available before playback. Examples: * Resize the player * See related videos * Select rendering mode 2. On mobile, the dock functionality is now very much hidden (only on COMPLETE). 3. Javascript developers don't immediately see the dock buttons they insert, so they think the API is broken. ",jeroen Player 6.6 Release,1997,Re-introduce horizontal volume slider,skinning,,enhancement,jeroen,new,2013-05-31T10:03:00-04:00,2013-06-03T20:52:57-04:00,"We received plenty feedback on the change to a vertical volume slider for 6.0. Some of it was ''just cause'', but there is a clear use case around audio-only, in particular background audio (podcasts, radio). Therefore, we should re-introduce the horizontal volume slider, as an option in the skinning model: * The vertical volume slider lives in the '''tooltip''' component and has the following components: * volumeCapTop, volumeCapBottom * volumeRail, volumeRailCapTop, volumeRailCapBottom * volumeProgress, volumeProgressCapTop, volumeProgressCapBottom * volumeThumb * The new horizontal volume slider will live in the '''controlbar''' component and has the following properties: * volumeCapLeft, volumeCapRight * volumeRail, volumeRailCapLeft, volumeRailCapRight * volumeProgress, volumeProgressCapLeft, volumeProgressCapRight * volumeThumb * If both volume sliders are available in the skin: * And there's room for the vertical slider (i.e. no audio mode), the vertical slider is drawn and the horizontal not. * And there's no room for the vertical slider (i.e. audio mode), the horizontal slider is drawn. Half our built-in skins will get a horizontal volume slider. See e.g. attached update of Modieus.",jeroen Player 6.6 Release,1154,Skinning for Touch devices,skinning,,feature,jeroen,new,2010-12-13T14:44:53-05:00,2013-06-03T20:43:53-04:00,"With the latest iOS release for iPad, it's now possible to visual elements on top of the