[theora-dev] Interlaed video encoding.
Tim Borer
tim.borer at rd.bbc.co.uk
Fri Aug 29 10:06:22 PDT 2003
I've been arguing the need for interlaced video compression in Theora for a
while. The BBC has about a million hours of archive material most of which
is interlaced. Very recently Greg Dyke (our head honcho) announced our
desire to create a "creative archive" in which (our own) material would be
available for non-commercial use. Therefore there is a crying need for
interlaced compression.
It is not true, technically, that we can simply "deinterlace" video and
treat it as progressive. For a start this impairs the quality and makes it
more difficult to compress. More fundamentally, it doubles the bandwidth.
When we are trying to squeeze video down wet string (56Kbit telephone
modems or, for a minority, "broadband") doubling the bandwidth is not viable.
We are currently looking at video compression techniques to see what we
could use for distributing our content as the "creative commons". IMO any
video compression scheme which does not embrace interlace is not viable.
Without interlace in Theora we may be forced to use Real or Windows Media.
It is not simply a question of distributing our content. We also use
compression in house for production. A compression format which is only
suitable for low quality Internet streaming would not be suitable for in
house production, again giving an advantage to competing proprietary
formats. If we have to use different formats for production and
distribution this is a disadvantage for us (involving transcoding between
compression formats with inevitable loss of quality) and so would mitigate
against Theora if it did not support interlace. On the other hand were we
to find a suitable, non-proprietary format to distribute our content might
it not give that format quite a boost?
There is another, much easier, issue which also needs to be addressed for
professional use. This is the ability to support greater chroma bandwidths
(4:2:2 and 4:4:4 maybe even 4:4:4:4). Whist 4:2:0 currently used is
adequate for consumer use and internet streaming it is not suitable for
other purposes.
I believe that without supporting interlace and greater chroma bandwidth
Theora will only ever be a niche format. I would like to see Theora gain
greater credibility than this. I would like to see Theora succeed. The
issues of whether a compression format is suitable for distribution is not
separate (for us) from whether it is suitable for production. Incidentally
this does not apply for audio since, for production, we try to maintain a
linear PCM (no compression) chain, which is possible because of the lower
bit rate.
The transition from MPEG1 to MPEG2 was mainly about implementing interlaced
compression. MPEG1 was not viable for broadcasting because it did not
support interlace. MPEG2, which is essentially the same thing but
supporting interlace, is now THE worldwide standard for high quality video
distribution (DVD and digital broadcasting). Nuff said.
My opinion is that implementation of interlaced compression is a crucial
issue for Theora.
I don't believe the patent problems are too severe (I have been working in
this field for 15 years).
Implementing compression of interlaced video need not be too technically
challenging. My favoured option is simply to treat fields as frames. This
would be relatively simple to implement and give a significant boost to
compression efficiency for interlaced content. Sure this would not give the
best possible compression performance but it would go a long way towards
this without being complex to implement (it needs no changes to the core
compression methods, it simply requires the data to those routines to be
appropriately formatted). Better performance could probably be achieved by
allowing for the 1 picture line offset between fields, it might also be
improved by prefiltering the fields and maybe post filtering them on
decompression. These simple techniques would probably get Theora most of
the way there and I find it inconceivable that such obvious simple
techniques can be patented (but who knows with patents). MPEG2/4 does lots
of clever and complex things at the block level. It is these sort of things
that are patented. Whilst these sort of techniques gains a bit on
compression efficiency it takes a lot of development to implement them and
it is probably a question of diminishing returns. Much better, in my
opinion, to get something out there with a simple form of interlaced
compression and develop it further later if needs be.
I have been hoping to persuade Xiph to initiate some work on interlaced
compression. Although I've discussed this first with Emmett and latterly
with Jack I don't seem to have been very persuasive.
Please note these are my own personal opinions and in no way represent any
sort of official BBC position.
At 22:13 26/08/2003 -0400, you wrote:
>Adding interlaced support to Theora has been discussed. Without going into
>the technical details of our approach, the main issue is that this is a
>heavily patented arena. Some people believe that many of the patents are
>very weak, but we are not patent lawyers, and a quick search of just MPEG2
>patents yielded almost 30 that involved interlacing in the US alone.
>
>In other words, the challenge is not a technical one, it is a legal one,
>and currently the time involved simply to read and comprehend all the
>patents involved is prohibitive.
>
>--- >8 ----
>List archives: http://www.xiph.org/archives/
>Ogg project homepage: http://www.xiph.org/ogg/
>To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
>containing only the word 'unsubscribe' in the body. No subject is needed.
>Unsubscribe messages sent to the list will be ignored/filtered.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Theora-dev
mailing list