[Libav-user] IP cam accessing directly and from dshow speeddifferences.

[Matthew Einhorn]

On Sat, Jun 15, 2013 at 3:50 PM, Don Moir <donmoir at comcast.net> wrote:

> 2013/6/14 Matthew Einhorn <moiein2000 at gmail.com>:
>>
>>> Hi,
>>>
>>> I have a WANSCAM IP camare (AJ-C2WA-C198) which I'm testing in
>>> ffplay/ffmpeg. I noticed that playing it through its http address is much
>>> slower than when playing it with direct show. I'm linking to logs for
>>> both
>>> as run in ffplay.
>>>
>>> ffplay displayed the video through direct http access very slow and
>>> choppy
>>> using this command :ffplay -report -loglevel debug -i
>>> http://user:pwd@IP:99/**videostream.asf -an (see
>>> http://paste.ubuntu.com/**5765942/ <http://paste.ubuntu.com/5765942/>).
>>>
>>> To use direct show, I installed a driver from http://alax.info/blog/1223
>>> which converts a IP cam to direct show and the ffplay speed was faster
>>> although still choppy, even with a large realy time buffer. The command
>>> line
>>> was "ffplay -loglevel debug -report -f dshow -i "video=wanscam" -an
>>> -rtbufsize 1000000" (see http://paste.ubuntu.com/**5765952/<http://paste.ubuntu.com/5765952/>
>>> )
>>>
>>> Finally, viewing the camera directly from Firefox was much faster than
>>> either method and it wasn't choppy at all. I am looking for
>>> recommendations
>>> as to what I can do in ffmpeg to speed it up so that it's as fast as
>>> Firefox. In the end I'd be using the API not ffplay.
>>>
>>
> It appears a filter is being used when using ffplay and could be a
> problem, but here's a few things I found when connecting to IP cam.
>
> Some of this might have changed since last time I checked which has been
> awhile.
>
> 1) the probe time may effect the timestamps of the video packets. In other
> words, if it takes 5 seconds to do the probe, packet times can be 5 seconds
> late.
>
> 2) audio can effect things quite a bit. For my IP camera its way out of
> sync and slowed things and so just did not bother with audio for the time
> being. It was way of sync with the installed software as well and not just
> ffmpeg.
>
> 3) When I got down and dirty with the camera IP API things got better. I
> still believe that to get the best possible performance you need to 'know'
> the camera, meaning some database would be useful.
>
> 4) I have a special interface for IP and USB cameras and not a generic
> interface. This is for a few reasons, but for one it is flagged to ignore
> timestamps. The timestamps are way off and I want to see the video in real
> time, not 5 to 10 seconds later.
>
> I have found there is a lot to check for IP cameras and various ways to
> interface. Normally there is going to be an optimal interface and you just
> need to play with it.
>
>
>
Thanks for the replies. I believe I partially figured out how to get a nice
fps, at least in vlc, now the question is how to achieve it in ffmpeg. I
know very little about network protocols so I'm partially walking in the
dark here. But this time I'm using the cam directly without any middleware.

Anyway, before,I streamed with http://xxx/videostream.*asf* which resulted
in slow speeds, even in VLC. Using http://xxx/videostream.*cgi* instead
(which is what firefox uses) with :network-caching=0 resulted in speeds as
fast as firefox.

The problem is that when trying "ffplay -loglevel debug -analyzeduration
999999999 -probesize 999999999
http://CPL:lab@169.254.5.105:99/videostream.cgi" I get

Format ingenient probed with size=2048 and score=50q=    0B f=0/0
[ingenient @ 000000000277a2c0] File position before
avformat_find_stream_info() is 0
[ingenient @ 000000000277a2c0] Could not find codec parameters for stream 0
(Video: mjpeg): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[ingenient @ 000000000277a2c0] File position after
avformat_find_stream_info() is 4
http://CPL:lab@169.254.5.105:99/videostream.cgi: could not find codec
parameters
[AVIOContext @ 0000000002779dc0] Statistics: 27 bytes read, 0 seeks

When I tried wgets on the link I get a 27 byte file (attached). I guess
something is wrong with the stream, but vlc is able to read it so I'm
wondering how I can get ffmpeg to read it as well? increasing probesize and
analyzeduration has no effect.

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130619/7fb5293b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: videostream
Type: application/octet-stream
Size: 27 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130619/7fb5293b/attachment.obj>