On our server we have Wowza 4.0.4.
My case:
Start stream (e.g 10sec)
Disconnect from Internet
Reconnect
End stream
As result I get two mp4 files (before and after disconnect) but the first one (before disconnect) is broken, the second one is OK.
How can I fix Wowza to get the first mp4 file normal/unbroken?
Related
I'm implementing an RTSP server which reads a video H264 file stream and makes it available under RTSP protocol.
The idea is this:
The server creates a pipeline using video1.mp4 as videosrc and then, when video ends and the EOS event is generated, it has to switch filesrc to video2.mp4 and restart streaming automatically. When video2.mp4 ends it switches back to video1.mp4 again. The client is supposed to never stop receiving a video stream in this way.
Is it possible to obtain a server behavior like this?
Cheers
Summary: How do I stream high quality video using WebRTC native?
I have an h264 stream that's 1920x1080 at about 30fps. I can currently stream this from a server on localhost to a native client on localhost just fine.
I wrote a WebRTC server using Google's WebRTC native library. I've written a VideoEncoder and VideoEncoderFactory that takes frames consisting of already encoded data and and broadcasts it over a video track. Using this I can send my h264 stream to the WebRTC server over a pipe and I can see the video stream in a browser.
However, any time something moves the video gets corrupted. It continues to play but is full of artifacts. Eventually I discovered that WebRTC is dropping some of my frames. When I attach a sequentially increasing ID to each frame before I pass it to rtc::AdaptedVideoTrackSource::OnFrame and I log this same ID in webrtc::VideoEncoder::Encode I can see that some of my frames simply disappear.
This kind of makes sense, I'm trying to stream high quality video over something meant for video chat and lowing my framerate fixes the corruption. However, I'm not asking the WebRTC library to do a lot, it's just forwarding already encoded data to a client on localhost. I have a native app that does this fine and I've seen one browser WebRTC client that can do this. Is there a field in the SDP or some configuration change that will allow me to stream my video?
This was the solution How to control bandwidth in WebRTC video call? .
I had heard about changing the offer sdp but dismissed it because I was told that the browser will accept unlimited bandwidth by default and that you'd only need to to this if you want to limit bandwidth. However, adding "b=AS:high number" has fixed all of my problems.
Does Wowza Streaming Server (used as live streaming services) care about the direction of data stream?
Possibility of Wowza Server as a server side mode and client side mode
Since I am trying to send data stream via LTE, the cost of sending data stream is very high. So I am wondering if it is possible to have live stream data only when the request is present.
Thank you
It's not 100% clear what do you mean by "Wowza acting as a client" to me. Wowza can be configured to be an edge instance, that pulls stream from an origin Wowza server, when you want to have multiple, possibly geographically distributed stream sources.
Or, if you think about the other case, Wowza accepts the stream from encoders, in which case the data flow direction is also towards Wowza. This is the case when you install for example a Flash Media Live Encoder, or a VLC and push your encoded stream "into" Wowza, which then distributes this stream to all other players.
But obviously Wowza won't act as a video player to you.. :-)
Can you clarify your first question, maybe I can give a better answer then.
I am trying to frame sync two looping videos over a lan. Both videos have the same length but the resolution might differ. The following code works already for the first run:
server code
client code
As soon as the video reaches GST_MESSAGE_EOS it starts over which is fine. But the client however will keep on reaching EOS all the time. I think this is because the servers clock is already past the clients video length.
How can I fix this. Can I somehow reset the servers base time on EOS? And if so how?
After trying a lot of different approaches, I found that manually reconnecting to the server on each video end event did the trick. See the original server and client code links in the question for my solution.
I've compiled with VS the live555 source code, and it works just fine if I try to stream locally a file
e.g.
Command Line:
live555.exe myfile.mp3
VLC Connection String
rtsp://169.254.1.231:8554/myfile.mp3
but if I try to stream it over the internet, VLC communicates with live555, but live555 won't send data to him
Command Line
live555.exe myfile.mp3
VLC Connection String
rtsp://80.223.43.123:8554/myfile.mp3
I've already forwarded the 8554 port (both tcp/udp) and tried to disable my firewall but this doesn't solve.
How is that?
To troubleshoot:
Are you streaming RTP over RTSP: have you checked the "Use RTP over RTSP (TCP)" option in VLC? You can check this in VLC under the preferences: input/codecs->Demuxers->RTP/RTSP. You can try to see if this solves the problem in which case it could be that UDP is blocked.
You speak of forwarding. Do you mean port forwarding from one machine to the RTSP server? if so-> if you are not doing RTP over RTSP, then you would also need to forward the ports for the media which is not the same as the RTSP port (554 or 8554). These ports are exchanged during the RTSP SETUP. If you do RTP over RTSP the media is interleaved over 554 or 8554 and you don't have to worry about this.
Also, another good debugging tool is the live555 openRTSP application. You can run it from the command line and specify "-t" for RTP over RTSP, which is basically what the VLC option does. You can specify "-T" for HTTP tunneling, etc and it allows you to write captured media packets to file, etc.