I had in mind trimming the current Dirac spec of
everything covered in SMPTE 2042. (BTW the SMPTE
spec is originated in MS Word 2003 because that,
for good or ill, is the SMPTE's standard document
format). I think this is really the only way of
preventing divergence. This would also produce a
document that could be standardised by the SMPTE.
Redistribution terms for SMPTE standards are,
like all standards documents, difficult. Even
though the spec was mainly written by the BBC
team nevertheless SMPTE own the copyright and
sell the spec. We did have an early draft of the
VC-2 spec on our web site - but it was spotted by
an SMPTE member and we had to take it down or
jeopardise the standardisation process. This
does, I appreciate, make like difficult for an
open source, open technology, like Dirac. The
IETF might be a better standardisation
organisation from this point of view but they
have no track record for things like codecs
(whereas the SMPTE standardised Microsofts VC-1
codec). So we had good reasons for going via the SMPTE.
Usually the way these things work is that those
who need the SMPTE spec can usually get a copy
informally through a forum such as this. Or
drafts can be made available on line. This is not
ideal but is no worse than any other standardised code.
Thanks you for your kind comments on the
completeness of the spec, we did put a lot of work into it.
Tim
At 23:22 06/03/2010, Tommy Thorn wrote:
Thanks Tim,
certainly, all the work that has gone into SMPTE
2042 shall not be ignored. In the immediate
term, I'll double check issues I found against
the SMPTE to the extent that the latter covers
them. I still think it's worthwhile correcting
the obvious issues now, regardless of the longer term solution.
When you say include the SMPTE spec by
reference, does that imply trimming the current
Dirac spec of everything covered by SMPTE 2042
and adjusting the rest to be a natural
extension, or are you suggesting embedding the
SMPTE spec into the current Dirac document
(potentially by translating the Word document to
LaTeX)? Assuming the former, what are the
redistribution terms of SMPTE 2042? Are the test streams freely available?
Having never had any exposure to video codecs
before and practically no knowledge of signal
processing, I was very impressed by the
completeness and quality of the Dirac spec. It
enabled me to write a decoder exclusively based
on the spec except for just a couple of issues
that I'll bring up later (unfortunately my
decoder doesn't do intra frames correctly yet).
Regards,
Tommy
On Mar 6, 2010, at 00:47 , Tim Borer wrote:
> Recent work on specification has focused on
the SMPTE specification for Dirac Pro/VC-2.
VC-2 or SMPTE 2042 is the intraframe coding
subset of the complete Dirac spec. Although
that may sound like a small sub-set, in fact it
includes most of the Dirac spec. It includes
everything about the wavelet transform and
arithmetic coding, data types, stream syntax
etc. Of course it doesnt include details of
the inter frame coding but that actually
represents a relatively small proportion of the spec.
>
> I have been working with the SMPTE on
specification over the past few years. Late
last year the core part of the Dirac Pro spec
SMPTE 2042-1 was ratified. This is a one
hundred and thirty odd page spec defining the
core decoder. More recently parts 2 (level
specifications) and part 3 (conformance
testing, including conformance test streams)
have also been ratified. So now Dirac
Pro/VC-2/SMPTE 2042 is a fully ratified
international codec spec available from the
SMPTE store. In addition there are some
specialised SMPTE specs relating to specific broadcast applications.
>
> In considering updating the Dirac long GOP
spec we need to ensure that the SMPTE spec
remains the master (as far as it goes). It
would be bad if the two specifications
diverged. The SMPTE spec has been subject to
considerable peer review in the SMPTE standards
committee. It has diverged from the Dirac spec
in order to correct bugs etc. It is a more
reliable reference for the part of Dirac that
it covers than the Dirac spec. Of course, like
all documents, it probably still has bugs in
it. I would request that if Dirac users have
queries about the Dirac spec they first check
the SMPTE spec. If they could then note and
send me any errors I can get them corrigendum
to the specification. If you arent able to
obtain a copy of the SMPTE spec then contact me and I will see what I can do.
>
> I think the long GOP Dirac spec needs
redrafting so that it normatively includes the
SMPTE spec by reference. That way we can ensure
that the two do not diverge. This is quite a
lot of work and, at present, the BBC is
reluctant to commit many resources, but I will
see what I can do. Ideally we would release an
addition to the existing specification (SMPTE
2042 part 4?) that includes the interframe
coding specification. This is possible but,
having worked on the VC-2 spec or several
years, I know that it is a lot of work. Anyone out there willing to help?
>
> Please get back to me on issues of specification and standardisation.
>
> Best regards
>
> Tim Borer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2724
- Release Date: 03/05/10 13:26:00
Tim Borer
BBC Research & Development
BBC Centre House
56 Wood Lane
London W12 7SB
Mobile: 07745 108652
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Schrodinger-devel mailing list
Schrodinger-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
