Sony-Canon-JVC-Sharp HD Format Agreement

Zac Stein · August 29th, 2003, 09:03 AM

What i meant is, the HD standard they have chosen will not be any more taxing on your storage space and throughput in comparison to our current standard.

I do conceed there will be slightly more pressure on your video card and cpu to play back the higher rez produce, but in reality any decent system up today that can already handle DV very well will handle this new standard without breaking a sweat.

You see they are just stuffing a new standard into the old standards framework. Hence it is a question of software updates rather than serious hardware change.

Current firewire speeds will be fine. Current harddrive speeds will be fine. Nearly everything will treat this new standard the same as the existing DV standard.

Zac

Ps. the 1 frame difference between 24p and 25p is a non issue it is almost impossible to spot the difference. What is noticable is that 25p handles long pans far smoother, as it's pulldown rate is even 2/2 (splits it into 2 fields) where as 24p-60i plays some funny math with 2's and 3's to fit it in and tends to jitter slightly because it's pulldown is not even, this of course only really noticable during long pans.

Don Parrish · August 29th, 2003, 09:48 AM

Thanks again Zac,

Is there any guess as to Whether todays NLE programs (Vegas 4 etc.) can be patched or will HDV need a new round of editing programs to handle them?

Don Parrish · September 6th, 2003, 08:23 AM

Unfortunately I was sent this by Sonic Foundry

"Thanks for writing. You will have to capture with a different program and then do your editing in Vegas 4.0. Vegas 4.0 can only capture from firewire and firewire doesn't capture HD".

The data rate is apparently to high, I was discussing this in the Vegas section of DVinfo. I guess it will take eide, raid, or the new firewire (2 or B) to capture it but I also think it is going to be a wait and see about a lot of issues.

Chris Hurd · September 6th, 2003, 07:34 PM

It's not data rate, Don... FireWire supports 400 megabits per second; HD is 100 megabits per second. Your standard current-generation FireWire could handle a couple of HD streams and still leave plenty of overhead. I believe it's more of a CODEC issue, or the lack of a standard one for HD over FireWire, perhaps.

Don Parrish · September 7th, 2003, 08:59 AM

I wish you folks could saw my skull open and dump the info in, it's the only way I am going to learn fast enough.

Chris, how does the codec effect transfer protocol, I would think that 1's and 0's are are transfered and the source and destination would be the only ones that cared about content.

Thanks for the help.

Jon Yurek · September 7th, 2003, 04:36 PM

<<how does the codec effect transfer protocol, I would think that 1's and 0's are are transfered and the source and destination would be the only ones that cared about content.>>

Well, yes. The problem is that it's not quite as easy as that. I don't know exactly how DV is compressed exactly, but I've never seen DV footage that's been anything other than 720x480, which says to me that it can't be anything else and that the codec is optimized for this. HD would require a higher resolution and more compression (since it's more data in the same data size, according to previous posts).

This is fine and all, but doesn't answer your question. As for capturing data, DV on a tape is just a steam of DV data. In order for the capturing program to read it, it would need to know how to decode it to display it, and, at the *very* least, get the timecode to know where to begin and end. I mean, sure, you could theoretically dump an entire tape onto disk and then deal with it with something that could handle HD (actually, IIRC, someone made a backup solution that used DV tapes as opposed to the rather expensive regular backup tapes... so it's not impossible to deal with data that way), but when was the last time you did that? You need to see the video and hear the audio while you're capturing and get only what you want.

Don Parrish · September 7th, 2003, 08:05 PM

But all of this hasn't been written in stone yet, if firewire is fast enough, and new programs must be written to edit and burn HD, then why not write them using firewire protocol? High def camcordrs are new, The programs are just starting to trickle out. Why would a manufacturer work around one of the most user friendly, widly used transfer protocols that they are already licensed for? I guess thats where I am lost. Digital data is in binary, octal, hexidecimal, and some wierd grey codes made up in many different lengths. I guess that's my question, what does firewire care if it's carrying Hd, Sd, or pictures of hooters girls (wee hah). There are firewire hard drives, still cameras, video cameras, human interface devices, DVD burners, CD burners, all kinds of equipment that use firewire.

Jeff Donald · September 7th, 2003, 08:30 PM

FireWire is just the pipe that carries the data. FireWire is not a format. As long as the data fits within FireWire specs. it can do the job.

Jon Yurek · September 7th, 2003, 10:45 PM

Exactly. The only limitation Firewire would have is the speed at which it can deliver the bits. If DV is 25Mbps, then Firewire will have no problem for a long time to come since it can deliver (even in its slow form) 400Mbps.

I think you may be confused by what Sonic Foundry told you. They probably meant to say "We don't support HD over Firewire" and not that "You can't do it" since, as you said, it's just 1s and 0s - there's absolutely no reason to not be able to do it. As Jeff said, it's just a pipe. The thing is that they need to be able to understand what's coming down the pipe.

Don Parrish · September 8th, 2003, 07:04 AM

So which of the following is correct.

A. future software may in fact use firewire to transfer high definition video.

B. The format of firewire is incompatible with high definition video.

Jeff, you are the Mac man, how does the new FCP transfer HD?

sorry for the Bother folks, I am just trying to get a grasp on a few things that are important to me, I was always the kid that had to know HOW things functioned to understand it. So please forgive me for dragging this out.

Don

Chris Hurd · September 8th, 2003, 07:05 AM

Don, I'd say most definitely that your option "A" is the correct one.

Jon Yurek · September 8th, 2003, 04:49 PM

<<So which of the following is correct.

A. future software may in fact use firewire to transfer high definition video.

B. The format of firewire is incompatible with high definition video.>>

A is correct. B doesn't make a lot of sense since there is no real "format" to Firewire... none that would make a difference to the video, anyway.

Think of it this way: You have a cable connection from your cable company. A station can send normal TV signals over cable, and they can also send HD signal over the same cable, right? The cable isn't the problem if your TV can't display the HD signal, it's the TV's problem. It's the same thing with DV and HD over Firewire. They can both be transferred without a problem, but your NLE has to know what to do with it - it's not Firewire's fault if the NLE doesn't.

Chris Hurd · September 8th, 2003, 05:06 PM

Don

Quote:

forgive me for dragging this out

This message board was created for the purpose of dragging thiings out!

;-)

Jeff Donald · September 8th, 2003, 06:10 PM

Quote:

Jeff, you are the Mac man, how does the new FCP transfer HD?

HD can be over FireWire or some other method such as SDI (Serial Digital Interface, another pipeline like FireWire). If you were using SDI, you'd need a PCI HD capture card like Pinnacle's CineWave HD, with an SDI interface.

Francesco Marano · September 15th, 2003, 08:41 AM

anyone know if panasonic is in the group,
or have another format (50 mb hd???)

ciao
Francesco

September 6th, 2003, 07:34 PM	#19
Chris Hurd Obstreperous Rex Join Date: Jan 2001 Location: San Marcos, TX Posts: 27,366 Images: 513	It's not data rate, Don... FireWire supports 400 megabits per second; HD is 100 megabits per second. Your standard current-generation FireWire could handle a couple of HD streams and still leave plenty of overhead. I believe it's more of a CODEC issue, or the lack of a standard one for HD over FireWire, perhaps. __________________ CH Search DV Info Net \| 20 years of DVi \| ...Tuesday is Soylent Green Day!

September 7th, 2003, 08:30 PM	#23
Jeff Donald Warden Join Date: Mar 2002 Location: Clearwater, FL Posts: 8,287	FireWire is just the pipe that carries the data. FireWire is not a format. As long as the data fits within FireWire specs. it can do the job. __________________ Jeff Donald Carpe Diem Search DVinfo.net for quick answers \| Where to Buy? From the best in the business: DVinfo.net sponsors

September 8th, 2003, 07:05 AM	#26
Chris Hurd Obstreperous Rex Join Date: Jan 2001 Location: San Marcos, TX Posts: 27,366 Images: 513	Don, I'd say most definitely that your option "A" is the correct one. __________________ CH Search DV Info Net \| 20 years of DVi \| ...Tuesday is Soylent Green Day!

September 15th, 2003, 08:41 AM	#30
Francesco Marano Contributor Join Date: Sep 2001 Location: Italy Milan Posts: 59	Panasonic??? anyone know if panasonic is in the group, or have another format (50 mb hd???) ciao Francesco

August 29th, 2003, 09:03 AM	#16
Zac Stein Major Player Join Date: Aug 2002 Location: Melbourne, Australia Posts: 730	What i meant is, the HD standard they have chosen will not be any more taxing on your storage space and throughput in comparison to our current standard. I do conceed there will be slightly more pressure on your video card and cpu to play back the higher rez produce, but in reality any decent system up today that can already handle DV very well will handle this new standard without breaking a sweat. You see they are just stuffing a new standard into the old standards framework. Hence it is a question of software updates rather than serious hardware change. Current firewire speeds will be fine. Current harddrive speeds will be fine. Nearly everything will treat this new standard the same as the existing DV standard. Zac Ps. the 1 frame difference between 24p and 25p is a non issue it is almost impossible to spot the difference. What is noticable is that 25p handles long pans far smoother, as it's pulldown rate is even 2/2 (splits it into 2 fields) where as 24p-60i plays some funny math with 2's and 3's to fit it in and tends to jitter slightly because it's pulldown is not even, this of course only really noticable during long pans.

August 29th, 2003, 09:48 AM	#17
Don Parrish Major Player Join Date: Dec 2001 Location: Tavares Fla Posts: 541	Thanks again Zac, Is there any guess as to Whether todays NLE programs (Vegas 4 etc.) can be patched or will HDV need a new round of editing programs to handle them?

September 6th, 2003, 08:23 AM	#18
Don Parrish Major Player Join Date: Dec 2001 Location: Tavares Fla Posts: 541	Unfortunately I was sent this by Sonic Foundry "Thanks for writing. You will have to capture with a different program and then do your editing in Vegas 4.0. Vegas 4.0 can only capture from firewire and firewire doesn't capture HD". The data rate is apparently to high, I was discussing this in the Vegas section of DVinfo. I guess it will take eide, raid, or the new firewire (2 or B) to capture it but I also think it is going to be a wait and see about a lot of issues.

September 7th, 2003, 08:59 AM	#20
Don Parrish Major Player Join Date: Dec 2001 Location: Tavares Fla Posts: 541	I wish you folks could saw my skull open and dump the info in, it's the only way I am going to learn fast enough. Chris, how does the codec effect transfer protocol, I would think that 1's and 0's are are transfered and the source and destination would be the only ones that cared about content. Thanks for the help.

September 7th, 2003, 04:36 PM	#21
Jon Yurek Regular Crew Join Date: Sep 2003 Location: Worcester, MA Posts: 64	<<how does the codec effect transfer protocol, I would think that 1's and 0's are are transfered and the source and destination would be the only ones that cared about content.>> Well, yes. The problem is that it's not quite as easy as that. I don't know exactly how DV is compressed exactly, but I've never seen DV footage that's been anything other than 720x480, which says to me that it can't be anything else and that the codec is optimized for this. HD would require a higher resolution and more compression (since it's more data in the same data size, according to previous posts). This is fine and all, but doesn't answer your question. As for capturing data, DV on a tape is just a steam of DV data. In order for the capturing program to read it, it would need to know how to decode it to display it, and, at the very least, get the timecode to know where to begin and end. I mean, sure, you could theoretically dump an entire tape onto disk and then deal with it with something that could handle HD (actually, IIRC, someone made a backup solution that used DV tapes as opposed to the rather expensive regular backup tapes... so it's not impossible to deal with data that way), but when was the last time you did that? You need to see the video and hear the audio while you're capturing and get only what you want.

September 7th, 2003, 08:05 PM	#22
Don Parrish Major Player Join Date: Dec 2001 Location: Tavares Fla Posts: 541	But all of this hasn't been written in stone yet, if firewire is fast enough, and new programs must be written to edit and burn HD, then why not write them using firewire protocol? High def camcordrs are new, The programs are just starting to trickle out. Why would a manufacturer work around one of the most user friendly, widly used transfer protocols that they are already licensed for? I guess thats where I am lost. Digital data is in binary, octal, hexidecimal, and some wierd grey codes made up in many different lengths. I guess that's my question, what does firewire care if it's carrying Hd, Sd, or pictures of hooters girls (wee hah). There are firewire hard drives, still cameras, video cameras, human interface devices, DVD burners, CD burners, all kinds of equipment that use firewire.

September 7th, 2003, 10:45 PM	#24
Jon Yurek Regular Crew Join Date: Sep 2003 Location: Worcester, MA Posts: 64	Exactly. The only limitation Firewire would have is the speed at which it can deliver the bits. If DV is 25Mbps, then Firewire will have no problem for a long time to come since it can deliver (even in its slow form) 400Mbps. I think you may be confused by what Sonic Foundry told you. They probably meant to say "We don't support HD over Firewire" and not that "You can't do it" since, as you said, it's just 1s and 0s - there's absolutely no reason to not be able to do it. As Jeff said, it's just a pipe. The thing is that they need to be able to understand what's coming down the pipe.

September 8th, 2003, 07:04 AM	#25
Don Parrish Major Player Join Date: Dec 2001 Location: Tavares Fla Posts: 541	So which of the following is correct. A. future software may in fact use firewire to transfer high definition video. B. The format of firewire is incompatible with high definition video. Jeff, you are the Mac man, how does the new FCP transfer HD? sorry for the Bother folks, I am just trying to get a grasp on a few things that are important to me, I was always the kid that had to know HOW things functioned to understand it. So please forgive me for dragging this out. Don

September 8th, 2003, 04:49 PM	#27
Jon Yurek Regular Crew Join Date: Sep 2003 Location: Worcester, MA Posts: 64	<<So which of the following is correct. A. future software may in fact use firewire to transfer high definition video. B. The format of firewire is incompatible with high definition video.>> A is correct. B doesn't make a lot of sense since there is no real "format" to Firewire... none that would make a difference to the video, anyway. Think of it this way: You have a cable connection from your cable company. A station can send normal TV signals over cable, and they can also send HD signal over the same cable, right? The cable isn't the problem if your TV can't display the HD signal, it's the TV's problem. It's the same thing with DV and HD over Firewire. They can both be transferred without a problem, but your NLE has to know what to do with it - it's not Firewire's fault if the NLE doesn't.