yellowstone
yellowstone copied to clipboard
mbullington
Seems like the client forgets to use use credentials?
Hello,
I'm trying to use yellowstone to get the video stream from a password protected endpoint. Any time I try to paly it always errors out with a 455 (Method not valid in this state). Inspecting the traffic with wireshark it seems like that the server "forgets to login" at every request and has to do it each time it makes a request thus resulting in a 455 when trying to play. Here is the summary from a dump made with wireshark between yellowstone and an RTSP server:
as you can see every time it tries to make a request it first does it without providing credentials which results a 401, and then it does it again, this time with credentials. The first time is fine, if I recall correctly that's what the RTSP specs describes, but the subsequent times it should remember to include an auth header, but it doesn't, thus resulting in a 455 because the server remembers that the SETUP was done on a different session.
For comparison here is one from VLC connection to the same server:
As you can see it tries the first time without a credentials, then fails, tries again with credentials, succeeds and then keeps using the same auth header resulting always in a 200.
Can we get a fix for this?
Thank you in advance
Enrico
Thanks for the logs from Wireshark. I can also see this if I enable the logging in the wowza.js example (the last few lines of the wowza.js file) and point it at one of my CCTV cameras.
I don't think Yellowstone used to work like this in version 2.x I wonder if something broke when @mbullington moved over to Typescript in 3.x and all I've tested with are Bosch cameras with authentication turned off or with the Wowza online RTSP source (that does not need authentication)
Update: The bug seems to have come from the change by @tuliofaria where it checks for 401 Authentication Errors only on the first two RTSP messages. I'm testing and working on a fix
There were actually two issues here and I'm not sure you were seeing both problems so the latest Yellowstone may still fail on your RTSP server.
Problem 1 - Not sending Authorization for RTSP commands with Seq Numbers > 2 Yellowstone sends a RTSP command with no authorisation. Then gets a 401 and then sends the command again with Authorization. A change from another contributor meant it only did this for the first 2 RTSP commands, then stopped with a Promise Reject(). This meant I could not get any video from an Axis IP camera.
I've fixed this
Problem 2 - Not sending the Authorization in the first place. Yellowstone does not cache the Authorization type (basic/digest) or any authorization parameters (like Realm and Nonce) It currently works by sending a command, getting a 401 and then sending the command again with Authorization, for every RTSP command
I've not fixed this yet but know what to do.
It may be worth testing the first fix while I work on the 2nd fix
Or, if you can give me access to the RTSP server you are using, I can do a test here
Unfortunately I can't make the device public, but if you tell me what fork to test with i can try and see if it'll run
Can you send me the wireshark log of the DESCRIBE packet please, showing the SDP.
sure thing
RTSP/1.0 200 OK
CSeq: 3
Content-Type: application/sdp
Content-Length: 507
Date: Wed, 21 Sep 2022 12:37:19 GMT
v=0
o=- 1109162014219182 0 IN IP4 0.0.0.0
s=Media Server V4.26.131
i=Media Server Session Description : standard
e=NONE
c=IN IP4 0.0.0.0
t=0 0
a=control:*
b=AS:1258
a=range:npt=now-
m=video 0 RTP/AVP 96
i=Video Media
a=rtpmap:96 H265/90000
a=control:trackID=video
b=AS:1248
m=audio 0 RTP/AVP 0
i=Audio Media
a=rtpmap:0 PCMU/8000
a=control:trackID=audio
b=AS:10
a=Media_header:MEDIAINFO=494D4B48020100000400050010710110401F000000FA000081000000000000000000000000000000;
a=appversion:1.0
I can see the problem. You are connecting to a H265 (HEVC) video stream. Yellowstone does not know how to receive RTP packets with H265. Yellowstone only has code to handle the RTP payloads for H264 and AAC. (the H264Transport and AACTransport files)
So there was a bug in the wowza.js sample that it should not have sent PLAY because there were no streams it could receive. I've just fixed that in the wowza.js example file.
So, if you need to stream H265, then we need a H265Transport.ts implementation.
(note- there is a nice open source H265Transport in C# in the SharpRTSP project. I wrote it a few years ago)
Well, my idea was to just grab the data from the on data event but sure, that'd be great. From my very limited research i understand that the h265 transport is very similar to h264, obviously decoding is different tho, but that is something I don't have to take care of.
Tho having a dedicated handler would be great.
if you just grab the data from the Data Event, you will not be able to decode and play the video.
The data event will give you the RTP packet contents. That is a little bit of H265, wrapped with some special headers when sending via RTP. And that data is wrapped in the RTP Packet which adds an extra header. So you can capture the data from the Data Event, but then you need to write the code to extract the actual H265 video.
Yea i figured, i found a function online that was supposed to be able to extract packets but didn't have much luck so i just ended up using ffmpeg in a "pass through" mode temporary, I'll be waiting for the h265 transport to swap it out.
Ported over my C# H265 RTP handling code to Typescript for 2 of the 3 different ways H265 gets split into packets. But there is a bug - I get corruption in the H265 from my Axis camera.
So there is something in the h265 branch but needs debugging in H265Transports.ts
Great, I'll test it out, perhaps it works on my machine, worst case scenario I'll try to debug it my self