Started to use videojs.
When the download rate is slow and the video get stuk (while buffering) I get a very strange "jumping lines" effect.
Any ideas ?
Please take a look at the following short video :
https://www.youtube.com/watch?v=665XbXyz8Y8&feature=youtu.be
thx
Sagi
That's the loading spinner, but you must have some CSS that's altering its appearance. Look for styles you have targeting .vjs-loading-spinner.
Related
Im using blender to edit a video and when i try to render it, it comes up with the error: border rendering is not supported by sequencer.
Using blender 2.80
Disabling Render Region fixed the problem for me.
Turning off border rendering (render region blender 2.8) in Rendering -> Properties -> Output properties
fixed it for me.
I recall playing with menus and the hypothesis is that I checked it somewhere along the way to cause that problem in the first place.
I cant comment yet bc of reputation apparently, so I guess I have to leave my comment behind here. I do have an answer but I'm not sure if it is a correct one.
I had the same problem, and I think i fixed it by unchecking the sequencer box under Post processing in the same tab as where you edit the format and encoding etc. But now that it does let me render my video (just a picture with audio under it) the render result is audio only? Could be a seperate problem or part of this solution, idk. Would unchecking that box help for you?
In my project I'm using swiper.js as a slideshow, each slide either contains and image or a html5 video with webvtt captions / subtitles.
On debugging, we noticed that the subtitle position is wrong (too low, cuts off screen) on webkit browsers.
After much debugging it turned out that this css3 rule on the parent div (the swiper-wrapper) makes the vtt position wrongly:
transform: translate3d(-1024px, 0px, 0px)
When you put the video in the first slide, all goes well, since there's no css translate yet.
This seems to be a core webkit issue: default webvtt positioning breaks when using css translation on a parent.
The workaround I found is to add a line positioning in the vtt itself to every subtitle element, like so:
WEBVTT
00:00:02.160 --> 00:00:06.440 line:90%
hello world
00:00:06.560 --> 00:00:11.920 line:90%
testing subtitles
Any sentence without the "line: 90%" part is rendered partly offscreen. It seems this setting forces the webvtt parser / renderer to set itself to the correct position.
QUESTION: did anyone encounter this issue yet and is there any other (easier) workaround for this bug? Adding the "line:" part to all subtitles would be a hell of a job.. unless there's a good editor that can do that stuff in batch.
QUESTION 2: Since this seems to be a webkit vtt parser bug, anyone know where to best report this?
Test setup here: http://orgonemedia.nl/webvtt-bug/
I'm currently debugging some WebVTT files for English captions and other languages too. I'm experiencing a similar problem, although I can't say what is exactly causing it. I'm going to try the line:90% fix you've suggested here.
ANSWER TO YOUR QUESTION 1: Regarding the job of adding it to all the subtitles, you'll be happy to know that's actually pretty easy with the right tool. I use Sublime Text Editor. The way I would do it is use "Find all" to find all the occurrences of -->, then simultaneously edit each of those lines, using the arrow key to navigate across to the right place on the line (since each subtitle out-time is the same number of characters, 12), then type in line:90%
UPDATE:
So I implemented your suggestion, using the method I outlined, and it successfully repositioned my captions.
More details: I was only experiencing the problem of captions being half off the bottom of the video when viewing on an iPad. Oddly enough, viewing the same page on an iPhone, they were positioned correctly without any change. The 90% change still adjusted it up though.
Intriguingly the line:90% code does nothing to adjust caption position when viewing the page on Chrome.
I'm having trouble getting much at all to display on Safari desktop. I think there's something invalid about my file format, but I'm darned if I can find it.
When editing the captions through my video hosting service's caption editor (I'm using JWPlayer), the timecodes show up as being invalid:
Image showing caption editor with invalid warning
There seems to be a huge issue with the iframe url parameter "vq" (in this case "vq=hd720").
If you use this paraneter, the video screen in the flash player turns black.
This example URL worked until today:
http://www.youtube.com/embed/dFVDJlM6zLY?vq=hd720
(feel free to replace the example YouTube ID)
Now, this example works only without the "vq" parameter (vq=hd720):
http://www.youtube.com/embed/dFVDJlM6zLY
The problem is, that we delivered this YouTube iframe in a lot of websites for a lot of clients and it worked quite well for month (years?). Now every single site has black youtube videos!!!
Does anyone know if this parameter was depricated?
Was there a new YouTube API release today?
The parameter was already discussed and recommended in diffrent forums:
e.g. Force youtube embed to start in 720p
Any ideas how to force Google (YouTube) to solve this problem?
It seems that the only way out of this (currently) is to remove the vq parameter or set it to auto. This seems like a widespread problem though, that has occurred very recently. You may wish to star this issue at google make them take notice:
https://code.google.com/p/gdata-issues/issues/detail?id=6009
I was having a similar issue but when I tried to force an embeded youtube video to play in HD at a dimension smaller than the HD resolution.
I was able to get around the "black screen" HD issue by using the old embed code.
If you set the video size to the highest resolution you can then use vq=hd720 parameter and set the video width and height to a lower resolution
<object width="1280" height="720"><param name="movie" value="//www.youtube.com/v/VIDEO_ID?hl=en_US&version=3&rel=0&vq=hd720"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="//www.youtube.com/v/kyilUYoxcww?hl=en_US&version=3&rel=0" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>
Hope this helps!
Just had this exact problem. Found changing it to vq=auto works in the code. But on the videos we're working with it's coming out at a slightly lower quality than we'd like.
Nevertheless, this at least removes the blackout.
What are your 3d settings set to? Here's what I've noticed...
1) Taking away the vq=hd setting works.
2) Turning the 3D setting on the video player ON (or sometimes OFF the ON again) makes the
video work.
3) Curious about number 2, I went to the video settings on the video (the admin settings) and changed the 3D settings under Advanced. I changed it from "Disable 3D for this video" to "Please make this video 3D." For some reason this works -- the vq code is back to working the way it should.
HOWEVER I don't know if I would recommend doing this! The reason I set all my videos to "Disable 3D for this video" in the first place was because if I left on on the on the default "No Preference," it often caused glitches in the video.
Has YouTube changed anything with the 3D settings recently? I think thay may have but am not certain.
I am trying to build a site using video.js to view videos. We need to switch videos while maintaining the currentTime value from the old video. The way I have it working right now is using the loadedmetadata event to set currentTime. The problem I am seeing with this is that the first frame of the video gets shown momentarily while the player seeks to the right time. I am new to JS programming so perhaps I am doing something wrong but I do not see anything in the docs that can help me overcome this. I am trying to render H.264/mp4 videos in Chrome. Thanks!
Changing the preload setting to 'metadata' might help this in the browsers that support that setting.
preload="metadata"
Then it supposedly should only load the metadata and trigger the loadedmetadata event, and not show the first frame. That is unless providing any new src forces preloading, and I'm not sure off the top of my head.
HTML5 video doesn't give us a lot of options around seamless switching videos unfortunately. The media source API proposal from Google/Microsoft/Netflix aims to fix this. http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
You could try this:
https://bitbucket.org/felixschwarz/videojs-hdtoggle/
As seen here on the old videoJS-Forum I think you might have to declare preload="auto".
In the linked forum-threat there are also some changes I made documented.
When embedding html inside of SVG using the foreignObject tag, webkit based browsers render the backgrounds of the embedded html elements behind the svg elements. See http://code.google.com/p/chromium/issues/detail?id=35545 .
Here's an example : http://www.mxgraph.com/demo/markup/webkitbg.html
The green div should be on top of the red.
Does anyone know of a workaround for this issue? Maybe some incantation of z-index and/or grouping of elements or something in svg to fool webkit into doing the right thing?
This is webkit bug 58417, fixed on 2011-11-10. The fix is in Chromium version 17, which is currently in beta as of 2012-01-09, and should be released in early February. Not sure when the fix will land in Safari, but luckily I don't need to support it.
So the workaround seems to be "wait a month"...
I've just been hit by the same issue. Even though the bug is fixed since a long time in Chrome, Safari seems to be ages behind with the codebase.
My solution is to add style="display:inline-block" to the first child of the foreignObject tag. This seems to fix the problem.