[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