1.26.4 Error while decoding frame errors

[pok]

I am interested in your error problem. I wonder whether it is related to my forum topic about 'make' fails. I wrote about: avcodec_decode_video2 being only in libavcodec 54 and above.

For example, the latest Ubuntu Server 12.04.03 version has libavcodec version 53

However, avcodec.decode_video is deprecated since libavcodec54. Yet your latest ffmpeg is compiled with avcodec_decode_video2 ( in libavcodec55).

So is there an ffmpeg mismatch, or a conflict of versions going on? Just a novice thought!

I think the reason is that ... just need to add the directive conditional compilation ...

[codabiz]

Many thanks Pok I already have a forum topic on this, but staying on topic.

As there seem to be a lot of issues with ffmpeg, I am really asking the question whether decoding frame errors are dependent on libavcodec version, as avcodec_decode_video is now deprecated in the latest version of ffmpeg (now avcodev_decode_video2) ?

[chippy99]

I have three different types of camera, Vivotek IP7134, Vivotek IP8133 and AverMedia SF1301. All worked ok on 1.26.3. The Vivotek 8133 is the only camera that supports h.264. Vivoteks set to Protocol RTSP, Remote method RTP/RTSP. The Avermedia only works when set to RTP/Multicast.

[BlankMan]

Same problem here. Upgraded from 1.25.0 using rtsp mpg4 there to 1.26.4 and all 4 of my Vivotek cameras (IP8332, FD8134V, PZ7132, & FE8172V) encountered the "Error while decoding frame" problem. Switched them to ffmpeg rtsp://cam/live.sdp they all worked using mpg4. PZ7132 doesn't support H.264 so that's not an option.

Installed 1.26.3 and set the monitors to 'remote' again using rtsp://cam/live.sdp they all worked using mpg4.

PITA reverting to 1.26.3 from 1.26.4, zmupdata.pl wouldn't update the db to 1.26.3 threw an error at line 1054 so had to manually update the Config table in the db from 1.26.4 to 1.26.3 to get zoneminder to run.

[dvarapala]

Same problem here. Upgraded from 1.25.0 using rtsp mpg4 there to 1.26.4 and all 4 of my Vivotek cameras (IP8332, FD8134V, PZ7132, & FE8172V) encountered the "Error while decoding frame" problem.

I don't know about the other two, but the IP8332 and the FD8134 both work fine with 1.26.4 in MJPEG mode.

FWIW.

[BlankMan]

Same problem here. Upgraded from 1.25.0 using rtsp mpg4 there to 1.26.4 and all 4 of my Vivotek cameras (IP8332, FD8134V, PZ7132, & FE8172V) encountered the "Error while decoding frame" problem.

I don't know about the other two, but the IP8332 and the FD8134 both work fine with 1.26.4 in MJPEG mode.

FWIW.

Yeah except mjpeg uses a lot of bandwidth. Even at 15fps. 1920x1920x24x15. 1,327,104,000. 1.3Gb/sec not including packet overhead. My NIC's are only 1G... And that's only one of the four on the subnet. Got to stream.

[dvarapala]

Yeah except mjpeg uses a lot of bandwidth. Even at 15fps. 1920x1920x24x15. 1,327,104,000. 1.3Gb/sec not including packet overhead. My NIC's are only 1G... And that's only one of the four on the subnet. Got to stream.[/quote]

Suit yourself, but I currently have 9 IP cameras on my 1Gb Ethernet LAN, including a 5 Megapixel Axis and 5 1.X Megapixel cams, and all but one (the Dahua) are streaming MJPEG at full frame-rate to a single ZoneMinder box and I'm not even coming close to maxing out my available bandwidth.

[BlankMan]

NM

[BlankMan]

NM

Should not have been allowed to operate a keyboard this morning.

Duplicated posts.

[BlankMan]

Suit yourself, but I currently have 9 IP cameras on my 1Gb Ethernet LAN, including a 5 Megapixel Axis and 5 1.X Megapixel cams, and all but one (the Dahua) are streaming MJPEG at full frame-rate to a single ZoneMinder box and I'm not even coming close to maxing out my available bandwidth.

What do you men suit myself? How do you put 1.3Gb/sec over a 1Gb/sec Ethernet link? Tell me that and maybe I'll try it! It doesn't matter many megapixels your cameras are, it matters what resolution you're using, what color depth you're using and what frame rate you're using.

You may be set to full frame rate that doesn't mean you getting full frame rate. Cameras may throttle frame rate based on light level and exposure. I see that with all my IP camera but not my coax cameras.

[pok]

ATTENTION
Everyone who cameras stopped work via rtsp after installing the release please provide external access to the broken camera.

Or prepare the contents of log files from the database and tcpdump.

Instructions for obtaining logs:
0. Set in ZM config maximum debug level
1. run console or xterm
2. enter ip li sh oiutput is
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:85:59:dd brd ff:ff:ff:ff:ff:ff

3. enter sudo tcpdump -i eth0 -s 0 -w ~/cam_srv.cap host _CAM_IP_ADDRESS_ or _ZMSERVER_IP_ADDRESS_
where eth0 shell replace (or not) to you interface to cam
colored word shell replace to cam and ZM server ip address
4. in ZM console run cam in Monitor mode
5. open screen with Monitor picture
6. in ZM console Stop cam capture
7. in system console or xterm press Ctrl+C
8. in system enter mysql -D_ZM_DATABASE_NAME_ -u_ZM_USER_NAME_ -p_ZM_USER_PASSWORD_ -h_HOST_WITH_ZM_DATABASE_ -e "select * from Logs where TimeKey>=unix_timestamp(now()- interval 10 minute);" > ~/Logs_db.txt
colored word shell replace to you values
9. attach files ~/cam_srv.cap and ~/Logs_db.txt to you post

[abalamut]

I did it.
Cam is D-lInk DCS-6113
tcp dum is quite big
http://ftp.cinepost.ru/temp/from_rd/tcp_dump.zip

[pok]

I did it.
Cam is D-lInk DCS-6113
tcp dum is quite big
http://ftp.cinepost.ru/temp/from_rd/tcp_dump.zip

As I can see these errors are not related to the process of encoding or decoding a ... this is an error getting a package ...
Now image is present, so there are many solutions
1. ostrich - change the output to a log to issue not a mistake but an informational message.
diff ./ostrich/src/zm_remote_camera_rtsp.cpp ./ZoneMinder-master/src/zm_remote_camera_rtsp.cpp

Code: Select all

273,274c273,274
<                       Debug( Logger::INFO, "Error while decoding frame %d", frameCount );
<                       Hexdump( Logger::INFO, buffer.head(), buffer.size()>256?256:buffer.size() );
---
>                       Error( "Error while decoding frame %d", frameCount );
>                       Hexdump( Logger::ERROR, buffer.head(), buffer.size()>256?256:buffer.size() );

2. workaround - use ffmpeg (can get "rain window", because that too is not entirely correct working with streams)
3. right way - rewrite work with RTP/RTSP stream

[TheKorn]

Yeah except mjpeg uses a lot of bandwidth. Even at 15fps. 1920x1920x24x15. 1,327,104,000. 1.3Gb/sec not including packet overhead. My NIC's are only 1G... And that's only one of the four on the subnet. Got to stream.

Your math is a bit off there...

A 1920x1920 camera? Haven't seen one. Likely you're really using 1920x1080. That'll cut down things considerably. (~711Mb/sec)

More to the point, you calculated the raw (uncompressed) bit rate. While not as nice as H264, mjpeg is compressed already; it's jpeg compression! Typically jpeg can achieve 10:1 (often better!) compression vs. raw uncompressed images. So now you'd be down in the neighborhood of 71Mb/sec or so.

I think that'd be do-able over a gig link. Maybe even a few! (Trying to insert some levity here!)

[abalamut]

1. ostrich - change the output to a log to issue not a mistake but an informational message.
diff ./ostrich/src/zm_remote_camera_rtsp.cpp ./ZoneMinder-master/src/zm_remote_camera_rtsp.cpp

Code: Select all

Code:
273,274c273,274
<                       Debug( Logger::INFO, "Error while decoding frame %d", frameCount );
<                       Hexdump( Logger::INFO, buffer.head(), buffer.size()>256?256:buffer.size() );
---
>                       Error( "Error while decoding frame %d", frameCount );
>                       Hexdump( Logger::ERROR, buffer.head(), buffer.size()>256?256:buffer.size() );

Unfortunately I have not enough skill to compile ZM from source.
I installed ZM using this guide
http://www.zoneminder.com/wiki/index.ph ... e_easy_way
I use Ubuntu 12.04.3 x64. Can you provide deb file as fix?

2. workaround - use ffmpeg (can get "rain window", because that too is not entirely correct working with streams)

I have problem with ffmpeg. Some time picture looking like res solid. Some time it is "rain window" .

3. right way - rewrite work with RTP/RTSP stream

What is it?