starlight.2014q4
2014-10-03 04:34:06 UTC
Hello,
Have new Dahua IPC-HDW4300S working well.
I've found that using VLC 2.1.5 (Windows 64-bit
on W2K8 server) to capture a video stream
from this camera results in dropped
frames attributable to VLC.
Capturing with 'ffmpeg' drops no frames
and results in a perfect MPEG-TS recording.
Before I submit a bug report, it seems
a good idea to ask if I'm missing a command
or configuration option.
Here is the VLC command:
C:\programs64\VideoLAN\VLC\vlc.exe --intf rc --rc-host=127.0.0.1:4212 --high-priority --rtsp-tcp --rtsp-frame-buffer-size=20971520 "rtsp://user:password at camera01:554/cam/realmonitor?channel=1&subtype=0&unicast=true" ":sout=#transcode{acodec=none}:duplicate{dst=file{dst=D:/log/2014xxxx.ts,no-overwrite}}" :sout-keep
And here is the FFMPEG command:
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://user:password at camera01:554/cam/realmonitor?channel=1&subtype=0&unicast=true" -vcodec copy -acodec copy D:\log\2014xxxx.ts >d:\log\2014xxxx.ffcout 2>d:\log\2014xxxx.ffcerr
I am quite sure VLC is the problem here. Was
originally capturing UDP multicast and ran
a Wireshark packet capture in parallel with
the VLC capture on the same machine. Used
'ffmpeg' to find the H264 frame gaps and then
used 'videosnarf' to extract the same data
from the PCAP file where VLC had missed
a frame. Using 'ffplay' I stepped frame-
by-frame through both the VLC capture and
the Wireshark capture and clearly identified
frames dropped by VLC but not by Wireshark.
Wireshark shows zero RTP frame gaps when
Telephony->RTP->Stream_Analysis is run.
Then switched to TCP to be certain that the
Windows UDP stack was not the problem
and still saw as many dropped frames.
They tried 'ffmpeg' with TCP and it drops
zero frames.
In all cases VLC and FFMPEG are set
to real-time priority 24 with Process
Explorer. CPU is Intel i7-920 (4 cores,
8 thread, 2.67 MHz) and RAM is 6G with
3G available.
The stream is a 3M CBR at 20 FPS set
to maximum 8 MBPS (1 Mbyte/sec).
Thanks!
Have new Dahua IPC-HDW4300S working well.
I've found that using VLC 2.1.5 (Windows 64-bit
on W2K8 server) to capture a video stream
from this camera results in dropped
frames attributable to VLC.
Capturing with 'ffmpeg' drops no frames
and results in a perfect MPEG-TS recording.
Before I submit a bug report, it seems
a good idea to ask if I'm missing a command
or configuration option.
Here is the VLC command:
C:\programs64\VideoLAN\VLC\vlc.exe --intf rc --rc-host=127.0.0.1:4212 --high-priority --rtsp-tcp --rtsp-frame-buffer-size=20971520 "rtsp://user:password at camera01:554/cam/realmonitor?channel=1&subtype=0&unicast=true" ":sout=#transcode{acodec=none}:duplicate{dst=file{dst=D:/log/2014xxxx.ts,no-overwrite}}" :sout-keep
And here is the FFMPEG command:
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://user:password at camera01:554/cam/realmonitor?channel=1&subtype=0&unicast=true" -vcodec copy -acodec copy D:\log\2014xxxx.ts >d:\log\2014xxxx.ffcout 2>d:\log\2014xxxx.ffcerr
I am quite sure VLC is the problem here. Was
originally capturing UDP multicast and ran
a Wireshark packet capture in parallel with
the VLC capture on the same machine. Used
'ffmpeg' to find the H264 frame gaps and then
used 'videosnarf' to extract the same data
from the PCAP file where VLC had missed
a frame. Using 'ffplay' I stepped frame-
by-frame through both the VLC capture and
the Wireshark capture and clearly identified
frames dropped by VLC but not by Wireshark.
Wireshark shows zero RTP frame gaps when
Telephony->RTP->Stream_Analysis is run.
Then switched to TCP to be certain that the
Windows UDP stack was not the problem
and still saw as many dropped frames.
They tried 'ffmpeg' with TCP and it drops
zero frames.
In all cases VLC and FFMPEG are set
to real-time priority 24 with Process
Explorer. CPU is Intel i7-920 (4 cores,
8 thread, 2.67 MHz) and RAM is 6G with
3G available.
The stream is a 3M CBR at 20 FPS set
to maximum 8 MBPS (1 Mbyte/sec).
Thanks!