Panasonic P2

[Guest Daniel J. Ashley-Smith]

When I import my DV footage from my camera to Vegas, you know what I get? Unreadable Jibber in the file name. I have to personally open the file, view it and then re-name it so that I even know what it is. What makes P2 so different in that front?

That's purely something to do with Vegas. P2 holds files, DV holds video. It's not like you're uploading filenames with DV. With Premiere the default filename would be "projecttitle01.avi".

[Tim Tyler]

And second, Phil. Take a chill pill again

Please stop telling Phil to 'take a chill pill'. Jan is entirely capable of defending herself if she feels the need.

[Brian Wells]

I just think that the software side of it seems like it was implemented by the Ronald McDonald Department of Fashionability.

 

I find all of this very troubling, but isn't this an Avid problem?

 

The brand-specific MXF wrapper that requires proprietary software to unwrap it is also troubling.

This will surely not go over well with the commonwealth of Massuchusetts! http://slashdot.org/article.pl?sid=05/09/24/1317234&from=rss

[Phil Rhodes]

Hi,

 

To some extent it is an NLE problem, yes. The Avid could have loaded the XML and named the clip based on something useful in there. Again, though, and I don't wish to be repetitive here, I simply don't see the advantage. Why not just name the files after scene and take? That's how all the compactflash audio gear works, and it works spectacularly well.

 

And to clarify, the MXF implementation is not outside the standard, it's just that the standard has so many options and flexibilities that it's very hard to handle reliably. The vendors do love to shout about how it'll make everything accessible to anyone, but it doesn't quite work like that. It's so wide, so flexible, and with so many subformats and options that in the end you're just hiding incompatibility by putting it in a big box marked "MXF" and pretending that solves the problem.

 

To wit: both XDCAM and P2 can record 25-megabit DV in a way that most 25-megabit software DV codecs will decode. They'll record it to an MXF file. Both XDCAM and P2 will also record the "atom" operational pattern, which separates "essences" (video and audio tracks, among other things) into separate files. So, it's MXF, it's the same OP, it's a compatible codec. But will the same software handle it, even after we've satisfied three requirements that are quite opaque to the average user? No, because one is frame wrapped and the other is clip wrapped. What does this mean? Who does this help? God knows, but I can only suggest the slogan "MXF: great for software engineers, disastrous for editors."

 

So, it's Panasonic's choice to organise things in a certain way and that does make it irksomely specific to P2 while not being outside the wide MXF spec. This flexibility might be seen as a flaw in MXF as much as it is a flaw in P2, which is why I question the use of MXF in this application (actually I question the use of MXF in more or less any application, but whatever). The result of course that this specificity limits compatibility, in direct contraditction to the stated aims of MXF. Not only do you have to write an MXF import module, you have to write a P2 MXF import module, and an XDCAM MXF import module, and an Avid MXF import module.... it ain't quite Quicktime movies anymore, if you see what I mean.

 

It's actually quite easy to confuse the Newscutter into producing an XDCAM-specific error message by giving it P2 files. I'll mount a screengrab if anyone wants to see it, it's quite amusing. It's confusing enough that even Avid can't sort it out reliably.

 

Phil

[Josh Bass]

"When I import my DV footage from my camera to Vegas, you know what I get? Unreadable Jibber in the file name. I have to personally open the file, view it and then re-name it so that I even know what it is. What makes P2 so different in that front?"

 

 

Dude. . .you're using Vegas wrongly. I have it, and you can call each clip you capture anything you want before you even digitize it. It doesn't default to gibberish either, it'll default to whatever the name you gave the tape (e.g. "My Cool Movie") followed by a clip number (e.g. 001). So even if you never changed the filenames, they are far from illogical, and would look something like this---"My Cool Movie--Clip 001.avi, "My Cool Movie--clip 002.avi", etc.

[Stephen Williams]

Personally, I'm gonna without comment until I actually use the P2 cards, and understand how hard or easy they are to use.

 

Landon

 

Hopefully that will apply to more than just P2 cards in the future!

 

Stephen

[Jan Crittenden]

Phil Rhodes asked:

No, I'm asking what the benefit is to all this stuff that I should suffer my choice of software being so severely curtailed. I mean, sure, support will come, but what's the point? Why not just use a standard format that everyone can already read?

 

Here is a statement from Avid about the format that we use:

 

While many rules apply to all Operational Patterns, the building blocks may be

assembled somewhat differently.

 

For example, OP-1A files may include multiple tracks of audio and video essence that are

interleaved into a single file. This approach makes the files nicely self-contained and can work

well in applications where each file represents a complete program or take. But OP-1A may be

less applicable to content authoring steps such as nonlinear editing, where programs are

created by surgically slicing and layering different sections of source material.

 

Not surprisingly, Avid products will natively support OP-Atom (SMPTE 290M) the operational

pattern that was designed to specifically address the needs of nonlinear video and audio

editing. Benefits of OP-Atom include the separation of essence into multiple files while retaining

common clip metadata across related files.

 

This is from their white paper on MXF. It is fairly short and easy to read, you can find it here: http://www.avid.com/resources/whitepapers/...=885&marketID=1

 

>OK, now you're being asked by me to please not because I don't believe that the complexity overhead is worth it. As I say, I am willing to be persuaded. What DOES it gain me?

 

P2 MXF support has been implemented by Avid (across NewsCutter, Media Composer, Unity with HD support coming in DS), Pinnacle (the Liquid Broadcast / Chrome family, done prior to the Avid acquisition), Quantel, Thomson/Grass Valley, as well as Canopus, EVS, Dayang. We expect Leitch Nexio NLE support (for O.P. Atom) in a month or so, and Velocity already does support P2. Microsoft recognized the pervasive position of DVCPRO and added IEEE 1394 support for 50 and 100 Mb/s for DVCPRO in Windows XP Service Pack 2, and they selected P2 for their Connected Services Framework for P2's IT-centric "instant access." TeleStream has P2 support in FlipFactory 4, and it can serve as an ingest for Avid servers. Dalet and Omneon are P2 cognizant, to the degree their customers have asked for support, as is SGI. Focus Enhancements well aware of MXF, and is working with us to have an FS-100 for the HVX200, and created P2 DV file conversion software for us (more below).

 

The decision to use MXF (SMPTE 377) was largely driven by two things: our participation in SMPTE and MXF and AAF; and Avid and Quantel. Avid told us they were going to shift from OMF to MXF, and they asked that we follow O.P. Atom (SMPTE 390) so the content would not need to be parsed at ingest as it must be for O.P 1A (SMPTE 378). Even Grass Valley, who have their own "earlier" version of MXF (GXF, I believe - SMPTE 360) can mount and or ingest P2 MXF. The independent existence of all the audio and video essence allows the NLE application operate even without ingest, i.e. for many systems like Avid's or GVG's the device can simply mount, or content can be ingested, usually faster than real time, at the users option.

 

>No, it doesn't. Most significantly, the SPX-800 doesn't save scene and take information, and doesn't offer any way to set or increment those fields even if it did.

 

I said it was in the P2 viewer, the P2 viewer allows for clip infomation to be edited. The P2 viewer does indeed allow for this. The clip names on the file is a random number. If you are working in a very large station and you are ingesting clips from 10 camcorders into the servier, you cannot have Clip one, Clip two, Clip three because you would have 10 of each of these everyday. It has to be more random than that and thus the random number that you are complaining about. You can then rename the user clip name to what ever you want. The random number stays until you rename it say in the application or in Windows Explorer. But you can resort all of your clips by the user clip name.

 

>And then it worked with every piece of software that wants to print. P2 works with those applications that Panasonic have chosen to favour. Bad idea.

 

Here is where your slant on this is just simply incorrect. If you undstand the nature of the MXF, and the little booklet above may help, you would know that it is towards standards that all files can be interchanged. The further from the standard the more difficult. And BTW, we don't chose who we will work with, folks come to us to make sure that we work with them.

 

>Enhance the metadata. Is it me, or is that right off the sales briefing for the thing? What d'you mean, enhance the metadata?

 

Well you could add key words for searching in the archives later, you could put in more pertinent things like the correct spelling of the interviewee's name, or if nothing else you could put in the DP's name under the shooter. The clip owns the serial number of the P2 card that recorded it and there is a long list of data that can be assembled about any of the clips. This is all for the benefit of the archive.

 

>No, that's exactly the problem, you can't just view the files. If it was raw DIF you could do that.

 

Funny enough, I clicked on the MXF video file and it came up and said what do I read this with and I chose Windows Media Player. However it only played the video. Oviously, the more powerful application to work with the clips is the P2 Viewer.

 

>If it was an AVI or a quicktime movie you could just do that. But it isn't. It's six files in a strange, largely unsupported format, even unsupported by software that claims to support it. OK, I could be wrong. Please, tell me what this gains anyone.

 

Well, all I can say is that the broadcasters that have the Newscutter here seem to be working with it just fine and from what I have seen on the Newscutter demos, it seems to work just fine. Not sure why you were having a problem.

 

>> I mean in order for me to view HDV files I have to download a very special piece of software that I don't

>> use for anything else.

 

>Yes! And this is... a bad thing! I think we're getting through here.

 

See I don't see it as a bad thing, and perhaps this is just where we get to stay on the other side of the fence from each other. If a small piece of software allows me to work with a file format that up until I download it, and unlike the VLC stuff, actually allows me some real opportunity to working with the clip, I don't see the problem. I think this is cool and most of the customers I have demoed this too also feel that is it s cool.

 

>No, obviously Marc let me take it out for review without doing that. Obviously.

 

This is too bad, as it is not inherently obvious to step into a non-tape environment and know exactly what to do. I mean if you are into IT, it might be intuitive, but if you are coming from a tape-based background I don't think it is.

 

>I understand what it is and how it is intended to work. I think it's a superb idea and very forward-looking; I think it's probably the best thing since sliced bread if you're Bloomberg or CNN.

 

Actually it is smaller news organizations like New York 1, or local affiliates, as at a network level, it is harder to change that to an tapeless society when so much of the infrastructure is wrapped around tape or tape based archive.

 

>I wouldn't be objecting this much if Panasonic were more willing to say "Sure, it's intended for big ENG organisations with huge offline storage who are willing to buy very specific software". It's no surprise that it's being supported (however badly) by news edit software first. Fine. Great. But you have to be willing to accept the limitations of the thing. It is not panacea, much as I appreciate that in the gumdrop-tree world of technology sales you have to believe it is.

 

Well Phil, you will never hear this from my lips as I think just the opposite is true. The smaller, more controllable the environment for production, the easier it is to work with the P2. Frankly as it stands right now, I saw on the IBC floor three demonstrations, one at Avid in Xpress Pro HD, at Apple in FCP 5.0 and at Canopus in Edius HD, P2 footage, shot on the HVX200, imported into their systems and editing. So much for your point about lack of support. Frankly I believe whole heartedly that this is the coolest thing to happen to video since 24P.

 

>I wouldn't be objecting this much if there was any good technical reason why it was a good idea to do it this way. Look, I'll forgive you any inconvenience so long as you can say why it's a good idea. So please. What exactly does this get me, or anyone, over a much more straightforward RIFF extension?

 

>> Please take a look at the Standards for OP-Atom and that is exactly what we followed.

>Yes, I know. So? That's not the problem. The problem is that there are so many subformats of MXF that you end up coding each implementation separately even if everyone does follow the rules. I understand the drive for convergence in file formats, but really MXF to me has always looked like nothing more than "call everything the same name so it looks pretty to the user, and sort it out behind the scenes." If I want to view a JPEG images, it's called JPG, and any JPEG reader can parse it. If I want to view an MXF, I first have to know if it's a Sony MXF, or a Panasonic MXF, or...

When I first heard that P2 was going to record MXF, I must admit that my head hit the desk in a rather paradise-lost moment of techno-disappointment. The problems with MXF aren't Panasonic's fault, but the decision to use it is.

 

Here I fail to understand what you mean. I see MXF standards and the one we implemented as appropriate and working. So are you saying the following a SMPTE standard is not a good practice? How can that be? Since we do work with a good number on the SD domain and a growing number on the HD domain, it seems perhaps that following a standard is a good idea. The OP Atom is operationally robust.

 

>> These clips are not separate,

>> It does not look that way to the NLE.

 

>Hang on, I thought the whole point here was for the audio and video to be separate for the NLE?

 

It is but it is primarily wrapped around the fact that many of the systems that work with the P2 can edit directly from the card. If I grab a clip and place it on the timeline, the NLe pulls its repective audio with it. They are not having to do two operations here, it is one.

 

>> The MXF wrapper holds the clips together, they are not separated uless you separate them.

 

>No, the MXF wrapper is designed to do that, it just doesn't in your implementation. For some reason. Again raising the question of why use it.

 

Again, I cannot explain your experience, but it seems to work exactly so when I see the demo.

 

> Phil, the system is quite competant and very powerful,

 

>You're not even bothering to respond to my queries anymore, are you?

 

The query you had that got this response had nothing to it, you said it was not a competant system, and I said it was. For the rest of your concerns I have tried to answer them, point by point.

 

Come on. What does 0255F mean? Why is it important for it to be 0255F and not 01143503, which would be just as unique within a timecode range and human-readable to boot?

 

As mentioned above, the random number generator idea is so that if you choose not to rename your clips, you don't have to and you can put all of the footgae in the server from any given day and it will accept them all. It may mean to the small producer that as you bring the clips in that you rename them, to me this makes sense as how would anything generated by a device have the ability to know what to really call my clip. This may be a fence issue and I will be on this side always and you on that side, but frankly I think as a person sitting down to edit footage is more likely to have viable names beyond clip 1, clip 2, and these would be vastly more useful.

 

>Why, in God's good name, should I have to rename the clips myself because you chose to put gibberish there? Seriously, why? And don't blow me off with "I'm a salesperson not an engineer", get on the phone to Osaka and find out.

 

First I am not a salesperson. I am a Product Manager. Didn't need to go to Osaka, we have some pretty strong engineering types right here and the random number generator part of the clip naming is in that same SMPTE standard noted above.

 

> so far most of the folks we have working with it, look at the thumbnails and the Marker info.

 

>That's because most of the folks you have working with it are CNN or Bloomberg-like organisations and are using it for ENG. You just released, in a very big noise, a camera clearly designed for filmmaking. Are you referring to those people?

 

Actually I the folks that I have shown this camera to are the small filmmakers and this is the camera that I am the Product Manager for and yes, I do see that these folks will have a very easy time of working with this camera and its files be it on the Apple FCP platform, the Avid platorm or the Canopus. And probably by March for full implementation the Matrox Axio.

 

>How're they lining up dual system sound?

 

Well on the HVX200, it will jam time-code over 1394, so if the audio recorder outputs a TC on a 1394 link, the HVX can hear it and jam to it. If not I would suggest that a clapboard be used. Or they could both set to real time.

 

>How're they ratifying it against timecode-logged production notes?

 

By looking at time code sorts that can be done in the P2 viewer. or on the time line.

 

>> If you keep the MXF wrapper intact, then you are managing one file and it has component parts within it.

 

>No, it absolutely does not. Look, have you actually done this, or are you relying on Panasonic's internal briefing on the thing? Each MXF file has exactly one component in it. Audio, video, comments, metadata, proxies, etc.

 

Actually we have been doing this, I was looking over an engineers shoulder last night as we played with both the Newscutter and the Canopus. Don't have the Apple with me as I am in Chicago at ResFest. It worked appropriately last night.

 

>To view a virtual card in the P2 viewer on an Avid Newscutter, you have to have the files in one place. To actually import them onto the timeline they have to be in another. And thank God it only actually needs two, not all five. The only way to import P2 material into an Avid Newscutter - that I could find, please correct me - is to manually go into the data on the card and pull out individual files. No help from the magic "MXF wrapper".

 

Let me come back to you on this as I will give you the set of commands, I forgot to write this down last night. I will write it down and post back tomorrow probably as this event goes until 10:00 tonight.

 

>And of course, if you are using any of the myriad applications that doesn't support MXF, or rather Panasonic's very specific implementation of MXF, the import procedure is to unwrap from MXF, rewrap it to a more sensible format and mux in the audio. Which takes hours and no small amount of computer ability.

 

Take a look at the list above, it is not a small list, it is a very large list and it is growing in support. Microsoft told us that the reason that they chose P2 over other non-tape based products was because P2 is IT from the moment that you press the record button. It is not a small select couple of systems that we chose to support, this is broad based support over many platforms.

 

>Look, I like the system, I think it has great potential, I just think that the software side of it seems like it was implemented by the Ronald McDonald Department of Fashionability.

 

Then the Society of Motion Picture and Television Engineers the Ronald McDonald Hall of Fame. ;-) My feeling is that somehow you ended up with a demo that didn't work and are struggling to figure out why. If all of the implementations that we have had worked as badly as you describe, I dare say that we would have over 3000 cameras deployed at this point in time. No the system works fine, your demo didn't work. I will get back to you on the import to the Newscutter keystrokes.

 

Best regards,

 

Jan

[Phil Rhodes]

Hi,

 

> Here is a statement from Avid about the format that we use:

 

I don't much care what Avid think, I don't often use their software.

 

> P2 MXF support has been implemented by Avid...and....and....

 

That doesn't answer the question "what does it gain me." If you're trying to imply that MXF gains me a lot of compatibility with big software, well, I think I've already shown that simply isn't the case. It certainly isn't as widely compatible as any of the preexisting formats.

 

So once again, what, please, is the technical advantage of MXF over an AVI or a Quicktime movie or a raw DIF? I'm not suggesting you shouldn't also provide name-linked metadata as XML, which the user can overlook if they want to. Please, invite one of your engineers to answer this question. What, as an editor, is the difference to me, other than that MXF is very difficult to handle and takes up a lot of time?

 

> The decision to use MXF (SMPTE 377) was largely driven by two things: our participation in SMPTE and MXF

> and AAF; and Avid and Quantel.

 

That sounds dangerously like you were supporting the pack, rather than basing your decisions on sound technical reasoning. It also sounds dangerously like this:

 

Avid and Quantel realised you were going to release a hot new camera system, and wanted to make sure you had to use their software to work with it.

 

> I said it was in the P2 viewer, the P2 viewer allows for clip infomation to be edited.

 

I should not have to manually input scene and take numbers. I don't have to do this in any other solid state media device. The only way to do it at the moment is to read the slate out of the frame, which is quite literally as backward and inconvenient as film. Please, if you get them to fix nothing else, get them to fix this.

 

> If you are working in a very large station and you are ingesting clips from 10 camcorders into the servier,

> you cannot have Clip one, Clip two, Clip three

 

But you can have SC001_T003_0255F.MXF if you're really convinced that we need that level of differentiation. Or more sensibly you can have it be an option. You really think the average HVX-200 user is going to have the sort of problems you're trying to avoid? Of course not, it's an independent movie camera.

 

> Funny enough, I clicked on the MXF video file and it came up and said what do I read this with and I chose

> Windows Media Player. However it only played the video.

 

DV25 or DV50?

 

Until very recently, the Microsoft directshow splitter for ivas RIFF chunks was not working for DV50. If they have fixed this - woohoo!

 

> Well, all I can say is that the broadcasters that have the Newscutter here seem to be working with it

> just fine

 

Yes, yes, you can keep telling me that you have a lot of people who like it, but that doesn't deflect the problems it has. This isn't an answer. Like I said, big news setup, complete refit for P2 workflow, fine, lovely, best thing since sliced bread. Having some people happy with it does not mean there are no problems with it.

 

 

> This is too bad, as it is not inherently obvious to step into a non-tape environment and know exactly what

> to do. I mean if you are into IT, it might be intuitive

 

How can I put this... I'm into IT. I understand what it's trying to do and believe me I understand where it's failing to make all it could of the IT integration. The reason I'm so concerned about this is that it's such a titanic unnecessarily missed opportunity.

 

> Frankly I believe whole heartedly that this is the coolest thing to happen to video since 24P.

 

I'm sorry, but you really do beg for this - of course you like it. You are being paid a lot of money and being offered a jet-set lifestyle to like it. Employ me in the same role and I'm sure I could find a lot of reasons to like it!

 

And I do like it. Honestly. I'm just hoping that you can come up with some software upgrades for the cameras to implement some of the things I've suggested. I really think I've been sufficiently specific about what it needs to do, and I suspect you could do most or all of them in software.

 

> Here I fail to understand what you mean. I see MXF standards and the one we implemented as appropriate and working.

 

That doesn't answer the question. Why is MXF more appropriate than a format that is just as capable and much more widely compatible?

 

What does MXF audio, MXF video, MXF timecode, MXF proxies and XML metadata do that you could not do with a straight DIF and XML, or ivas AVI with new RIFF chunks, exactly the same way a Broadcast Wave works so well in devices like the Fostex PD-6 and FR-2? Again, feel free to have an engineer answer these questions.

 

> So are you saying the following a SMPTE standard is not a good practice?

 

Yes, that's exactly what I'm saying.

 

> How can that be?

 

What, they're infalliable?

 

> The OP Atom is operationally robust.

 

As is raw DIF, a fact attested to by every DVCAM, DVCPRO and miniDV camera out there. And that's a few cameras.

 

> Again, I cannot explain your experience, but it seems to work exactly so when I see the demo.

 

Look, here we go. Five directories, five files. Files are not held together by the magic MXF fairies. Files are separate. It is annoying.

 

> First I am not a salesperson. I am a Product Manager.

 

Uhhuh.

 

> Well on the HVX200, it will jam time-code over 1394, so if the audio recorder outputs a TC on a 1394 link,

> the HVX can hear it and jam to it.

 

Y'see this is the thing. You've never actually done this, have you? You've never tried to line up audio and video takes. You get your soundtrack, which would be called something like Scene_01_take_01.wav, from something like a PD6. You then look for your video file for that scene and take. But it's called:

 

0255F.MXF

 

Or is that:

 

0744Q.MXF

 

Or perhaps:

 

1099E.MXF

 

You begin to see the problem? You have a directory full of this crap and you have to search individually for the one you want by opening them individually. Several hundred of them. The magic MXF fairies do not save you from this. The magic P2 viewer does not save you from this.

 

Have I now made this problem sufficiently clear? Can you please - sob, wail - please, please, pretty please make it burn the take number into the filename? If nothing else?

 

Phil

[Tim Tyler]

Hey, Phil. Pardon me if I missed the answer to this in an earlier post, but... What file naming convention are you proposing for P2?

 

It sound to me like the P2 MXF format is designed to bind descriptive data directly to the media file so that the contents of a card could be dumped directly into a database. This may not be overly advantagous to the one-camera indie filmmaker, but it will likely benefit many Panasonic customers, especially the ones who will buy and use multiple cameras.

 

Panasonic's MXF viewer allows us mortals to see through the MXF wrapper and access/modify the media and metadata within; probably a 1-click process to view. Is that right? Alternatively Panasonic could have chosen to write straight AVI/MOV files from the camera which would likely contain minimal metadata (timecode+) I wonder if the MXF file will contain FPS, iris, focus, shutter, audio, color temp, time of day, and user configuarble data bits like my Canon digital SLR does?

[Landon D. Parks]

I think the whole "People should listen to me, I'm Phil Rodes" thing is overly Hollywood and WAY over rated!

[Phil Rhodes]

Hi,

 

> Hey, Phil. Pardon me if I missed the answer to this in an earlier post, but... What file naming convention are

> you proposing for P2?

 

Well, if it is a random number, then they could put anything they like in the filename, so long as it was accompanied by the random number. Personally I don't see it as a problem as you should be setting camera or operator IDs to differentiate things, then naming against timecode, but if they absolutely want to avoid database clashes based on a hash of the camera's serial number or something, that's fine. But to make the filename that and only that is incredibly unhelpful for no good reason.

 

And in a more general sense, I'm troubled by this use of the filename field. Filenames are there to communicate information about the content of the file to the user. This application is misuse; it doesn't fulfil that purpose. If you really want a relational database, keep it inside a file.

 

> It sound to me like the P2 MXF format is designed to bind descriptive data directly to the media file so that

> the contents of a card could be dumped directly into a database.

 

Yes, but if you then list that database alphabetically based on what the material is called, which is what every NLE under the sun does by default, you get an unordered mess. The only way to order takes meaningfully outside of the P2 view is by inspection, which is insane.

 

> This may not be overly advantagous to the one-camera indie filmmaker,

 

I think that alone should be enough to at least offer an alternative given what the HVX-200 is clearly fo.

 

> Panasonic's MXF viewer allows us mortals to see through the MXF wrapper and access/modify the media

> and metadata within;

 

It's not particularly wrapped up, it's just XML and is even hand-editable. The timecode also seems to be in the MXF-wrapped video DIF, as the Newscutter sees it without the XML (which it doesn't read.)

 

> Is that right? Alternatively Panasonic could have chosen to write straight AVI/MOV files from the camera

> which would likely contain minimal metadata

 

Not so. I would have suggested they follow the very successful lead of solid-state audio recorders, which record the Broadcast Wave format. This is a perfectly legal WAV file taking that extension and containing the new "bext" (broadcast extension) "chunk". bext doesn't define very much metadata as it was designed to be minimalistic, but you can have as much arbitrary data as you like and it's still a valid WAV file. AVI files use the same RIFF, or resource interchange file format. It would be entirely code-legal for Panasonic to generate a RIFF chunk containing their metadata, even as raw XML. The critical thing is that it is still a valid AVI file; those who choose to write extensions to read the proprietary data can do so and in the meantime it works on every piece of software in the world exactly the same as it always did. If they're particularly wedded to the idea of split A/V they can still do that too and it requires zero effort to use it. Everyone's tools and workflow still operates correctly and automatically, no software changes, no big operation. They can still save the XML metadata and link it with a filename convention if they want to, and again if you don't want it ignore it an everything keeps working.

 

> I wonder if the MXF file will contain FPS, iris, focus, shutter, audio, color temp, time of day, and user

> configuarble data bits like my Canon digital SLR does?

 

The MXF doesn't contain anything (again, yet again, begging the question of why use it); the metadata is in the XML. It's pretty complete - altogether a good way to store it, it's just a shame you're forced to parse it to be able to do the slightest thing with the files.

 

To summarise, it stores the following fields in various parts of the XML; some omitted for relevancy:

 

ClipContent:

ClipName (0255F)

GlobalClipID (A long, GUID-style hash)

Duration (in frames)

EditUnit (1/25 for PAL 25p)

 

EssenceList:

Video:

VideoFormat (MXF, as if that tells us anything.)

Codec (DV25_411 in my case)

FrameRate (The SPX-800 we had set this to 50i, even though we were shooting 25p.)

StartTimecode (Self-explanatory)

EndTimecode

Pulldown (2:2 in my case)

AspectRatio (16:9)

 

 

Audio: (This section repeated twice, presumably for stereo)

AudioFormat (MXF again)

SamplingRate (48000)

BitsPerSample (16)

 

ClipMetaData:

UserClipName (another long hash)

DataSource (Set to the string SHOOTING in my case, purpose unknown)

 

Device:

Manufacturer (Who else?)

SerialNo F4TKA0014

ModelName SPX-800E

 

Shoot:

StartDate 2005-08-09-09T16:13:31+00:00

EndDate 2005-08-09-09T16:16:14+00:00

 

Thumbnail:

FrameOffset 0

ThumbnailFormat BMP

Width 80

Height 60

 

All very lovely. If you can read it.

 

Phil

[Guest Daniel J. Ashley-Smith]

I think the whole "People should listen to me, I'm Phil Rodes" thing is overly Hollywood and WAY over rated!

Where the hell did that come from?!

[Brian Wells]

The MXF doesn't contain anything. To summarise, it stores the following fields in various parts of the XML... All very lovely. If you can read it.

An honest question, how do you think this data will be recorded on a Firestore? Any idea?

[Phil Rhodes]

Hi,

 

In a piece of XML, I would imagine, exactly as it is now.

 

Phil

[Jan Crittenden]

Hi,

 

Sorry it has taken a little longer to write this and get back to you and the list. Long show hours with just enough traffic that the sentences I can write there are few.

 

>I don't much care what Avid think, I don't often use their software.

 

But the other day your complaint was all about not being able to import into Newscutter without having to bring in these audio and video files separately, which BTW, I just did the demo here at Res and it works just fine, whole files audio and video come in simultaneously, represented by a Thumbnail, drop onto the timeline and it works rather famously.

 

The whole point of the Avid quote was to orient you to why anyone would choose MXF, they just said it better than I could say it. The fact that you choose to discount standards, while that is your given right, doesn?t mean that we are going to change the way we do things, because if we were to do so, then everything else in the chain would also have to be changed. An additional reason I included the quote from Avid was because it was their system that you were working on when you were having so many problems and indeed it is from their perspective that they work with the MXF OP Atom.

 

As far as how to import the MXF into Newscutter, we just opened the application, and it automatically recognized the P2 Card. I understand on older versions the computer needed to boot with the P2 card in the slot. We selected New Project from the pop-up window and chose Private as it was not going to be on a Shared Network. We then chose Tools form the Tool Bar-clicked Media Tool, this asks for which drive, we chose the drives that has the clips, and the drive that had the project. We then clicked the Master Clips as this is the header for the MXF. (If you clicked on the Media choice, this would have led you to the small individual audio and video files.) This then made the bin appear with Picons/Thumbnails. We chose the clips and put them on the timeline, video with audio. Since it showed them as Thumbnails we could tell which was which. Now the bin has four different views, I noticed. The Brief view showed the title of the clip that you hate, but along with it, it showed the time code, duration and that is had Video and Audio. The Text view had all of that plus which codec and the create date, with time. The next was Frame and this showed the just the Thumbnail and title. In the Script window, not only did the thumbnail show, but the description of the clip could be typed in here, which, would be the view I personally would use as here I would be able to say which take it was, and something about the content.

 

>That doesn't answer the question "what does it gain me." If you're trying to imply that MXF gains me a lot of compatibility with big software, well, I think I've already shown that simply isn't the case. It certainly isn't as widely compatible as any of the preexisting formats.

 

Actually you haven?t shown that it doesn?t work with a lot, your only example was the Avid Newscutter and hey, this one worked just fine. And on top of that and in spite of the fact that you don?t acknowledge it, the list for manufacturers that support and can work with the MXF is very strong. Apple, Avid, Pinnacle, Canopus, Microsoft, Telestream, Quantel, Grass Valley, Focus Enhancements, Quantum, InPhase Technologies, and a growing number of others. I will grant that Apple strips it back and works with the XML, but it but having there does not keep it from working with Apple. The point that the list that I posted in my previous post should have told you is that there is wide acceptability of the file structure.

 

>So once again, what, please, is the technical advantage of MXF over an AVI or a Quicktime movie or a raw DIF? I'm not suggesting you shouldn't also provide name-linked metadata as XML, which the user can overlook if they want to. Please, invite one of your engineers to answer this question. What, as an editor, is the difference to me, other than that MXF is very difficult to handle and takes up a lot of time?

 

Again Phil, if you read the SMPTE standards or if you had read what I posted before, it allows for the ability to multi-share and start editing right off of the card itself, right down to doing split edits. A Dif doesn?t have MetaData, nor does AVI, and which flavor of AVI is that? In the P2 domain if you roll from one card to the next in the middle of a take, that metadata is pretty important as the span-clip info needs to be there. What in an AVI would know that the file was continued on the next card. Only a file format that can have pointers to the other half from each part that points back to the other is appropriate. None of these simpler file formats can do this.

 

>That sounds dangerously like you were supporting the pack, rather than basing your decisions on sound technical reasoning. It also sounds dangerously like this:

>Avid and Quantel realised you were going to release a hot new camera system, and wanted to make sure you had to use their software to work with it.

 

Well if you had read the entire list you would know that it is not just Avid and Quantel it is also Grass Valley, it is Apple, it is Canopus, it is Microsoft, it is Telestream, it is Focus Enhancements it is a lot of folks. I find it interesting that you have decided to take this to a conspiracy theory discussion just because you only want to acknowledge two of the names that have been out there and associated with working in P2 and even in my previous post.

 

>I should not have to manually input scene and take numbers. I don't have to do this in any other solid state media device. The only way to do it at the moment is to read the slate out of the frame, which is quite literally as backward and inconvenient as film. Please, if you get them to fix nothing else, get them to fix this.

 

Which solid state device, you mean like a digital still camera? Hey my solid Nikon state camera gives me numbers which I then have to rename. So which one are you talking about? An audio device, is it looking to include metadata? Does it roll from one card to the next, does it have proxies associated with it and then how about a voice memo that can be used to annotate the interview, or shot marker that allows you to see in the P2 viewer which shot is the best one, or links all of the shot markered shots for a singular playout of the clips?

 

>But you can have SC001_T003_0255F.MXF if you're really convinced that we need that level of differentiation. Or more sensibly you can have it be an option. You really think the average HVX-200 user is going to have the sort of problems you're trying to avoid? Of course not, it's an independent movie camera.

 

Phil, when you design a camera, you have to make some things automatic or else people just run head long into trouble, and the HVX200 will be used by a much wider group of customers than independent filmmakers, it too could be employed by the TV stations much in the same way as they currenly employ the PD-150s and DVX100s. The HVX all by itself will have many decisions that will need to be made. This one frankly, if we took the suggestion, would then keep them from importing the clips as then the naming convention no longer works within the standard.

 

There are plenty of strategies that people can work with. Your suggestion is a little late. Unfortunately you should have been a part of the MXF SMPTE committee. If we follow a standard, then others can build to that standard. The naming convention is in the standard. And SMPTE is made up of engineers that are vastly smarter than I am and so when you say ?what, they're not infallible?? I wonder. This is silly. It is not one engineer that passes a standard is a body of extremely bright people that look at a standard and deteremin if it is well enough described so that others can build to it.

 

>DV25 or DV50?

 

Actually it worked in DVCPRO and DVCPRO50 clips.

 

>Until very recently, the Microsoft directshow splitter for ivas RIFF chunks was not working for DV50. If they have fixed this - woohoo!

 

All I can say is that it worked and I would imagine that is because Microsoft has supported DVCPRO50 since at least NAB ore service pac 2.

 

>> Well, all I can say is that the broadcasters that have the Newscutter here seem to be working with it just fine

 

>Yes, yes, you can keep telling me that you have a lot of people who like it, but that doesn't deflect the problems it has. This isn't an answer. Like I said, big news setup, complete refit for P2 workflow, fine, lovely, best thing since sliced bread. Having some people happy with it does not mean there are no problems with it.

 

But you keep not paying attention to the other things that it also works with. And when I talk about the very product that you said didn't work for you, you don?t acknowledge the fact that IT does work and it works fine. You seem to discount the fact that because it works on Newscutter, which you couldn?t make work, as irrelevant now because it doesn?t work on small systems or you don?t work on Avid that much, and then when I point out that even the HD footage from the HVX200 was working with FCP, Canopus, and Avid XPress Pro HD at IBC, this is ignored as irrelevant as well. Point is that it does work and people do work with the naming convention as a part of the file. As I said, if you wanted to rename the clip you could address the User clip name. And that could be viable. Or you could look at Thumbnails with Time code. That also works, or the mode that sllows description, that too works. You say it has problems but frankly we don't see this the same way. And we probably will always be on opposite sides of the fence on this one.

 

>How can I put this... I'm into IT. I understand what it's trying to do and believe me I understand where it's failing to make all it could of the IT integration. The reason I'm so concerned about this is that it's such a titanic unnecessarily missed opportunity.

 

Well if you were into IT then you would have to understand a bigger picture than Phil?s desktop. When you have to make something that will work in a multi-camera shoot and an Indy scenario, this is what the Standard does. The fact that it does not name it by clip, is, well unfortunate in your eyes, but still viable. There are many ways to manage the data and frankly looking at the clip thumbnail and the TC, I can tell just about when and if it was clip one or two and I don?t even have to rename to see this. The missed opportunity is not missed at all.

 

>> Frankly I believe whole heartedly that this is the coolest thing to happen to video since 24P.

 

>I'm sorry, but you really do beg for this - of course you like it. You are being paid a lot of money and being offered a jet-set lifestyle to like it. Employ me in the same role and I'm sure I could find a lot of reasons to like it!

 

Well it is interesting that you choose to discount my opinion because I have a "jet-set lifestyle." This is freakin? laughable as anyone that has seen me in the last three weeks at Res-Fest. I have worked everyday since the 5th of September, talking to customers at now 4 ResFests, at the IFP Market and the IBC, plus also doing my own job on the side. If this is a jet set style life, I don't think that many would volunteer for it. Point is that you so easily discount what I say because I am paid by Panasonic and give yourself all of the credit in the world. I have been in this industry for 32 years in one position or another. I have worked with vast numbers of individuals that only want to shoot video and get paid. I put my pants on just like you do and I can actually discuss trends in this industry.

 

>That doesn't answer the question. Why is MXF more appropriate than a format that is just as capable and much more widely compatible?

 

Already answered this question.

 

>What does MXF audio, MXF video, MXF timecode, MXF proxies and XML metadata do that you could not do with a straight DIF and XML, or ivas AVI with new RIFF chunks, exactly the same way a Broadcast Wave works so well in devices like the Fostex PD-6 and FR-2? Again, feel free to have an engineer answer these questions.

 

Already answered this question. And having an engineer come on here and state the same things that I already have so that you can just continue in your rant that it doesn?t work and nothing is compatible seems like a waste of his time. I have explained it, I have pointed to the standards on this, and since all of our Partners have figured out how to work with the file structure, begs the question, why would we change. We are now into this for 2 years now with systems working, why would we change it?

 

>> So are you saying the following a SMPTE standard is not a good practice?

 

>Yes, that's exactly what I'm saying. What, they're infalliable?

 

Well let's just say that standards are what make things repeatable, definable and ultimately interchangeable.

 

>> The OP Atom is operationally robust.

 

>As is raw DIF, a fact attested to by every DVCAM, DVCPRO and miniDV camera out there. And that's a few cameras.

 

But these do not do with the MXF does, which is multiuser, right off the card editing. I can't do an audio split edit from the card if the audio is interleaved as it is in these formats. I would have to fully import them into the system before I edited. These do not have the room for pointers for the card-spanning feature.

 

>> Again, I cannot explain your experience, but it seems to work exactly so when I see the demo.

 

>Look, here we go. Five directories, five files. Files are not held together by the magic MXF fairies. Files are separate. It is annoying.

 

Yes you can find this strutcture in Windows Explorer, but in our working with the Newscutter or with any of the others they are imported together and brought onto the timeline as if it were a clip, unless I choose Video or audio only.

 

> Well on the HVX200, it will jam time-code over 1394, so if the audio recorder outputs a TC on a 1394 link, the HVX can hear it and jam to it.

 

Y'see this is the thing. You've never actually done this, have you? You've never tried to line up audio and video takes. You get your soundtrack, which would be called something like Scene_01_take_01.wav, from something like a PD6. You then look for your video file for that scene and take. But it's called:

 

>0255F.MXF

 

And what would it be called on if it had been recorded on tape and then imported? At the time of digitizing it would be named, and you would have named it that by virtue of the log you made during production. You can rename the clip, in the User Clip area. And yes I have done this before, and I have sat in a lot of production areas. I choose what I do because I enjoy this more. Frankly I think most of the indy folks that I know would work thorough the P2 viewer and rename clips, but they may also just bring the clips into the NLE and work with the viewer there.

 

>You begin to see the problem? You have a directory full of this crap and you have to search individually for the one you want by opening them individually. Several hundred of them. The magic MXF fairies do not save you from this. The magic P2 viewer does not save you from this.

 

If you work the NLE, there is a number of different views that can offer different methodologies to working with the Thumbnails, timecode, comments, all of this is part f the logging in process. No the Fairies do not deal with the fact that you need to look at the Thumbnail, or log in the footage, and type some thing in that makes it work for you. But if you were to compare it to tape, you would be in the same situation, you would be logging in the footage. However, on P2 is still faster as I do not have to wait for it to be digitized before I log it in.

 

>Have I now made this problem sufficiently clear? Can you please - sob, wail - please, please, pretty please make it burn the take number into the filename? If nothing else.

 

Phil, fortunately we are a standards based company. Systems delivering today work with the file structure. People, yes, even individual production guys have worked through the process and no they were not a big news organization. There are other ways to work around this naming issue, if you don?t want to, that is your choice. As far as your other complaints, frankly I don?t see that they have much weight as the system that you said that didn?t work, does, exactly as I say, and the other systems that you say are not compatible are.

 

So now I will move on to your next post. Might be a day or so before I finish my response to that one as today should be our busiest day at Res.

 

Best regards,

 

Jan

[Phil Rhodes]

Hi,

 

> But the other day your complaint was all about not being able to import into Newscutter without having to

> bring in these audio and video files separately, which BTW, I just did the demo here at Res and it works just

> fine

 

This is true only if you're coming off the card. If you want to archive a card to local storage and access it there - and this is Avid's procedure reccomended to me by their engineer - you have to manually copy the video and audio MXFs to the Avid's media bin. And if you want to look at them in P2 viewer, you have to have them somewhere else. Duh?!

 

I'm not doing your demo, I'm working in the real world.

 

> The fact that you choose to discount standards

 

That's not so; I just prefer standards that are widely supported and easily implemented; I deprecate standards which require the user (with a multiple-task involvement) to jump through a lot of hoops to make it easier for the engineer (a single-task involvement).

 

Yes, you have some big names attached; I have shown that the implementation of at least one of these is wanting, even two years after release as you say. I run a mainly After Effects suite and I have no ability to read MXF at all. You can blame Adobe to some extent but I can't question them for not chasing the standards; Avid is already dumping OMF for MXF before much of the rest of the world has caught up with the earlier format. The problem with standards is that we have too many of them!

 

> it allows for the ability to multi-share and start editing right off of the card itself, right down to doing split

> edits

 

I will be happy to demonstrate any of the usual formats being split edited from a compactflash card on two separate systems anytime you're in the area.

 

> A Dif doesn?t have MetaData,

 

Yes, it does, it has the timecode and user bits and the dimensions of the frame, and aspects such as audio sample size, and rate are implicit to the format markers. It has everything useful that P2 has but for the name of the clip, and that's what the filename field is for.

 

And P2 doesn't store the userbits in the XML. Oops.

 

> which flavor of AVI is that?

 

One of a number (principally two), but which is still a much smaller number than the number of possible MXF layouts.

 

And most decoders - I'd say every, but I haven't used every single one - will decode type 1 or 2, that is RIFF AVI in IVAS or demuxed VIDS and AUDS with embedded, duplicated or demuxed audio, at least where VIDC is DV25, even when it's PAL 4:1:1.

 

> In the P2 domain if you roll from one card to the next in the middle of a take

 

Which the newscutter does not automatically reassemble anyway. This is one of the first questions I asked at the introduction I was given, and the answer was no.

 

If you can remember back in the days of 4Gb file limits on FAT32 volumes under windows, there were very competent methodologies for piecing together split files. Matrox's RT and Digisuite series did it with AVI files.

 

> Hey my solid Nikon state camera gives me numbers

 

Annoying, isn't it? No, I mean like the audio devices I've mentioned here which work very, very well and drop into existing workflow like a complex-shaped peg into a preexistingly complex-shaped hole and fill it so neatly that you wonder how you lived without it.

 

> An audio device, is it looking to include metadata?

 

Yes. Peruse the documentation:

 

http://www.ebu.ch/departments/technical/tr...74-chalmers.pdf

 

Peruse also an overview of the RIFF format and understand how it would work for you:

 

http://www.digitalpreservation.gov/formats...fdd000025.shtml

 

> Phil, when you design a camera, you have to make some things automatic or else people just run head

> long into trouble

 

The sort of thing you're referring to would only be as bad as setting timecode wrongly, which is bad, but recoverable, and happens all the time, and isn't precluded by P2 anyway.

 

> ...ignored as irrelevant [long list of supporters]

 

All of those supporters would have intrinsically been supporters if you'd used a more widespread format; if you'd used a more widespread format, you would have been able to list every company in the world there because it would not have required a specific implementation. Therefore, the long list of supporters does not imply that the choice of standard was a good one. Once again, given these facts, and I'm going to keep on asking this until you come up with a straight answer: how is it better than a preexisting format? What can it do that they cannot?

 

The answer, if you're interested, is "nothing". I appreciate I'm talking to a salesperson who doesn't have the background in the technology; that's fine, that's OK, it's just another example of a big company putting you poor saps out front to deflect probing technical questions you're unprepared to answer, and I absolutely don't mean that as an insult. The reason you get arguments like this happen is that they just won't let us talk to the engineers who can actually answer the questions as engineers talking to other engineers tend to be rather too honest for company politics!

 

> Well let's just say that standards are what make things repeatable, definable and ultimately

> interchangeable.

 

Yes, use an interchangeable format. Plenty exist. No need to go get another.

 

And, as I have shown, MXF lacks programme interchange with apparently-identical media. P2 MXF is not XDCAM MXF but I can't tell by looking at it. Stupid. Stupider than Type 1 and 2 AVIs when almost all decoders will read either (and the technical implementation to do it is not too bad).

 

> But if you were to compare it to tape, you would be in the same situation, you would be logging in the

> footage

 

You do realise you just told me that the logging process for P2 is no better than it is for tape? And that's stupid for a format which could choose to do it much more easily. Again reference PD6, again reference broadcast wave.

 

> Phil, fortunately we are a standards based company.

 

And there are many preexisting standards out there you could have chosen which would have all worked much better, automatically and withot fuss, than the one you did.

 

I shudder to think what you have cost people in time and money with this.

 

Phil

[Phil Rhodes]

Hi,

 

I think there are still questions to be answered here. Or shall we assume that my interpretation stands?

 

Phil

[Jan Crittenden]

Hi,

 

I think there are still questions to be answered here. Or shall we assume that my interpretation stands?

 

Phil

 

Actually no, just trying to figure out how and where to host the video clip that we have showing that this is not the only way to do the exersize when working with Newscutter or any other NLE but since we were discussing Newscutter, that is what we used. Also trying to find the time to answer the point by point. I actually do have a pretty intense job that has other deadlines that are more pressing. I did ask Tim to keep the topic open for a reason.

 

Soon, but not today,

 

Jan

Edited October 18, 2005 by Jan Crittenden

[Stephen Williams]

I actually do have a pretty intense job that has other deadlines that are more pressing.

Jan

 

Jan,

 

This is one of the most interesting threads since I have been a member!

 

9 days of silence is a long time. I know the thread was locked for a couple of days, but I would have hoped answering Phil's questions would be a no 1 priority.

 

Just my 2c

 

Stephen

[Jan Crittenden]

This is one of the most interesting threads since I have been a member!

9 days of silence is a long time. I know the thread was locked for a couple of days, but I would have hoped answering Phil's questions would be a no 1 priority.

 

Hi Stephen,

 

I understand that it may be interesting, frankly there are other things in my job description to which I must attend. When the first two posts were made I was on tour with Resfest (SF and LA)so nights and weekends were in a hotel room. I am now at home. My husband is undergoing chemotherapy, and while at home I find I need to be here now. I am sure you all can understand. Take on top of this the idea that posting on the internet is less than 5% of my job responsibilities. I respond to the internet during the day between things like marketing bulletins, answering email from vendors and dealing with maketing plans and at night when my dear one has retired. Responses to obdurate positions requires a point by point rebuttal which just consumes hours at a time because I feel as though I need to be both clear and sure of my responses. Right now I have a number of things that take priority, like the AG-DVX100B Launch and a major announcement on the AJ-SDC615. They deserve a pro-active marketing effort.

 

So I appreciate your patience.

 

Best,

 

Jan

[Kent Nason]

Hi Jan

I'm new to this forum thing so forgive my blunders. Steve is right, this is very interesting and it's nice to get a chance to consult a rep who definitely knows her product. I have been shooting documentaries for more than thirty years and have just completed shooting two HD docs using 2/3 incn Panasonic cameras with great success. Jan do you know if Panasonic will be releasing this camera with a tape drive as well as the P2 configuration? This camera is very interesting and is looking to the future but the memory/hard drive issue is questionable considering the success of the 100 don't you think? java script:emoticon(':)',%20'smid_3')

 

 

Hi Stephen,

 

I understand that it may be interesting, frankly there are other things in my job description to which I must attend. When the first two posts were made I was on tour with Resfest (SF and LA)so nights and weekends were in a hotel room. I am now at home. My husband is undergoing chemotherapy, and while at home I find I need to be here now. I am sure you all can understand. Take on top of this the idea that posting on the internet is less than 5% of my job responsibilities. I respond to the internet during the day between things like marketing bulletins, answering email from vendors and dealing with maketing plans and at night when my dear one has retired. Responses to obdurate positions requires a point by point rebuttal which just consumes hours at a time because I feel as though I need to be both clear and sure of my responses. Right now I have a number of things that take priority, like the AG-DVX100B Launch and a major announcement on the AJ-SDC615. They deserve a pro-active marketing effort.

 

So I appreciate your patience.

 

Best,

 

Jan

[David Mullen ASC]

The only reason they can offer DVCPROHD recording in an under-$10,000 consumer camera is by not building it with a DVCPROHD deck. Even their cheapest camera with a DVCPRO50 deck is $20,000, and that's a bargain compared to Digital Betacam. I believe the cheapest DVCPROHD camcorder out there is $60,000.

 

The only way to put an HD deck in this consumer camera at this price level would be to go to the highly-compressed consumer HDV route, which Panasonic is trying to avoid. Besides, if you want to shoot and record HDV, there are already cameras out there that offer that.

 

You're not going to see any cheap consumer camera with one of the pro HD tape format decks built into them (HDCAM, DVCPROHD, HD-D5, HDCAM-SR).

 

Eliminating a deck (I'm ignoring the DV one that comes with this camera) gives the manufacturers the ability to offer a wider range of frame rates, resolutions, compression schemes, etc. because it's all just data to be recorded to memory, not some particular video codec that has to be hardwired into a deck, a deck that need recording heads of certain track sizes, etc.

Edited November 6, 2005 by David Mullen

[Jan Crittenden]

Jan do you know if Panasonic will be releasing this camera with a tape drive as well as the P2 configuration?(':)',%20'smid_3')

 

There is a tape drive, it records DV. The DVCPRO HD deck would be vastly too expensive to put into a camera of this price range, as David mentions.

 

This camera is very interesting and is looking to the future but the memory/hard drive issue is questionable considering the success of the 100 don't you think?

 

I guess I don't know what you mean. If you would care to elaborate, I will try to answer, but what do you mean by the "success of the 100? 100Mbs, DVX100? I don't know where you are going as both are very successful, so I don't understand your question.

 

Best,

 

Jan

[Mark Allen]

My two cents...

 

I have no problems at all with the memory card use. The motivations for it make perfect sense to me - bringing higher quality to us at a more affordable price... That's great for the consumer.

 

I think the use of tape will be history long before the use of film.

 

I have seen Jan at one of the showings of the HVX200 and was notably impressed with her knowledge of her product and attention to clarity when it was discussed.

 

As for the multiple frame rates - when it was being shown these were not decided. If it is not totally variable, would highly highly lobby for 22 to be included. One migth pass it over as not being noticeable enough - but this is exactly why it's so great for shooting action scenes. All hong kong martial arts are shot at 22... (well, in actuality, they go nuts with frame rates and will go even fractions because they are so in tune with their actor's speeds - but 22 is the del facto standard). So, for the sake of action - consider 22.

[Phil Rhodes]

Hi,

 

Yes, I agree, in the broad strokes it's a very good idea - it's just been wrecked by some very silly decisions in the details.

 

Phil