Hm, that's difficult to say here.
Something is making the player to stop, somewhere...
There is a few way the player can retrieve itself in the STOPPED state. From what I can tell right now, we may be in one of the following situation
- you re-loaded a video through
loadVideo - you called stop or dispose
- a fatal error happened
Can you enable RxPlayer's logs (RxPlayer.LogLevel = "DEBUG")? At the very least we will see if it's another loadVideo call or an error
I am using RxPlayer with reactjs, I am new to this world of reactjs, to initialize the rxPlayer as follows
const initPlayer = () => {
player = new RxPlayer ({videoElement: document.getElementById ("video")});
video = player.getVideoElement ();
videoContainer = video.parentNode;
console.log ("initPlayer player:" + player);
player.loadVideo ({
url: "http: // localhost: 8000 / output / streams / video1 / dash.mpd",
transport: "dash",
autoPlay: autoplay,
});
player.addEventListener ("playerStateChange", onChageState);
player.addEventListener ("availableVideoTracksChange", onVideoTrack);
player.addEventListener ("Error", function (err) {
console.log (`The player crashed: $ {err.message}`);
});
};
useEffect (() => {
console.log ("useEffect initPlayer ()");
initPlayer ();
}, [channelData, autoplay]); Could she be doing something wrong? Regards.Traducir del: inglés
468/5000
do the following:
const onChangeValueQuality = (e) => {
console.log ("set valueQuality:" + e.target.value);
const value = player.getPlayerState ();
console.log ("player state:" + value);
try {
player.setVideoTrack (e.target.value);
} catch (e) {
const error = player.getError ();
console.log ("error:" + error + "code:");
console.log (e);
}
};and error tells me it is null.
Good, I need help, I don't know what else to do, I have the following problem whether it loads dash content or directfile when I am going to advance to a position in the player or I am going to change the resolution, it tells me the following error, Error: player: no content loaded
at Player.seekTo (rx-player.js: 48473)
at onMouseClick (Player.js: 334)
at HTMLUnknownElement.callCallback (react-dom.development.js: 188)
at Object.invokeGuardedCallbackDev (react-dom.development.js: 237)
at invokeGuardedCallback (react-dom.development.js: 292)
at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js: 306)
at executeDispatch (react-dom.development.js: 389)
at executeDispatchesInOrder (react-dom.development.js: 414)
at executeDispatchesAndRelease (react-dom.development.js: 3278)
at executeDispatchesAndReleaseTopLevel (react-dom.development.js: 3287)
at forEachAccumulated (react-dom.development.js: 3259)
at runEventsInBatch (react-dom.development.js: 3304)
at runExtractedPluginEventsInBatch (react-dom.development.js: 3514)
at handleTopLevel (react-dom.development.js: 3558)
at batchedEventUpdates $ 1 (react-dom.development.js: 21871)
at batchedEventUpdates (react-dom.development.js: 795)
at dispatchEventForLegacyPluginEventSystem (react-dom.development.js: 3568)
at attemptToDispatchEvent (react-dom.development.js: 4267)
at dispatchEvent (react-dom.development.js: 4189)
at unstable_runWithPriority (scheduler.development.js: 653)
at runWithPriority $ 1 (react-dom.development.js: 11039)
at discreteUpdates $ 1 (react-dom.development.js: 21887)
at discreteUpdates (react-dom.development.js: 806)
at dispatchDiscreteEvent (react-dom.development.js: 4168)
However, the video is reproduced, the curious thing is that before performing the action I ask for the status of the player and it tells me that it is Stopped, however I am subscribed to the player's events and in Stopped I have an alert to see if it passes through the but I never run the alert, and it goes through playing, I don't know why this happens, if you could help me, greetings
does the player have an event that is executed when the getPosition changes to update my bar?
We do have a positionUpdate event but the frequency at which it is sent might not be the one you want.
If that's the case you can call getPosition with an interval while also relying on the player's states (through playerStateChange) to know when the user is seeking etc. (or even the seeking and seeked events).
It seems there is something that makes the player stop somewhere.
Here's the code of the loader:
const segmentLoader = (infos, callbacks) => {
console.log('customSegmentLoader', infos)
const xhr = new XMLHttpRequest();
const sendingTime = performance.now();
xhr.onload = function onXHRLoaded(r) {
if (200 <= xhr.status && xhr.status < 300) {
const duration = performance.now() - sendingTime;
const size = r.total;
const data = xhr.response;
callbacks.resolve({ duration, size, data });
} else {
const err = new Error("didn't work");
err.xhr = xhr;
callbacks.reject(err);
}
};
xhr.onprogress = function onXHRProgress(event) {
const currentTime = performance.now();
callbacks.progress({ type: "progress",
value: { duration: currentTime - sendingTime,
size: event.loaded,
totalSize: event.total } });
};
xhr.onerror = function onXHRError() {
const err = new Error("didn't work");
err.xhr = xhr;
callbacks.reject(err);
};
xhr.open("GET", infos.url);
xhr.responseType = "arraybuffer";
const range = infos.segment.range;
if (range) {
if (range[1] && range[1] !== Infinity) {
xhr.setRequestHeader("Range", `bytes=${range[0]}-${range[1]}`);
} else {
xhr.setRequestHeader("Range", `bytes=${range[0]}-`);
}
}
xhr.send();
return () => {
xhr.abort();
};
};Hi,
This should work... I tested it locally on the RxPlayer's demo page and I had no problem.
Maybe it's a problem with the content.
When you say "only the first segments" is loaded, you mean how many segments for each track? If it's just one, it is possible - for whatever reason - that we are only loading the initialization segment.
It's a little technical but basically you're playing a content which depends on an index segment, we also have to download it here.
On the initialization segment (the first requested one), there is a supplementary property on
infos.segment, called indexRange (set to undefined for the other segments)You have to also request that second byte range and concatenate both of those infos (range first, indexRange second).
indexRange comes just after the range, in those cases you can very easily do:xhr.setRequestHeader("Range", `bytes=${range[0]}-${indexRange[1]}`);if (segment.range !== undefined) {
let rangeStart, rangeEnd;
if (segment.indexRange !== undefined) {
rangeStart = Math.min(segment.range[0], segment.indexRange[0]);
rangeEnd = Math.max(segment.range[1], segment.indexRange[1]);
} else {
rangeStart = segment.range[0];
rangeEnd = segment.range[1];
}
xhr.setRequestHeader("Range", `bytes=${rangeStart}-${rangeEnd}`);
}MINIMUM_SEGMENT_SIZE is not really linked to requests, it is a configuration value related to how the RxPlayer calculate which segments are currently in the buffer, it will not help you here.
So here you basically want to request "bigger segments" so there are fewer segment requests ?
The size of segments is actually dictated by the content (more specially in your case, by the index segment). Technically, the RxPlayer could load multiple contiguous segments at a time instead of just one at a time, but this is not an usual feature and this is not something handled by the player today.
If you control the content packaging process, it would be better to just generate bigger segments on that side.
Hi,
Yes, we're just considering the "main" role for the video AdaptationSet for now.
The reason we did not generalize at first that logic is that though that behavior (choosing the "main" AdaptationSet by default) was clearly defined for video contents in the DASH-IF IOPs it was a little unclear if that also concerned other AdaptationSet types.
So, until now, we went for sorting based on:
- the
selectionPriorityattribute if available. - the order in the MPD
For AdaptationSet other than video.
Though we do encounter many contents signalling a "main" audio AdaptationSet and the DASH-IF IOP tells us that this is a possibility.
Consequently, I'm not against adding that behavior for audio contents. The main question I'm having now is what to prioritize between a "main" role and the selectionPriority attribute - but maybe I can find an answer by examining more closely the DASH-IF IOPs.
I will try to schedule that improvement for the next release (for in 3-4 weeks?).
3.9.5.2 does seem to say that we should first base ourselves on the content of Role, though it just says that we should just exclude all "alternative" first - which is weird because the role is actually called alternate.
By reading what other players are doing (dash.js and the shaka-player) it looks that both are using the main role when there are multiple AdaptationSet possible. This looks to me like a sane default - and by reading the DASH-IF IOP I guess the role takes precedence on the selectionPriority attribute,
That does not look too hard to implement so we will try to include it in the next release.
Hello @Miltosh, RxPlayer is a javascript library implementing a streaming video player. It handles the core feature of playing content and provides an API.
However, the library doesn’t implement a UI. For now, the RxPlayer demo page UI cannot be exported or reused. So, the RxPlayer’s users usually build an HTML web page above the lib, from scratch. Of course, it implies that you may have total control of the way to implement timelines, buttons, control panels, inputs, etc. If you intend to build the UI from scratch, we may help you get the info you need for displaying correctly playback info, etc. For know, you can check our API here https://developers.canal-plus.com/rx-player/doc/pages/api/index.html.