> Sorry, I do not fully understand the problem... What's your setup? > Are you feeding a DSS with ffmpeg (over a local network) and then > accessing the DSS with a player via RTSP?
FFMPEG and DSS are running on same machine, and then stream to remote player. According to my checks (done when I wrote this reply), the problem is not within DSS but within the app/RPT, because VLC running on same machine, and connected directly to RTP shows same issues. Please see below. > Or are you receiving video from DSS with ffmpeg and then restreaming > it? Nope, I'm receiving a video from another video source using their own SDK (it's mpeg4 but protocol seems to be a proprietary one). Then I'm re-encoding the video and re-streaming it. > According to your description, it looks like some packets are lost, > maybe because of network issues? > I mean, assuming that this is your setup: > |--------| ethernet |-----| ADSL > | ffmpeg |------------>| DSS |------------------> QT Player > |--------| |-----| > maybe some packets are lost on the ADSL because the instantaneous > bitrate of your stream is > 256kbps... It goes about this fashion: *source* --- |ADSL| --- *sdk* --- *ffmpeg* --- *DSS* --- |LAN| --- VLC And the issue exist without DSS as well: *source* --- |ADSL| --- *sdk* --- *ffmpeg* --- |LOCALHOST| --- VLC > Even if the average bitrate is 256kbps, there can be some "peaks" > over 256kbps which can cause troubles (for example, if there are > some dark scenes without much motion the codec can use few bits > for them, resulting in a high bitrate for the following scenes). > If this is the problem, it can be solved by using rc_max_rate & > friends (but this will cause a degradation in the video quality). Hmm, actually I don't know how it's applicable here, as video is coming from SDK just fine (because when it's recorded to disk, it has no visible jumps or garbage). LAN also doesn't has any such limitations. Now, what I noticed is that the default SDP produced by ffmpeg (and which I'm using) has the b:AS rate set to 200 kbit. According to SDP RFC, AS is the maximum bitrate produced by the application. So I tried increased it to 300 thinking that perhaps dss/player limits the actual stream (which comes in 256) and causing the issue. Unfortunately it didn't help. > You can use some tools like wireshark, tcpstats, and similar to > check what's happening in the network... Also, many players allow > to monitor the number of lost packets, the buffers' levels, etc... > Maybe you can use these statistics to understand where the problem > is. Just to understand, the number of sent frames should be equal to number of received frames on the player end? Or packets? > > 2) When I re-stream the recorded video with ffmpeg command line, it > > also looks fine. > > > So, I assume that you are using your libav-based program to feed > a DSS, right? Are you saying that if you first encode some live video > to a file, and then you stream it in a second time, everything is fine? Yes, if I use libav to stream live - it has issues. File recorded to disk, and then streamed via ffmpeg *command line tool* (not via my app) works fine. > If this is the case, then maybe you are seeing a different problem, due > to a drift between your computer's clock and the internal clock of the > video capture (or audio) card... > I expect this problem to appear after some hours of live streaming > (depending on the hardware quality, etc...). It can appear almost immediately. Again, the source seems to be ok (as the recorded movies play and re-streamed just fine). > The "ffmpeg" program provides a way to address this problem (-vsync > and -async). If you are usign your own program, you might need to > implement something similar. Any idea if it still can help in this case (as I don't use any card)? > > 3) I tried to connect directly to RTP port with VLC, it shows a lot of > > garbage (because of rtp?), and in case of live it plays only few > > frames and then stops. With recorded re-stream it plays it until the > > end. > > How do you directly connect to the RTP port with VLC? Remember that > if you do not use an SDP description, things are not guaranteed to work. Until your question I used such approach: vlc udp://@127.0.0.1:5000. After your question I tried to open the SDP withing VLC and it worked (which quite logical :) ), and seen clear video, but with the mentioned issues and jumps. > > 4) The whole issue happens when the source is over remote ADSL > > (256Kbps) connection. When the source is in local LAN, there are no > > issues at all (the amount of frames per second is about the same - 15 > > fps). > > > If you do not see problems when streaming on a local network, I guess > the stream's bitrate is to high for the ADSL (see the description at the > beginning of this email). Same here - the video comes from the source just fine (as it's recorded fine too). > > 1) The FFMPEG RTP operates in UDP, hence some frames might be lost > > between DSS and LibAVCodec, causing the "garbage" and jumps. Any way > > to switch the RTP to TCP? > > I dont' know if you are using ffmpeg as an RTSP client, or to feed > a DSS. In the first case, it should be possible to use RTP over RTSP > (I do not remember the exact option, but there should be one). FFMPEG is used as encoding/RTP streaming library only, it's not a client. Any idea what this option to send RTP in TCP/RTSP might be? > > 2) Could it be that the timing formula (with av_rescale_q) is somehow > > causing this? > > In theory, no... But the network can introduce some jitter, causing > problems. You can correct the timing formula to send a small amount > of packets "in advance" to compensate for some possible network jitter. > You can also modify it to "smooth" the output bitrate, so that your > stream can be more "ADSL friendly". > Any idea if it still applies to case where video coming clearly, but not re-streamed clearly? > > 3) Can someone recommend a good way to clearly playback video from > > live RTP, in order to pinpoint it on ffmpeg level and not on the DSS > > level? I tried ffplay but it didn't work. > > Difficult to say without knowing your setup... > Also, can you describe a little bit more what didn't work? Well, you answered on this earlier in the email :) - by mentioning that I should simply open the SDP in VLC. To summarize, the problem clearly in RTP, as VLC connected directly to it shows jumps as well. Question is how to reliably stream the RTP - whether it depends on any additional options in SDP (including the in/out band matter), or anything else. Thanks again for your time, hope all my explanations were clear enough. _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
