I, I have one workstation with 2 xeon e5410 with 16GB ram.
Capture start with sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS.
With this configuration I have this error on recorder with dropped frames:
_16:48:31.499 IngexRecorderImpl::Start(), tc 16:48:31:09, pre-roll 10
16:48:31.537 start_record_thread(input2 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input3 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input0 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input1 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input0 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.539 start_record_thread(input2 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.539 start_record_thread(input1 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.601 start_record_thread(input3 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.601 start_record_thread(input0 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
16:48:31.632 start_record_thread(input2 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
Warning: Adding 2 channels of silence to support Avid import
16:48:31.694 start_record_thread(input1 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
16:48:31.694 start_record_thread(input3 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
16:49:13.103 input1 index 1 frames waiting in ring buffer 95, max 170
16:49:14.891 input3 index 1 frames waiting in ring buffer 90, max 170
16:49:18.004 input1 index 1 frames waiting in ring buffer 123, max 170
16:49:21.484 input1 index 1 frames waiting in ring buffer 86, max 170
16:49:25.099 input1 index 1 frames waiting in ring buffer 91, max 170
16:49:29.018 input1 index 1 frames waiting in ring buffer 98, max 170
16:49:48.034 input1 index 1 frames waiting in ring buffer 96, max 170
16:49:51.731 input3 index 1 frames waiting in ring buffer 110, max 170
16:49:52.669 input1 index 1 frames waiting in ring buffer 116, max 170
16:49:57.411 input3 index 1 frames waiting in ring buffer 141, max 170
16:49:58.437 input1 index 1 frames waiting in ring buffer 144, max 170
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:04:02, last 16:49:57:03
16:50:04.353 input3 index 1 frames waiting in ring buffer 174, max 170
input3 dropped 4 frames!
input3 index 1 Timecode discontinuity: -169 frames missing - current 16:49:57:12, last 16:50:04:05
16:50:05.250 input1 index 1 frames waiting in ring buffer 171, max 170
input1 dropped 1 frames!
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:08, last 16:49:58:09
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:11, last 16:50:05:08
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:10, last 16:49:58:11
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:19, last 16:50:05:16
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:19, last 16:49:58:20
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:22, last 16:50:05:19
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:06:14, last 16:49:59:15
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:07:08, last 16:50:00:09
16:50:11.134 IngexRecorderImpl::Stop(), tc 16:50:11:00, post-roll 10
16:50:11.445 input2 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.453 input1 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.455 input2 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.457 input2 index 1 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.461 input0 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.463 input3 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.468 input0 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.488 input3 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.513 input1 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:12.559 input0 index 1 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:13.123 input3 index 1 frames waiting in ring buffer 220, max 170
input3 dropped 50 frames!
input3 index 1 Timecode discontinuity: -123 frames missing - current 16:50:06:07, last 16:50:11:04
16:50:14.167 input1 index 1 frames waiting in ring buffer 223, max 170
input1 dropped 53 frames!
input1 index 1 Timecode discontinuity: -120 frames missing - current 16:50:07:08, last 16:50:12:02
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:04, last 16:50:08:05
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:06, last 16:50:08:07
input1 index 1 Timecode discontinuity: -173 frames missing - current 16:50:08:09, last 16:50:15:06
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:09, last 16:50:08:10
16:50:19.005 input3 index 1 duration 2511 reached (total=2511 written=2457 dropped=54)
16:50:19.017 input1 index 1 duration 2511 reached (total=2511 written=2457 dropped=54)
Recording dropped frames!
_
Cpus working at 60%, ram at 100%.
If We recording 2 sdi channels, the aren't error., why??'
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
after some test i've saw this behavior:
1) 4 channels capture (6,92 secs) ring_len, coded 2:1 mjpeg, 20:1 mjpeg, mpeg4 QT
"frame backlog 1 or 2" in different channels several time every minute and some "Timestamp differs from expected by..12 to 640 ms"
cpu run between 65 to 75% with some spike to 85%
2) 3 channels capture (9,28 secs) ring_len, coded as above
"frame backlog 1" in different channels rarely and never "Timestamp differs from expected by.."
cpu run between 55 to 65% sometime 70%
3) 2 channels capture (14,04 secs) ring_len, same codec
one "frame backlog 1" and no "Timestamp differs from expected by.."
cpu run between 45 and 55% sometime 60%
is the ring_len to short for 4 channels?
is cpu to slow?
we have PC with 2 xeon e5410 with 16GB ram
1 raid1 for the system
1 raid0 software with 2 raid1 hardware for video
thank you for great job
vasco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The messages "frame backlog" from the capture process relate to the FIFO on the DVS board which is only about 8 frames, I think. Changing ring length won't make any difference there.
I would have thought your system was powerful enough. How does it get on doing just 2:1? It can be interesting to look at individual CPU usage with gkrellm. There is no threading for 2:1 so you should see 4 cores doing the encodes.
Another thing to try is boot option CPUFREQ=no which stops the system lowering clock speed when it thinks it can get away with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi John,
if I recorde 2:1 I have the same problems of frame backlog.
If I add at boot option cpufreq=no It work bad with cpu at 85%.
If I don't add cpufreq=no It work best.
thank
stefano
ngex@INGEX-CLIENT:~/ap-workspace/ingex/studio/capture> sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS
root's password:
driver version = (3,4,0,8)
24 11:44:11.481830 card 0: device present (720x576 25/1 interlaced)
24 11:44:11.521641 card 0: second channel (720x576 25/1 interlaced)
24 11:44:11.521755 card 1: device present (720x576 25/1 interlaced)
24 11:44:11.561439 card 1: second channel (720x576 25/1 interlaced)
24 11:44:11.561585 Primary capture PAL 16x9, YUV Planar 4:2:2
24 11:44:11.561634 Secondary capture PAL 16x9, YUV Planar 4:2:0 (MPEG sampling)
24 11:44:11.561670 Master timecode type is System using channel 0
24 11:44:11.561706 Using System to determine number of frames to recover when video re-aquired
buffer size 1073741824 (1024.000 MiB) calculated per channel ring_len 173
element_size=1505792(0x16fa00) ring_len=173 (6.92 secs) (total=260502016)
24 11:44:11.564800 chan 0: starting capture thread
24 11:44:11.564893 chan 1: starting capture thread
24 11:44:11.564978 chan 2: starting capture thread
24 11:44:11.565113 chan 3: starting capture thread
24 11:44:11.565284 chan 0: fifo init/start completed
24 11:44:11.580313 chan 1: fifo init/start completed
24 11:44:11.585495 chan 2: fifo init/start completed
24 11:44:11.590512 chan 3: fifo init/start completed
24 11:44:11.717234 chan 0: Video signal OK
24 11:44:11.737544 chan 1: Video signal OK
24 11:44:11.739598 chan 2: Video signal OK
24 11:44:11.740289 chan 3: Video signal OK
24 11:44:12.491902 chan 1: frame backlog 10
24 11:44:12.491991 chan 0: frame backlog 10
24 11:44:12.496243 chan 1: frame backlog 9
24 11:44:12.499355 chan 0: frame backlog 9
24 11:44:12.502071 chan 1: Timestamp differs from expected by -640 ms
24 11:44:12.502105 chan 1: frame backlog 8
24 11:44:12.504323 chan 0: Timestamp differs from expected by -640 ms
24 11:44:12.504375 chan 0: frame backlog 8
24 11:44:12.505591 chan 1: frame backlog 7
24 11:44:12.507919 chan 0: frame backlog 7
24 11:44:12.509269 chan 1: frame backlog 6
24 11:44:12.511478 chan 0: frame backlog 6
24 11:44:12.513144 chan 1: frame backlog 5
24 11:44:12.515464 chan 0: frame backlog 5
24 11:44:12.516600 chan 1: frame backlog 4
24 11:44:12.518957 chan 0: frame backlog 4
24 11:44:12.520065 chan 1: frame backlog 3
24 11:44:12.522691 chan 0: frame backlog 3
24 11:44:12.523890 chan 1: frame backlog 2
24 11:44:12.527406 chan 1: frame backlog 1
24 11:44:12.531406 chan 0: frame backlog 2
24 11:44:12.536175 chan 0: frame backlog 1
24 11:44:12.937261 chan 1: Timestamp differs from expected by 640 ms
24 11:44:12.940170 chan 0: Timestamp differs from expected by 640 ms
If I stop the capture and I relaunch the capture I don't have immediately frame backlog.
done - exiting
ingex@INGEX-CLIENT:~/ap-workspace/ingex/studio/capture> sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS
driver version = (3,4,0,8)
24 11:44:48.298312 card 0: device present (720x576 25/1 interlaced)
24 11:44:48.298369 card 0: second channel (720x576 25/1 interlaced)
24 11:44:48.298406 card 1: device present (720x576 25/1 interlaced)
24 11:44:48.298453 card 1: second channel (720x576 25/1 interlaced)
24 11:44:48.298488 Primary capture PAL 16x9, YUV Planar 4:2:2
24 11:44:48.298501 Secondary capture PAL 16x9, YUV Planar 4:2:0 (MPEG sampling)
24 11:44:48.298506 Master timecode type is System using channel 0
24 11:44:48.298510 Using System to determine number of frames to recover when video re-aquired
buffer size 1073741824 (1024.000 MiB) calculated per channel ring_len 173
element_size=1505792(0x16fa00) ring_len=173 (6.92 secs) (total=260502016)
24 11:44:48.301209 chan 0: starting capture thread
24 11:44:48.301284 chan 1: starting capture thread
24 11:44:48.301340 chan 2: starting capture thread
24 11:44:48.301410 chan 3: starting capture thread
24 11:44:48.301814 chan 0: fifo init/start completed
24 11:44:48.317557 chan 1: fifo init/start completed
24 11:44:48.322820 chan 2: fifo init/start completed
24 11:44:48.326804 chan 3: fifo init/start completed
24 11:44:48.457175 chan 0: Video signal OK
24 11:44:48.478312 chan 1: Video signal OK
24 11:44:48.483051 chan 2: Video signal OK
24 11:44:48.483392 chan 3: Video signal OK
Why???
Gkrellm:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be that you are running short of CPU power. You could try removing the 420 conversion (-s MPEG) in capture and having 2:1 as the only encode format. See if it will do 4 channels like that.
In your first output listing from dvs_sdi, I presume you started recording just before 11:44:12 when the capture backlog appeared. When you relaunched it, you couldn't have been recording, hence no backlog. If you are betting backlog in capture when not even recording then something is wrong.
Also check that some background task is not holding up the system for a short time. The beagle indexer is an example of something that can kick in and cause problems.
Are you using a player? If not accelerated by graphics card, this can use significant CPU.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hello John,
we try without MPEG conversion encoding just 2:1 the cpu work between 45/55% for 4 Channels
some frame backlog still appear
In your first output listing from dvs_sdi, I presume you started recording just before 11:44:12 when the capture backlog appeared
no we didn't start record
If you are betting backlog in capture when not even recording then something is wrong.
yes we think so
we made last test without nx server and the sistem seem work better
one question
we are using dvs sdk 3.4.0.8. with firmware 3.2.76.6_19_15
do you test it?
if not wich sdk/firmware are you use?
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you mean run Ingexgui on a remote machine? All you have to do is make sure you give it the right CORBA reference for the name server the recorder is connecting to. If you want it to be able to play back recordings on the computer monitor, you will need to export the recorder's video disk and mount it on the remote machine with the same mount point (/<machine name>/video/). You cannot play back recordings through the recorder's DVS card this way.
Alternatively, you can run Ingexgui (or the whole of Ingex) on the recorder machine with ssh -X, or better (as it doesn't use encryption and so makes less CPU demand), using X-forwarding. You will then be able to play back through the DVS card.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frame backlog is the number of DVS input fifo buffers in use - 1. We expect one to be in use (with the next frame); more than that indicates they are not being read fast enough.
hi ,
we do not use player for this test
today we ingest 3 channel in capture coded 2:1 and 20:1 with no secondary buffer and everything goes well
no frame backlog in capture and clean recorder with no drop framen (test run for one hour)
the second test 3 channel in capture coded 2:1, 20:1, mpeg4 with mpeg secondary buffer
on capture just one frame backlog and two timestamp differ 10 ms
on recorder several frame waiting in ring buffer but no drop frames (test run for one hour)
our cpu clock speed it's 2.33 GHz . your recommended hardware required is Intel Core2 QX6700 at 2.66 GHz
do you think that here is the problem?
witch cpu do you use?
cpu speed?
thanks
vasco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We did the test for 2 days with a different processor: i7-2600 3.4 GHz with 6GB ram.
No error.
Only capture a few frames backlog (1), but without recording any data loss.
It 's the frequency of the processor?
thanks
stefano
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I, I have one workstation with 2 xeon e5410 with 16GB ram.
Capture start with sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS.
With this configuration I have this error on recorder with dropped frames:
_16:48:31.499 IngexRecorderImpl::Start(), tc 16:48:31:09, pre-roll 10
16:48:31.537 start_record_thread(input2 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input3 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input0 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input1 index 0, start_tc=16:48:30:24 IMX50 MXF OP-1A)
16:48:31.537 start_record_thread(input0 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.539 start_record_thread(input2 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.539 start_record_thread(input1 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.601 start_record_thread(input3 index 1, start_tc=16:48:30:24 IMX30 MXF OP-1A)
16:48:31.601 start_record_thread(input0 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
16:48:31.632 start_record_thread(input2 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
Warning: Adding 2 channels of silence to support Avid import
16:48:31.694 start_record_thread(input1 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
16:48:31.694 start_record_thread(input3 index 2, start_tc=16:48:30:24 MPEG4 Quicktime)
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
Warning: Adding 2 channels of silence to support Avid import
16:49:13.103 input1 index 1 frames waiting in ring buffer 95, max 170
16:49:14.891 input3 index 1 frames waiting in ring buffer 90, max 170
16:49:18.004 input1 index 1 frames waiting in ring buffer 123, max 170
16:49:21.484 input1 index 1 frames waiting in ring buffer 86, max 170
16:49:25.099 input1 index 1 frames waiting in ring buffer 91, max 170
16:49:29.018 input1 index 1 frames waiting in ring buffer 98, max 170
16:49:48.034 input1 index 1 frames waiting in ring buffer 96, max 170
16:49:51.731 input3 index 1 frames waiting in ring buffer 110, max 170
16:49:52.669 input1 index 1 frames waiting in ring buffer 116, max 170
16:49:57.411 input3 index 1 frames waiting in ring buffer 141, max 170
16:49:58.437 input1 index 1 frames waiting in ring buffer 144, max 170
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:04:02, last 16:49:57:03
16:50:04.353 input3 index 1 frames waiting in ring buffer 174, max 170
input3 dropped 4 frames!
input3 index 1 Timecode discontinuity: -169 frames missing - current 16:49:57:12, last 16:50:04:05
16:50:05.250 input1 index 1 frames waiting in ring buffer 171, max 170
input1 dropped 1 frames!
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:08, last 16:49:58:09
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:11, last 16:50:05:08
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:10, last 16:49:58:11
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:19, last 16:50:05:16
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:05:19, last 16:49:58:20
input3 index 1 Timecode discontinuity: -173 frames missing - current 16:49:58:22, last 16:50:05:19
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:06:14, last 16:49:59:15
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:07:08, last 16:50:00:09
16:50:11.134 IngexRecorderImpl::Stop(), tc 16:50:11:00, post-roll 10
16:50:11.445 input2 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.453 input1 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.455 input2 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.457 input2 index 1 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.461 input0 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.463 input3 index 2 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.468 input0 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.488 input3 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:11.513 input1 index 0 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:12.559 input0 index 1 duration 2511 reached (total=2511 written=2511 dropped=0)
16:50:13.123 input3 index 1 frames waiting in ring buffer 220, max 170
input3 dropped 50 frames!
input3 index 1 Timecode discontinuity: -123 frames missing - current 16:50:06:07, last 16:50:11:04
16:50:14.167 input1 index 1 frames waiting in ring buffer 223, max 170
input1 dropped 53 frames!
input1 index 1 Timecode discontinuity: -120 frames missing - current 16:50:07:08, last 16:50:12:02
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:04, last 16:50:08:05
input3 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:06, last 16:50:08:07
input1 index 1 Timecode discontinuity: -173 frames missing - current 16:50:08:09, last 16:50:15:06
input1 index 1 Timecode discontinuity: 173 frames missing - current 16:50:15:09, last 16:50:08:10
16:50:19.005 input3 index 1 duration 2511 reached (total=2511 written=2457 dropped=54)
16:50:19.017 input1 index 1 duration 2511 reached (total=2511 written=2457 dropped=54)
Recording dropped frames!
_
Cpus working at 60%, ram at 100%.
If We recording 2 sdi channels, the aren't error., why??'
thanks
What disc system do you have?
1 raid1 for the system
1 raid0 software with 2 raid1 hardware for video
I have the same error when i try to write over the system disk…..
after some test i've saw this behavior:
1) 4 channels capture (6,92 secs) ring_len, coded 2:1 mjpeg, 20:1 mjpeg, mpeg4 QT
"frame backlog 1 or 2" in different channels several time every minute and some "Timestamp differs from expected by..12 to 640 ms"
cpu run between 65 to 75% with some spike to 85%
2) 3 channels capture (9,28 secs) ring_len, coded as above
"frame backlog 1" in different channels rarely and never "Timestamp differs from expected by.."
cpu run between 55 to 65% sometime 70%
3) 2 channels capture (14,04 secs) ring_len, same codec
one "frame backlog 1" and no "Timestamp differs from expected by.."
cpu run between 45 and 55% sometime 60%
is the ring_len to short for 4 channels?
is cpu to slow?
we have PC with 2 xeon e5410 with 16GB ram
1 raid1 for the system
1 raid0 software with 2 raid1 hardware for video
thank you for great job
vasco
The messages "frame backlog" from the capture process relate to the FIFO on the DVS board which is only about 8 frames, I think. Changing ring length won't make any difference there.
I would have thought your system was powerful enough. How does it get on doing just 2:1? It can be interesting to look at individual CPU usage with gkrellm. There is no threading for 2:1 so you should see 4 cores doing the encodes.
Another thing to try is boot option CPUFREQ=no which stops the system lowering clock speed when it thinks it can get away with it.
Hi John,
if I recorde 2:1 I have the same problems of frame backlog.
If I add at boot option cpufreq=no It work bad with cpu at 85%.
If I don't add cpufreq=no It work best.
thank
stefano
ngex@INGEX-CLIENT:~/ap-workspace/ingex/studio/capture> sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS
root's password:
driver version = (3,4,0,8)
24 11:44:11.481830 card 0: device present (720x576 25/1 interlaced)
24 11:44:11.521641 card 0: second channel (720x576 25/1 interlaced)
24 11:44:11.521755 card 1: device present (720x576 25/1 interlaced)
24 11:44:11.561439 card 1: second channel (720x576 25/1 interlaced)
24 11:44:11.561585 Primary capture PAL 16x9, YUV Planar 4:2:2
24 11:44:11.561634 Secondary capture PAL 16x9, YUV Planar 4:2:0 (MPEG sampling)
24 11:44:11.561670 Master timecode type is System using channel 0
24 11:44:11.561706 Using System to determine number of frames to recover when video re-aquired
buffer size 1073741824 (1024.000 MiB) calculated per channel ring_len 173
element_size=1505792(0x16fa00) ring_len=173 (6.92 secs) (total=260502016)
24 11:44:11.564800 chan 0: starting capture thread
24 11:44:11.564893 chan 1: starting capture thread
24 11:44:11.564978 chan 2: starting capture thread
24 11:44:11.565113 chan 3: starting capture thread
24 11:44:11.565284 chan 0: fifo init/start completed
24 11:44:11.580313 chan 1: fifo init/start completed
24 11:44:11.585495 chan 2: fifo init/start completed
24 11:44:11.590512 chan 3: fifo init/start completed
24 11:44:11.717234 chan 0: Video signal OK
24 11:44:11.737544 chan 1: Video signal OK
24 11:44:11.739598 chan 2: Video signal OK
24 11:44:11.740289 chan 3: Video signal OK
24 11:44:12.491902 chan 1: frame backlog 10
24 11:44:12.491991 chan 0: frame backlog 10
24 11:44:12.496243 chan 1: frame backlog 9
24 11:44:12.499355 chan 0: frame backlog 9
24 11:44:12.502071 chan 1: Timestamp differs from expected by -640 ms
24 11:44:12.502105 chan 1: frame backlog 8
24 11:44:12.504323 chan 0: Timestamp differs from expected by -640 ms
24 11:44:12.504375 chan 0: frame backlog 8
24 11:44:12.505591 chan 1: frame backlog 7
24 11:44:12.507919 chan 0: frame backlog 7
24 11:44:12.509269 chan 1: frame backlog 6
24 11:44:12.511478 chan 0: frame backlog 6
24 11:44:12.513144 chan 1: frame backlog 5
24 11:44:12.515464 chan 0: frame backlog 5
24 11:44:12.516600 chan 1: frame backlog 4
24 11:44:12.518957 chan 0: frame backlog 4
24 11:44:12.520065 chan 1: frame backlog 3
24 11:44:12.522691 chan 0: frame backlog 3
24 11:44:12.523890 chan 1: frame backlog 2
24 11:44:12.527406 chan 1: frame backlog 1
24 11:44:12.531406 chan 0: frame backlog 2
24 11:44:12.536175 chan 0: frame backlog 1
24 11:44:12.937261 chan 1: Timestamp differs from expected by 640 ms
24 11:44:12.940170 chan 0: Timestamp differs from expected by 640 ms
If I stop the capture and I relaunch the capture I don't have immediately frame backlog.
done - exiting
ingex@INGEX-CLIENT:~/ap-workspace/ingex/studio/capture> sudo nice -10 ./dvs_sdi -c 4 -mode PAL -f YUV422 -s MPEG -mc 0 -tt SYS
driver version = (3,4,0,8)
24 11:44:48.298312 card 0: device present (720x576 25/1 interlaced)
24 11:44:48.298369 card 0: second channel (720x576 25/1 interlaced)
24 11:44:48.298406 card 1: device present (720x576 25/1 interlaced)
24 11:44:48.298453 card 1: second channel (720x576 25/1 interlaced)
24 11:44:48.298488 Primary capture PAL 16x9, YUV Planar 4:2:2
24 11:44:48.298501 Secondary capture PAL 16x9, YUV Planar 4:2:0 (MPEG sampling)
24 11:44:48.298506 Master timecode type is System using channel 0
24 11:44:48.298510 Using System to determine number of frames to recover when video re-aquired
buffer size 1073741824 (1024.000 MiB) calculated per channel ring_len 173
element_size=1505792(0x16fa00) ring_len=173 (6.92 secs) (total=260502016)
24 11:44:48.301209 chan 0: starting capture thread
24 11:44:48.301284 chan 1: starting capture thread
24 11:44:48.301340 chan 2: starting capture thread
24 11:44:48.301410 chan 3: starting capture thread
24 11:44:48.301814 chan 0: fifo init/start completed
24 11:44:48.317557 chan 1: fifo init/start completed
24 11:44:48.322820 chan 2: fifo init/start completed
24 11:44:48.326804 chan 3: fifo init/start completed
24 11:44:48.457175 chan 0: Video signal OK
24 11:44:48.478312 chan 1: Video signal OK
24 11:44:48.483051 chan 2: Video signal OK
24 11:44:48.483392 chan 3: Video signal OK
Why???
Gkrellm:
And now I have recorder with dropped frame and error!!!
It may be that you are running short of CPU power. You could try removing the 420 conversion (-s MPEG) in capture and having 2:1 as the only encode format. See if it will do 4 channels like that.
In your first output listing from dvs_sdi, I presume you started recording just before 11:44:12 when the capture backlog appeared. When you relaunched it, you couldn't have been recording, hence no backlog. If you are betting backlog in capture when not even recording then something is wrong.
Also check that some background task is not holding up the system for a short time. The beagle indexer is an example of something that can kick in and cause problems.
Are you using a player? If not accelerated by graphics card, this can use significant CPU.
hello John,
we try without MPEG conversion encoding just 2:1 the cpu work between 45/55% for 4 Channels
some frame backlog still appear
In your first output listing from dvs_sdi, I presume you started recording just before 11:44:12 when the capture backlog appeared
no we didn't start record
If you are betting backlog in capture when not even recording then something is wrong.
yes we think so
we made last test without nx server and the sistem seem work better
one question
we are using dvs sdk 3.4.0.8. with firmware 3.2.76.6_19_15
do you test it?
if not wich sdk/firmware are you use?
thanks
other question
how we can use to remote the ingex machine in graphic mode?
thanks
Do you mean run Ingexgui on a remote machine? All you have to do is make sure you give it the right CORBA reference for the name server the recorder is connecting to. If you want it to be able to play back recordings on the computer monitor, you will need to export the recorder's video disk and mount it on the remote machine with the same mount point (/<machine name>/video/). You cannot play back recordings through the recorder's DVS card this way.
Alternatively, you can run Ingexgui (or the whole of Ingex) on the recorder machine with ssh -X, or better (as it doesn't use encryption and so makes less CPU demand), using X-forwarding. You will then be able to play back through the DVS card.
I have tested with sdk 3.4.0.8 and firmware 3.2.76.6_19_15 - works fine on system here.
What is the nx server you mentioned?
Nx server is the project nx server of nomachine.
It's a remote desktop.
Hi John,
I also asked for help to the developers of the DVS.
They ask what it means to_ frame back log_?
thanks
NX is an remote desktop solution http://www.nomachine.com/
Never used it myself so I don't know if it is CPU intensive.
J.Reykdal
RUV
Frame backlog is the number of DVS input fifo buffers in use - 1. We expect one to be in use (with the next frame); more than that indicates they are not being read fast enough.
But the reading speed depends on the processor or the dvs?
Reading speed depends on processor. DVS card is putting frames in the FIFO, dvs_sdi is reading them out.
then are the 2 Xeon processor 5410 that are not strong enough to withstand the 4 channels?. Even with 3 channels because we have no problem.
As I said earlier, there is something wrong if you are getting dropped frames in capture when you aren't even recording.
You didn't say if you are using a player.
hi ,
we do not use player for this test
today we ingest 3 channel in capture coded 2:1 and 20:1 with no secondary buffer and everything goes well
no frame backlog in capture and clean recorder with no drop framen (test run for one hour)
the second test 3 channel in capture coded 2:1, 20:1, mpeg4 with mpeg secondary buffer
on capture just one frame backlog and two timestamp differ 10 ms
on recorder several frame waiting in ring buffer but no drop frames (test run for one hour)
our cpu clock speed it's 2.33 GHz . your recommended hardware required is Intel Core2 QX6700 at 2.66 GHz
do you think that here is the problem?
witch cpu do you use?
cpu speed?
thanks
vasco
Do you still get a problem doing capture only (no recorder) 4 channels?
Hi,
We did the test for 2 days with a different processor: i7-2600 3.4 GHz with 6GB ram.
No error.
Only capture a few frames backlog (1), but without recording any data loss.
It 's the frequency of the processor?
thanks
stefano
Sounds like you had already fixed the problem in your post #21
Frame backlog of 1 is expected and nothing to worry about.
Hi guys,
we use an Intel(R) Xeon(R) CPU E5645 and become frame backlogs from 1 until 8. Is this CPU too slow?