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.