Let try to get Panasonic to implement this in firmware

Found the spot to download Panasonic source code.

Keep checking this page for updates:

https://eww.pavc.panasonic.co.jp/pro-av/support/mvp_e/user/gpl/category_e.htm

Its a subframe page from this link:

https://eww.pavc.panasonic.co.jp/pro-av/support/mvp_e/user/index_eu.htm

(Source Code D/L link is to the left)

The 'P2 Video Product' page is under construction however the other link has all RPMs TARs for another product.

They'll have to put up the others eventually. Haven't found any info on how firmware is to be updated. We'll probably have to wait until there is an actual update from Panasonic.

BTW - found these pages from https://eww.pavc.panasonic.co.jp/pro-av/
 
Last edited:
..just using a peice of software with DVCPRO HD support and capturing over firewire is already available. otherwise the P2 cards and firestore ect. let you go unleashed. im not sure why we need anything else really.
 
ullanta said:
and I'm sure you know that ethernet does not provide any bandwith guarantees, which would indeed make this very dangerous...
Click to expand...
When there's only one camera and one computer in the ends of one cable, what kind of QoS you would need? What's inside the cable eating your bandwidth?
ullanta said:
Anyway, I've haerd plenty of "rumor-like" mention of the HVX running Linux, but nothing official or with any meaningful detail. Can someone point me to anything beyond rumor?
Click to expand...
http://forums.creativecow.net/cgi-bin/new_read_post.cgi?forumid=193&postid=855891
 
ullanta said:
Anyway, I've haerd plenty of "rumor-like" mention of the HVX running Linux, but nothing official or with any meaningful detail. Can someone point me to anything beyond rumor? Knowing how things get distorted, "Linux" may mean any of the Unices, or even something like VxWorks, QNX, or OS-9.
Click to expand...
I was told by one of the Panasonic engineers at DV Expo that yes there is an imbedded Linux OS in there. The manual also makes mention that portions of the OS are under GNU. The relevant quotes (and pointer to the source code) are on page 4 of the HVX manual.
 
NFS can provide 10gigE bandwidth, it just a question of the system, so yes it garantees...
Click to expand...


Hmmm... I haven't had time yet to look up the Linux links... but you guys should have a look at the meaning of "guaranteed". You can tell me you usually run at 2 Gbps, but that doesn't provide a "guarantee" of even 1 bps. In a realtime system, the concept of "guarantee" vs. "always seems to" is essential.

Not saying it wouldn't work, just being precise here. In robotics (and especially space robotics) we're quite often eager to trade 3-4 magnitudes of performance for a guarantee. If the HVX had two processors, and we could run one strict realtime and let the other deal with ethernet servers, there are ways to make that reliable. We'd want that for almost any kind of IP-based interaction.

The problem is also occuring with firewire... sending DVCPRO HD stream to the Firewire port is no problems, but having the camera control the actual writing to the HD isa lot more processor intensive and can create problems and lockup for the camera OS.
Click to expand...
Exactly - the camera doesn't stream live to any HDDs, whether over Firewire, USB, or NFS. The issues are the same.

For the Ethernet Solution, you can either use NFS with UDP, or doing broadcast, so even if remote end freeze or whatever, the camera is not affected.
Click to expand...
Well - if you define "not being able to record footage" as "unaffected"...

----

Anyway, Toke, haven't you heard of cable mites?
 
Last edited:
They are not, processing a FAT table is alot more complicated than just streaming a file.

Also when writing to the P2 card, it is not real time, there is always a delay before it is written. GigE does have a delay, but so does the P2, or firewire... It just SO SMALL you dont see it. Ethernet will provide better response time than your firewire port.

Look go read book about computers network, and you will see there is multiple solutions of dealing with this. The idea is you have options.
 
mochouinard said:
Also when writing to the P2 card, it is not real time, there is always a delay before it is written. GigE does have a delay, but so does the P2, or firewire... It just SO SMALL you dont see it. Ethernet will provide better response time than your firewire port.
Click to expand...

I'm not talking about a delay, I'm talking about a GUARANTEE. You look it up in your network book while I go read mine.

Anyway, providing reliable service over unreliable UDP (let's not even talk about broadcast (and lets certainly not bring wireless into it)) is arguably at least as complicated as processing an allocation table....
 
Last edited:
ullanta said:
I'm not talking about a delay, I'm talking about a GUARANTEE.
Click to expand...
I'd still like to know where do you need a guarantee?
If the network consist of one camera and one computer?
Guarantee for cable break?
 
Industrial video camera manufacturers are quiting an extremely fast standard (CameraLink) and produce GigE cameras now. Firewire and USB2 interfaces are for low end models now.
 
Exactly toke lahti, cable break... sure..., cable catch fire... sure... but firewire cable is even more sensible.

We run over 400mbits/sec(Slowest speed at night) 24/7 for over 200 days without any problem ON THE INTERNET... Im trying to find where is your issue with network ?
 
Hey, the 2-node solution (2 computers, 1 process on each, 1 cable) is indeed extremely likely to work reliably. I'm not sure that there's a single-process version of NFS, but heck, we can develop that, too. And as long as we have strict real-time control over all the server functions, control functions for the camera, and parameter settings, and for all non-image feedback from the camera, then maybe we won't have any chance of something outside the image data stream momentarily filling a buffer, causing an unexpected delay, leading to a dropped UDP packet and retransmission (e.g., the gateway to bandwidth fluctuation). So anyone comfortable with having server functions in their image-processing control loops should go ahead and try it out! Probably can be done (for 2 nodes), certainly can't be proven or guaranteed, and certainly wouldn't be easy to do a decent job.

But add more nodes or processes, and the potential for losing frames increases tremendously.

Anyway, industrial camera APPLICATIONS in most situations are not as glitch sensitive as you're likely to be about your video. Most industrial applications are either driven by the incoming frame or at least tolerant of a lost frame...
 
Last edited:
NFS is good for unicast application. With a special capture application, it could be broadcast to the network, so any computers connected to the switchs will get the stream intact.
 
Industrial cameras are very simple systems and very absolute in their timing. It's up to the pc side software/hardware to handle the data properly. On modern pcs and rates up to 100mb/sec and proper software, the only parameters are quality of controller and hard disk capability. If you record to RAM you can do HD resolutions and any frame rate on normal PCs. GigE is not the limiting factor.
 
You must log in or register to reply here.
Back
Top