Maybe NR/ffmpeg does not have access right to that folder to write file?? You write to user "Io" desktop to a folder/file, this might not be allowed from access point of view
It's not a problem of access right, I checked. Moreover with this command the mp4 file is correctly created
ffmpeg -rtsp_transport tcp -i "rtsp://admin:admin@192.168.43.15:554/11.264" -c:v copy -t 30 "C:\\Users\\Io\\Desktop\\test\\test.mp4"
You're right, even to me it seems there should be some more on the output, it's like has been cut. But even with copy paste I always get the same.
For the out_2 the rc object wasn't display. Here the complete debug I get 
2 things; there is a setting possible in NR to allow more characters in the debug pane. I do not remeber where but try to search here in forum, has been discussed
Also, did you run that working command from an exec node in NR?
OOPS I see something now!!! I made a mistake when writing in your flow,,,I did write cam1, should be Cam1 (if it would work now if you change, well I hope...)
Should be like;
ffmpeg -f hls -live_start_index 0 -i http://127.0.0.1:1880/mp4frag/Cam1/hls.m3u8 -c copy -t 30 -f mp4 cam1_0.mp4 -y
Yes, once I understood the way it should work I checked and corrected the camera name.
To show more characters within debug node it has to be changed the option inside the settings.js. Here the full message
[http @ 00000272136bf640] HTTP error 401 Unauthorized
http://127.0.0.1:1880/mp4frag/cam1/hls.m3u8: Server returned 401 Unauthorized (authorization failed)
What kind of authorization is needed? How can I do it? Sorry, it may seem stupid question but I have very little knowledge about this staff 
For what I understand it has something to do with node-red authorization, since I protected it
I assume that you run NR in your Windows 10 PC? If so it could most likely be a firewall problem in your Windows PC. Since ffmpeg is trying to communicate over port 1880 and that is most likely blocked by default. Try for a short period to turn off the Windows Firewall just to check if it then works. Then you know where the issue is. If so, you have to allow traffic on port 1880
But I'm not a windows supporter, I use Linux, there it works 
Great krambriw. I just put the node-red credential inside the command and I get it. It works, even without turnoff the firewall (yes, it's Windows10) 
ffmpeg -f hls -live_start_index 0 -i "http://user:password@127.0.0.1:1880/mp4frag/cam1/hls.m3u8" -c copy -t 30 -f mp4 "C:\\Users\\Io\\Desktop\\test\\test.mp4" -y
A bit more tricky question. In this way I put plan credential inside the flow, the one encripted within settings.js. How can avoid it? Maybe it's what @kevinGodell explained in this replay Show ip camera in dashboard and store prefixed buffer video - #25 by kevinGodell but that I'm not able to understand
Possible yes, I think he is discussing how to "borrow" a cookie from a browser session. I don't know if it will help you in your setup and I don't know "how to", sorry I do not run NR in Windows
Per the ffmpeg authentication thing with the cookie, I had just discovered that ffmpeg can use custom headers and did a quick experiment to see if it could get past my authentication and it magically worked! I had not previously tried to do something like that.
If you are using basic auth, then you can try to duplicate that. Use a good browser. Log in to the ui dashboard. Inspect the cookies in your browser and see what it set. Delete that cookie set by your node red server and refresh the browser to see if you are no longer logged in. I guess that could be a good way to verify which cookie to steal. Currently I dont have basic auth setup and cant provide any further details of what the cookie in the headers might look like.
Thanks a lot kevin
@Lupin_III
The authorization is related to the setting you have in settings.js for NR. I tried this and it is the same also for Raspbian as you have experienced when running NR under Windows. I think it is the httpNodeAuth setting. Anyway, setting a user and password for it required me to login to the dashboard. When I inspect headers in the browser, the only cookie I can see being set is typical like below (see io=wW540xQTOgCuzrNmAAAW). After a refresh it is changed so it is not static, so this cannot really be used
I have no clue if it would be possible to retrieve the current cookie and feed that into the command executed by the exec node. Because having a static cookie can't give better security than just adding user:password like you did. Or am I missing something?
So this is a little nut to crack; how can/shall another application login correctly and then do http requests like we do here when accessing the mp4 stream without revealing the user name and password?
Replying myself. I found a way that feels a bit better. You can do like this
- assume username is "user" and password is "node-red"
- make a string like "user:node-red" and make Base64 encoding (see the flow below)
- use the resulting string and insert it in the ffmpeg command line like in the example below
- it works
How secure it is I don't know but at least you do not send user name and password in clear
EDIT: It's not really more secure since it is easy to convert it back to a string
Nice example with the basic auth headers for ffmpeg.
Also, the io= is the cookie set by socket. io and should be unrelated to the http authentication.
Hi, in the past weeks I wasn't able to go on with this issue, I hope to go ahead with it in the next days. Thanks a lot for all support
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
