[Libav-user] get mpeg4 streams with rtsp protocol

[Alessandro Antonello]

2011/6/15 luke <lclemens at gmail.com>:
> I have tried that. On some cameras, such as the axis, that does make
> the errors go away (but causes video delay). On others, like the
> panasonic, it doesn't work because they don't support TCP mode. Also,
> I don't think sending RTP over TCP is very efficient when bandwidth is
> limited and could cause delay. I could be wrong, but I'm under the
> impression that RTP was designed to work with UDP datagrams.
>
>
> On Wed, Jun 15, 2011 at 4:11 PM, av_vince [via libav-users]
> <ml-node+3600712-1203814277-245513 at n4.nabble.com> wrote:
>>
>>
>> 2011/6/15 luke <[hidden email]>
>>>
>>> I'm having this same problem with two axis ip cameras and two panasonic ip
>>> cameras!! The video gets messed up with ghosting and other artifacts,
>>> especially in the lower half. The console spits out hundreds of errors
>>> each
>>> minute.
>>>
>>> To reproduce the error, go to: http://ffmpeg.zeranoe.com/builds/ and get
>>> the
>>> latest 32 bit static build for, (the one I have is 1929807). Then open a
>>> IP
>>> camera rtsp stream via ffplay. If you don't have one, I found one that's
>>> accessible online that you can access using:
>>>
>>> ffplay rtsp://195.200.199.8/mpeg4/media.amp
>>>
>>> There will be a lot of errors in the output console for ffplay.
>>>
>>> A few years ago we used some older versions that didn't have any mpeg4
>>> errors, but they had another problem that caused the video to timeout
>>> after
>>> 1 minute. So it seems like the timeout problem was fixed, but replaced by
>>> this mpeg4 issue. There is a post in the ffmpeg group that describes the
>>> same issue. And another one here:
>>> http://web.archiveorange.com/archive/v/yR2T4qtfjQ1es89IeoVN .
>>>
>>> It's not just ffplay either. I tried it with several example apps like the
>>> ffmpeg sdl tutorial here: http://dranger.com/ffmpeg/ and my own code -
>>> they
>>> all get the same mpeg4 errors. The common code for these apps is based on
>>> av_open_input_file(), av_find_stream_info(), and av_read_frame().
>>>
>>> I've tried it on several different windows computers. I'm going to try it
>>> on
>>> Ubuntu tonight.
>>>
>>> Is there a chance that perhaps we just need a certain flag or option
>>> enabled?
>>>
>>> I will look into the source code and see if I can find the bug, but I'm
>>> pretty new with mpeg4 codec specifics so it would help a lot if someone
>>> can
>>> give me a better idea of where to look. I don't even know where to begin -
>>> the rtp parsing or the mpeg4 decompression?

I had some experience with Axis cameras in the past. Is almost impossible
to use UDP over an WiFi network. Too much packet lost. With TCP connection I
got the delay you are talking about. After a couple of minutes the
delay was almost
gone. Seems that the encoder has some guilt in this matter.

I also discovered that in Axis cameras, some frames had its payload missing.
The decoder just have to thrust in the received data. Maybe that was the source
of problems with delay. I don't know for sure since there are several years that
I don't work with video any more. Just a thought.

Alessandro Antonello