RTSP Stream : queue becomes empty after some seconds
Trying to play a video stream coming from a server with my own RTSP implementation. After a few seconds of normal video play, the BlockingQueue in AVDemuxer becomes and remains empty
http://pastebin.com/7V8qaYWd
can other players (ffplay, mplayer) play it normally? it seems that the player can not read the stream
Hi, I have a similar problem with RTSP live camera input. It complains about hundreds missing packets when decoding video. Did you use some input caching depth when readind input stream?? Wherre?? Many thanks.
many packet missing. i'm not sure why it happens.
While decoding video, h264 codec complains it has not enough data to decode entire frame (especially at the beginning of video playing). I thought it was only a problem of data cache, but I fixed this issue by using rtsp_transport parameter set to TCP instead of UDP. But I think it is not enoug to fix the real issue. As many video payers do, it is possible to consider caching input data until frmaes can be deocded entirely. But I dont know how yet.
@debosvi I think you are right. QtAV has not cache, it may decode an uncompelete frame. I will try to solve this problem. : )
my camera is an Axis Brand which is not well known about pts and continuous stream on network. i have added AVDict options like
AVDictionary *opts=NULL; av_dict_set(&opts, "rtsp_transport", "tcp", 0); avformat_open_input(&format_context, qPrintable(_file_name), NULL, &opts);
But not all rtsp streamers have such option
Does AVDict solve the problem? pts will be added internally? I'm not familiar with avdict.
Yes but only for camera (streamer) which allow such option. VLC rtsp stream is not compatible with this option for example (by default I think and I had not search more)
So I have to add dict support
how and for which class?? it is up to you or not, your choice!!
I found a bug around clock comparison in AVClock class. The fact is that QElapsed timer derived progressively between restart and timeout (a unary insignificant slice but repeated several times becomes significant). It could have the issue we faced.
Instead of having restartable timer, I fixed the issue in my side with continuous timer and then the issue disappeared.
i think we can add it in avdemuxer. issue 86 also talk about this.
do you still use qelapsedtimer? can you give a patch for clock?
I will send you a Unix patch (not really Qt). Then I think you can transpose it to Qt.
how can I send you a patch file??
you can paste here, or use gist
I tried to paste my file, but the HMI adds some spurious presentation (not very readable afterwards) Git you mean?? How appart from pull request??
you can see Gist on the top of this page. click it and you can paste something. Then past the gist url here
https://gist.github.com/debosvi/7985027
@debosvi I have added dict api.
QHash<QByteArray, QByteArray> dict;
dict.insert("rtsp_transport", "tcp");
mpPlayer->setOptionsForFormat(dict);
you can test now
I use another QElapsedTimer to correct pts periodically to reduce the accumulative error. the error should always be not greater than the error of calling restart() once. this works fine for me.
see commit 6c7790fe28019fbe1c4181e437b8521eaf6b9e7b
@debosvi I don't use your patch because it's not cross-platform.
Okay thank you. I will test soon on my platform.
hey @wise, is there any e-mail I’m able to contact you? Sorry about sending in this non related thread, but it was the only way I found. This is regarding a job proposal.