0

Using currentTime with <video> element

Jean Michel

March 27, 2017 15:23

None

Follow

I'm using the latest firmware version I see for XD2 series is 6.2.94, but as far as I can tell, video seek still doesn't work. I'm trying to position a HTML5 <video> by setting its currentTime to a value. When I do so, it seems to jump to a "random" position. I.e., nowhere near where I tell it to go. For example, if I tell it to go to 0.5, it typically ends up somewhere around 11-14 seconds.

Is this supposed to work, or is this a known "issue"?

Can this problem be caused by how the video is encoded (i.e., CBR, VBR)?

Does anyone know if this has been improved/fixed in the newer generation of players?

-JM

• Facebook
• Twitter
• LinkedIn

8 comments

• 0
  
  Romeo March 28, 2017 07:58

  Hi Jean-Michel,

  You can only seek to the next/previous I-Frame so if you want to seek in increments of 0.5 seconds then make sure to use the appropriate GOP structure when encoding your video file so there is an I-Frame that is close enough to the desired position.

  Regards,

  Romeo

   

• 0
  
  Jean Michel March 28, 2017 08:26

  Thanks for your reply!

  What happens if there's no keyframe at the seeked-to position? Will it go to the nearest keyframe, or just fail?

  Does CBR/VBR make any difference?

  Does this limitation hold also for roVideoPlayer, or does it only apply to HTML5 <video>?

  -JM

   

• 0
  
  Romeo March 28, 2017 10:05

  > What happens if there's no keyframe at the seeked-to position? Will it go to the nearest keyframe, or just fail?

  It will go to the next I-Frame.

  > Does CBR/VBR make any difference?

  No it does not. You just need to ensure that the video is within the recommend specs as per below:

  http://support.brightsign.biz/hc/en-us/articles/218065137-Supported-video-formats-and-codecs

  > Does this limitation hold also for roVideoPlayer, or does it only apply to HTML5 <video>?

  This is valid for both cases.

  Regards,

  Romeo

• 0
  
  Jean Michel March 28, 2017 13:05

  Thanks.

  I've made some further investigation into this issue now, and believe I have narrowed it down.

  Essentially, things work pretty much as expected when playing the video from a local file on the SD card. However, when setting the src URL of the video to point at a web server instead, seek operations no longer work properly.

  I have a simple and 100% reproducible test case that shows the problem I'm seeing. What's the best way to submit this test case? It includes a small test video, so it's about 3 MB in size.

  -JM

• 0
  
  Romeo March 28, 2017 13:28

  >Essentially, things work pretty much as expected when playing the video from a local file on the SD card.

  Indeed, that's the ONLY way we do support seeking to a position in a file. Sorry I should have thought of mentioning this earlier.

  Regards,

  Romeo

• 0
  
  Jean Michel March 28, 2017 14:03

  So you're saying that seeking in HTML5 <video> playing from a server is not supported by any BrightSign players?

  Is this documented anywhere?

  I would consider this a rather serious limitation, as pretty much any other device (including the cheapest ChromeBoxes/ChromeSticks as well as the fairly basic players in, e.g., the Samsung SSSP3 displays) support this rather basic function.

  -JM

• 0
  
  Ben Benjamin April 06, 2021 23:31

  Hey there, old thread but having a related issue: we're seeing a rather large difference between the currentTime reported by chromium and the actual rendered video -- for example, if triggering an event in javascript when currentTime is >= 5 seconds, the events appear to happen too early.. Chromium reports the video element time at 5.x seconds when the rendered video itself is closer to 4 seconds. This is problematic as we're building a sequence of keyframes for the video to "seek" between, pausing itself when it crosses a designated stop point. The play/pause events happen instantly, but the currentTime is quite off. The issue persists with HWZ on/off. Is there a method of getting more accurate currentTime reporting from the player?

• 0
  
  Jean Michel April 07, 2021 07:38

  Yes, I've seen the same. I believe the connection between the video playback engine and the browser is rather poor in this area, since there's often severan hundred mS discrepancy between the actual video and the time reported by the <video> tag.

  -JM