[opendtv] Re: Production Codecs
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 16 Jul 2008 08:54:19 -0700
Dan;
MXF works just fine, between and among vendors. And, I suspect that you are
not going to engineer an MXF system from source documents.
There is a problem with the latest reworkings of the spec. It seems that
two major vendors (Avid and Sony) made some technically non-compliant
changes that didn't seem to affect anything until the new changes were
proposed, and ALL HELL BROKE OUT. Some of the changes were good, others
seemed to have been intended to cause chaos.
I have suggested to you time and time again to join SMPTE. The battle was
"fine fun" last fall. People who aren't on the WG email reflector only got
this in a small dribble, and EVERY article I've read about the controversy
was slanted, ill-informed or ignorant. Basically, customers like PBS, like
NBC, were doing the log-rolling for Avid and Sony, who never commented on
the reflector. At one point, the AAF acted like they should have a veto on
SMPTE specifications.
I have it on good authority that the changes wouldn't break much on the
Snell & Wilcox side, but that's not exactly by design. The intellectual
author of MXF is Bruce Devlin of Snell. At one time, they had a microsite
on MXF, but this is what they have now http://www.snellwilcox.com/mxf/. I
wonder where my archive of the applications formerly there are .
Before you ask someone hereabouts concerning something as technical as MXF,
it's important to ask how their employer supports MXF. In the case of
Harris, I believe that's about zero. Harris has been the big driver behind
BXF, but aside from a similar moniker, they are quite different and have
distinct domains within TV plants.
It's also important to ask about their personal experience with the
technology, not "what they've heard." MXF's major problem is
widely-deployed non-standard vendor-specific implementations, the inability
or lack of a desire for vendors to fess up on what they've done, and how
that will be dealt with in future upgrades. It's close to a nightmare.
What I wrote in the third paragraph above is actually news: you won't have
read it anywhere, at least anywhere I've seen. (Other than the original
posts to the SMPTE WG.)
John Willkie
_____
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de dan.grimes@xxxxxxxx
Enviado el: Wednesday, July 16, 2008 8:20 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Production Codecs
When you say drop four frames, I assume you are talking about the time code
and not actually dropping essence. Am I correct?
I wish we didn't have to deal with 29.97 and just use 30. Is there any
reason to work in a non-integer format as of Feb. 19, 2009? I suppose I'll
still need to work with other systems out there.
Are there any insights you can provide to helping get MXF to work properly?
Or is this something that must be worked out at the manufacturer's level?
We are hiring a broadcast systems integrator so hopefully they will know and
be able to work out the issues. But I would also like to know for servicing
issues.
It seems like there would be problems treating a frame as a field. But I
imagine the software deals with each differently so long as it knows which
one it is working with. Mixing a progressive frame and an interlace field
would need some special processing, although I am not sure what that process
would be. Perhaps deinterlacing with predictive fields plus down scaling to
match the 720 raster?
Dan
"Richard C. Ramsden" <ramsden@xxxxxxxxxxx>
Sent by: opendtv-bounce@xxxxxxxxxxxxx
07/15/2008 11:29 PM
Please respond to
opendtv@xxxxxxxxxxxxx
To
opendtv@xxxxxxxxxxxxx
cc
Subject
[opendtv] Re: Production Codecs
There is a hidden standard for dealing with 720p@xxxxx
It's exactly the same as 29.97. 29.97 is 59.94 fields/sec. Treat each
progressive frame as an interlaced field. Drop 4 frames where in 29.97
you'd drop 4 fields. This method is used in all Harris (my employer)
equipment. It's obvious, it works, and it doesn't break when you down
convert.
For 23.98, I expect that some application of 3:2 pull down can resolve
how drop frame can be applied.
SMPTE specs aren't very good these days. There's more that's not there,
or vaguely spec'd than that is well defined. MXF is a nightmare. What
actually works is an agreement by the major players on what the spec
means to them.
Rich
Other related posts:
