Since the goal is to be the least late compared to the original flow.
Was this using the new ffmpeg movflag frag_every_frame? I have noticed an issue with atleast 1 of my cams that generally performs poorly and can only generate 10s duration segments based on the iframe interval. It can take up to 10s for the video to start being rendered after receiving segments, since I suspect that some of the newly received (shortened) segments don't have enough data to complete the visual frame.
Another thing I am currently working on is a different way to push the segments from server to client when using socket io. Currently, each new segment is requested after receiving the previous segment. I am going to add the option to request "all" segments, so there only needs to be the single request and all new segments will be sent as soon as they are available from the server. Not sure if this will make a difference or not, but it might take a small burden off of the socket io server.
I could implement another setting on the ui that can detect and fast forward the currentTime property of the video element. The tricky part is knowing what is a good value. I can constantly check it and see the current time vs available time and move the play head forward. The downside to that is if you move too far forward and dont receive a new video segment in time, then you will see lots of the spinning loading icon since the player will be stalled waiting on new video content.
1 Like
Yes i applied this new change command , with the ffmpeg v4 :
yes I see it is difficult to find the happy medium.
Would you not be able to calculate a kind of "moving average segment rate" that can be used as a "move forward" stepper
Did you create that nice UI with node-red dashboard ?
[off topic] Yes everything is done with the Node-red Dashboard, with some Dashboard ui-template keys (except the wifi chart which is a Win10 window in the background).
- a home page with tabs of Functions to develop (or not). Each tab has a button that leads to a more complete page.
- each complete page contains a button to return to the home page.
it looks something like this : ui control is the conductor of all navigation
2 Likes
Made some changes to dynamically tweak the video's currentTime property to keep it at a reasonable position based on the current amount of buffered video in an attempt to keep it close to realtime. This will eventually be a setting that you can change.
Also, found a major flaw that caused the video to freeze if a segment failed to arrive and the source buffer ended up with a gap in the time ranges.
If you wish to use the shortened segments with the -movflag +frag_every_frame and -min_frag_duration while still support hls.js playback, then you will have to tweak some of its settings to handled the smaller segments. An hls.js configuration that worked for me when my segments were shortened to 0.5 second duration:
{
"liveDurationInfinity": true,
"liveBackBufferLength": 5,
"maxBufferLength": 10,
"manifestLoadingTimeOut": 1000,
"manifestLoadingMaxRetry": 10,
"manifestLoadingRetryDelay": 500
}
I am currently testing socket.io@3 as a dependency. For me it seems to have better performance. If you would like to see if we can make this work and it doesn't break your node red server, here is what you can try:
// change to the node red folder
cd .node-red
// uninstall the dashboard and mp4frag nodes
npm uninstall node-red-dashboard
npm uninstall node-red-contrib-mp4frag
npm uninstall node-red-contrib-ui-mp4frag
// install the dashboard and mp4frag nodes that use socket.io@3
npm install kevinGodell/node-red-dashboard
npm install kevinGodell/node-red-contrib-mp4frag#socket_io_3x
npm install kevinGodell/node-red-contrib-ui-mp4frag#socket_io_3x
// restart node red
node-red-stop && node-red-start
Updated accordingly
But if I set socket.io as nbr 1 choice in Player Order (in ui-mp4-frag) nothing is shown in the browser. On my Mac the following works:
Chrome: hls.js, hls, mp4
Safari: hls.js, hls
Thanks for testing and I am sorry that it did not work for you. I am investigating now. If you have a chance, I am curious if you have any other dependencies on socket io. Can you also show the output of the command npm ls socket.io in the .node-red folder ?
pi@raspberrypi:~ $ cd .node-red
pi@raspberrypi:~/.node-red $ npm ls socket.io
node-red-project@0.0.1 /home/pi/.node-red
├─┬ node-red-contrib-mp4frag@0.1.0 (github:kevinGodell/node-red-contrib-mp4frag#9b46fcc281cb15c0f48219b211cce4e3e61dff31)
│ └── socket.io@3.0.3
└─┬ node-red-dashboard@2.24.2-beta (github:kevinGodell/node-red-dashboard#7ba4a3c36f034960959c119c50fcf3b4fdd0d964)
└── socket.io@3.0.3 deduped
The socket.io.js file delivered from the node-red server should show the version at the top. The file at my server was found at http://192.168.1.85:1880/ui/socket.io/socket.io.js.
/*!
* Socket.IO v3.0.3
* (c) 2014-2020 Guillermo Rauch
* Released under the MIT License.
*/
And in the browser, the socket connection should show that it is using EIO version 4, which is what socket io v3 uses.
Request URL:
ws://192.168.1.85:1880/mp4frag/socket.io/?EIO=4&transport=websocket
Request URL:
ws://192.168.1.85:1880/ui/socket.io/?EIO=4&transport=websocket&sid=6crnnvg2J0IMM1unAABW
No problem, I'm just happy to test
I guess I have a problem because of using the ui-table node (let uninstall it and check again if it then works)
pi@raspberrypi:~ $ cd .node-red
pi@raspberrypi:~/.node-red $ npm ls socket.io
node-red-project@0.0.1 /home/pi/.node-red
├─┬ node-red-contrib-mp4frag@0.1.0 (github:kevinGodell/node-red-contrib-mp4frag#aed30d4b1e40aa6de66f3b51bb5a7c187ef76459)
│ └── socket.io@2.3.0
├─┬ node-red-contrib-ui-mp4frag@0.1.0 (github:kevinGodell/node-red-contrib-ui-mp4frag#58699f56d000d75abcba9a416bddcfd176b3cbf6)
│ └─┬ node-red-dashboard@2.24.1
│ └── socket.io@2.3.0 deduped
└─┬ UNMET PEER DEPENDENCY node-red-dashboard@2.24.2-beta (github:kevinGodell/node-red-dashboard#7ba4a3c36f034960959c119c50fcf3b4fdd0d964)
└── socket.io@3.0.3
npm ERR! peer dep missing: node-red-dashboard@>2.15.0, required by node-red-node-ui-table@0.3.8
1 Like
I edited my previous post after you had already responded with further information. Also, I just did a full uninstall and reinstall again and it still works for me. There must be something that I am overlooking.
I shortened the commands for uninstalling and installing into 1-liners so we can be sure the last command doesn't get missed if copy pasting and not pressing enter on the last line.
change to node red dir:
cd .node-red
uninstall:
npm uninstall node-red-contrib-mp4frag node-red-contrib-ui-mp4frag node-red-dashboard
install:
npm install kevinGodell/node-red-contrib-mp4frag#socket_io_3x kevinGodell/node-red-contrib-ui-mp4frag#socket_io_3x kevinGodell/node-red-dashboard
restart node-red:
node-red-stop && node-red-start
I'm installing right now, it seems to take very long time, is that normal? I think I remember it did not take very long time earlier to install thoses nodes. Maybe something is being built in background???
i noticed that also. the dashboard seems to take a very long time to install. i walk away and come back. many minutes
Yes indeed - something weird has happened to npm when installing from git rather than npm... You can try yarn instead . Get your life back but shorter walks.
1 Like
OK, thanks, I will just stay calm
Just a question, is there a difference between these commands? If so I think I made the mistake earlier since I omitted the #socket_io_3x from the lines
npm install kevinGodell/node-red-contrib-mp4frag#socket_io_3x
npm install kevinGodell/node-red-contrib-mp4frag
oh yes... the #socket_io_3x is vital as that is the new branch you want to install from - not the default master one...
2 Likes
Gift from heaven, I will try...
Yarn syntax? Is it like
yarn install kevinGodell/node-red-contrib-mp4frag#socket_io_3x
It works now! After installing yarn I issued the following commands
change to node red dir:
cd .node-red
yarn add kevinGodell/node-red-contrib-mp4frag#socket_io_3x
yarn add kevinGodell/node-red-contrib-ui-mp4frag#socket_io_3x
yarn add kevinGodell/node-red-dashboard
restart node-red:
node-red-restart
1 Like
Amazing quality!!! Below 10% CPU load on an RPi3B+, viewing from my MacBook Air using Chrome
I hope you can see the fantastic quality also in this video recording from my mac. Streaming a pre-recorded video (unfortunately it seems it is just recorded in 720p, I think it is better like 1080p when I watch it live)
2 Likes
