When using videojs-contrib-ads to create an ad plugin in video.js, the main programme often starts playing before the ads start playing. It seems that video.js connects to the CDN of the main content initially and then contrib-ads checks if it needs to play prerolls. A few seconds of the main content is sometimes played before this happens and only then does it start to play the adverts.
This was seen mostly on iOS on live feeds.
Does anyone know why it works like this and is there a way to stop it?
Use the prerollTimeout setting.
The maximum amount of time to wait for an ad implementation to initiate a postroll, in milliseconds. If contentended has been fired and the ad implementation does not call startLinearAdMode() before postrollTimeout expires, the content video will end playback.
Related
Has anyone else found this? I'm using AudioSource.uri to get the remote audio source, then just using await player.play(); to play the remote audio file, on Android these audio files buffer and start playing a lot faster than on iOS where it takes up to 10 seconds to load and start playing (versus just 2-3 seconds on Android)
This happens because by default, iOS tries to prevent the player from having to stutter during playback when the network is slow. In effect, it waits longer for more data to be downloaded up front before allowing the audio to start.
How to override the iOS default: The AudioPlayer constructor in just_audio takes a parameter called audioLoadConfiguration where you can pass in platform specific parameters that control loading behaviour. One parameter that is relevant here is automaticallyWaitsToMinimizeStalling which you'll want to set to false. e.g.:
final player = AudioPlayer(
audioLoadConfiguration: AudioLoadConfiguration(
darwinLoadControl: DarwinLoadControl(
automaticallyWaitsToMinimizeStalling: false)));
I have two live videos feeding an encoder which creates H.264 chunk files and an HLS manifest which is being served by an apache web server.
A browser page using video.js shows a player. Pressing "play" on the browser properly plays the video. It works well.
However, if we change video sources (by flipping the switch in the picture below), there is a considerable delay (10 seconds) before the new content is displayed in the player. I'd like to get that to 3 seconds.
It appears that video.js and/or the HTML5 player in browser is buffering that amount of content. (if you delete the files on the web server, kill apache, or even pull the ethernet cable, the video keeps on playing!)
A button on the web page controls the switch. When clicked, I would also like to clear or reset the player so that it immediately re-reads the index.m3u8 manifest and downloads the new chunks.
So far, haven't found anything promising searching the internet or in the video.js API docs. There are lots of articles on API calls for fetching the current buffer percentage but cannot find any API for clearing it altogether.
Any ideas?
The encoder is set for 3 second chunks and the playlist depth is set for 10 entries.
I had a similar problem. Since i could not find a reliable API for this, i came up with a rather dirty workaround to clear the buffer:
var ctime = player.currentTime();
player.currentTime(0);
player.currentTime(ctime);
This currently works for me in all major browsers.
I've added some video app previews for my app on App Store Connect and when I set the video poster frame, it never saves the image that I want, it always reverts back to the one that Apple defaults to initially. Does anyone know a work around?
UPDATE: I did get in contact with App Store Connect and they told me it's a recent bug that they're actively working on fixing. I'm going to touch base with them early next week.
Issue is still happening. But if you want to be able to upload without problems try this:
Upload the screenshots of one complete language
Don't touch anything for 2-4 min once pictures are uploaded.
Then you can refresh the webpage and check if the screenshots are well uploaded.
My video src is an AWS presigned request url, it expires in x amount of time. The video will start playing just fine in video.js. For large video files after the brief url expiration time, changing the seek bar causes a network error because the original src link has expired. How do you refresh the src with another unexpired presigned url without restarting from the beginning of the video? I don't want the video to go back the beginning.
So far I have found that you can capture the change of the seek bar by listening for the event 'timeupdate' and in the passed event testing for e.manuallyTriggered.
Thanks
i had this same issue today. i'm using plyr instead of videojs, so i'm not sure if you can do this exact thing, but my solution was:
bind an error handler to the player for when the link has expired and someone tries to play/seek, and then in the handler...
store the current time of the video
send an ajax request to my server to get an updated signed URL
update the source of the player
set the current time of the video to the previously stored time
it's kind of slow/clunky, but it's the best fix i could come up with at the moment, aside from loading the entire video before allowing playback (which didn't seem like great UX).
update: this does work with videojs...but it doesn't work with either player in Safari, which apparently doesn't send the error event at all.
I have an audio tag like this:
<audio id="myAudio" msaudiocategory="BackgroundCapableMedia"></audio>
to which I set the src property to
URL.createObjectURL(file, { oneTimeOnly: true });
and then call
myAudio.play();
This works well for my personal mp3's, but songs downloaded through the Xbox Music Pass, which I assume are under DRM, simply do not play. There's no audio and the 'timeupdate' event never fires. I don't see any exception or message in the Output window.
I tried playing those same songs with VLC, and I get no audio while the progress bar advances normally.
Is it possible to play those songs outside of the official apps?
Edit: and if it isn't, can we detect if a music file is DRM'ed so as to prevent its usage in our apps?
These are DRM'd files, so they need the DRM keys, etc etc.
Since those are private to the application, it's not possible to play that DRM'd content outside of those applications.