Subject: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)

From: Maik Merten <[email-masked]>
Date: Thu, 14 Nov 2013 11:52:35 +0100

Hello all,

in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a 
sample of H.261 video was provided, connected to a (rhetorical?) 
question if this provided quality would be acceptable for users. Clearly 
that provided sample is of very low and unacceptable quality.

Just for comparison, here are two CIF samples at roughly 256k created by 
a somewhat modern encoder (ffmpeg with rate/distortion optimization):

https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg

https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg

(encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when 
using rate/distortion optimization. I understand MPEG-1 if used without 
b-frames is similar to H.261 in coding efficiency, but mostly adds more 
flexibility regarding frame sizes.

ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp 
2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )

Even without formal testing it is obvious that H.261 and/or MPEG-1 video 
is clearly outperformed in terms of coding efficiency by H.264 and VP8. 
However, personally, speaking as an end-user, I would very much prefer 
this video quality over audio-only calls (in cases where transcoding is 
not available), as the video produced still carries useful information. 
Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and 
is not exceedingly difficult to implement.

Of course a MTI codec with higher coding performance is much preferable. 
However, if no such high-performance codec with licensing terms that are 
acceptable for all communities can be agreed on I think it may be wise 
to seriously evaluate the option of implementing an outdated codec for 
the sake of interoperability. In practice, most calls will negotiate to 
H.264 and VP8 anyways, but sporadic negotiation failures that are 
difficult to account for by the user are still to be expected if no MTI 
codec is defined at all.

Best regards,

Maik

---

From: Maik Merten <[email-masked]>
Date: Thu, 14 Nov 2013 20:12:29 +0100

Hello again,

to allow for having a quick look at some test sequences I put together a 
very very sloppy overview page at

https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html

This includes a completely JavaScript-based MPEG-1 player for those that 
don't happen to have a fitting decoder installed (also, yay, JavaScript 
is fast enough now for simple video decoders!). I recreated the encoded 
files to ensure there are no b-frames and documented the encoder 
settings accordingly.

Best regards,

Maik

---

From: Leon Geyser <[email-masked]>
Date: Thu, 14 Nov 2013 21:35:32 +0200

>>This includes a completely JavaScript-based MPEG-1 player for those that
don't happen to have a fitting decoder installed >>(also, yay, JavaScript
is fast enough now for simple video decoders!). I recreated the encoded
files to ensure there are no >>b-frames and documented the encoder settings
accordingly.
Thanks for sharing. Looks better than what I expected.

On 14 November 2013 21:12, Maik Merten <[email-masked]> wrote:

> don't happen to have a fitting decoder installed (also, yay, JavaScript is
> fast enough now for simple video decoders!). I recreated the encoded files
> to ensure there are no b-frames and documented the encoder settings
> accordingly.
>
> Best regards,
>
> Maik
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 14:48:32 -0500

Just a reminder: Native applications don't necessarily have access to 
Javascript (they're running outside of a browser) so a Javascript-based 
solution sounds problematic to me. Everything we need should be 
accessible from WebRTC's Native API. If that happens to include a 
Javascript engine under the hood, so be it, but I just want to make sure 
this is understood.

Thanks,
Gili

On 14/11/2013 2:35 PM, Leon Geyser wrote:
> >>This includes a completely JavaScript-based MPEG-1 player for those 
> that don't happen to have a fitting decoder installed >>(also, yay, 
> JavaScript is fast enough now for simple video decoders!). I recreated 
> the encoded files to ensure there are no >>b-frames and documented the 
> encoder settings accordingly.
> On 14 November 2013 21:12, Maik Merten <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello again,
>
>     to allow for having a quick look at some test sequences I put
>     together a very very sloppy overview page at
>
>     This includes a completely JavaScript-based MPEG-1 player for
>     those that don't happen to have a fitting decoder installed (also,
>     yay, JavaScript is fast enough now for simple video decoders!). I
>     recreated the encoded files to ensure there are no b-frames and
>     documented the encoder settings accordingly.
>
>     Best regards,
>
>     Maik
>
>
>         in
>         http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html
>         a
>     [email-masked] <mailto:[email-masked]>

---

From: Maik Merten <[email-masked]>
Date: Thu, 14 Nov 2013 20:54:15 +0100

I included the JavaScript MPEG decoder so that people can have a quick 
look. I don't propose that videos should be decoded in JavaScript for 
WebRTC. If anything this merely demonstrates that old codecs have low 
processing requirements (duh!).

Maik

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Nov 2013 11:59:39 -0800

Thanks, this is interesting. Is the ffmpeg 261 encoder limited to CIF/QCIF,
or can you specify arbitrary sizes?

---

From: Maik Merten <[email-masked]>
Date: Thu, 14 Nov 2013 21:29:58 +0100

Am 14.11.2013 20:59, schrieb Justin Uberti:
> Thanks, this is interesting. Is the ffmpeg 261 encoder limited to
> CIF/QCIF, or can you specify arbitrary sizes?

As far as I know CIF/QCIF is hardcoded into the H.261 bitstream format, 
so there is nothing ffmpeg can do about it. The bitstream format of 
MPEG-1 Part 2 lifts this restriction.

Maik

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 15:31:33 -0500

In that case, excellent point :)

Gili

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Nov 2013 17:16:52 -0600

I sent a reply to this earlier, but just now realized that it went only 
to Justin, not to the list.

> CIF/QCIF, or can you specify arbitrary sizes?

It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm not 
sure what the difference between mpeg-1 and H.261 are, though, so we 
could be talking apples and oranges (or at least apples and pears) here. 
I'll note that mpeg-1 came out in 1991, which is a good 22 years in the 
past. I'm not drawing IPR conclusions for you, but invite you to ponder 
the implications yourself.

Following Maik's lead with the mpeg-1 js decoder, I put this together:

https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html

...with this commandline:

   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd -subcmp 
rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg

I don't really understand most of those options (I just cribbed them 
from Maik's example) or whether any of them would introduce more latency 
than is reasonable for a real-time conversation, but I will observe:

 1. The encoder claims that it was performing on the order of 90 - 100
    fps on my (admittedly modern) system;
 2. The resolution is 640x360 (somewhat larger than DCIF);
 3. The video is not, to my eye, unusable (draw your own conclusions, as
    it's clearly not as nice as modern codecs);
 4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works
    out to 508 kbits/second total.

Source video here, and NASA is acknowledged as the source of the 
material contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Nov 2013 17:22:29 -0600

On 11/14/13 17:16, Adam Roach wrote:
> # At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works 

Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime 
seems to divide it by two for some reason, although the javascript 
decode does the right thing). This works out to 254 kbps.

/a

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 15 Nov 2013 01:37:46 +0000

Folks,
Please don't consider H.261 and MPEG-1 part 2 as being in the same league in terms of coding efficiency or network friendliness.  They clearly are not.
H.261 is what many call the first generation video coding standard.  MPEG-1 (and MPEG-2) are second generation.
MPEG-1 has half-pel motion compensation.  H.261 has not.
MPEG-1 has B frames.  H.261 has not.
MPEG-1 has (arbitrary sized) slices that can be used for MTU size matching (although they are not commonly used for that purpose).  H.261 has not.  Instead, H.261 has the Group Of Block picture segmentation mechanism, that is clearly more optimized for parallel processing than for MTU size matching.
MPEG-1 allows for significantly larger motion vectors (necessitated by B frames and the resulting longer prediction interval, but can be used even in P frame only coding).
MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (in "still image" mode, designed for low frame rate application; could run at high frame rate though).
H.261 was ratified (in its first version) in 1988, and in the for all practical purposes final version in 1989.  Most people believe that all related patents have expired.
MPEG-1 was ratified in late 1992.  Its "bug fix" successor MPEG-2 (which adds interlace support) was ratified less than a year later.  There are at least two major disputes going on today regarding technology allegedly infringed by a compliant implementation of MPEG-2.  Based on my technical understanding, one of these technologies is not in any way related to interlaced.
Draw your own conclusions.
Regards,
Stephan

From: Adam Roach <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 14 November, 2013 at 15:22
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] H261/MPEG-1 video quality

On 11/14/13 17:16, Adam Roach wrote:
  *   At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works out to 508 kbits/second total.

Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime seems to divide it by two for some reason, although the javascript decode does the right thing). This works out to 254 kbps.

/a

---

From: Leon Geyser <[email-masked]>
Date: Fri, 15 Nov 2013 07:33:42 +0200

Hi everyone,
Maybe MPEG-1 Part 2 would be a better alternative to H.261. How can we
figure out if all the patents have expired for MPEG-1 Part 2?

On 15 November 2013 03:37, Stephan Wenger <[email-masked]> wrote:

>  Folks,
> Please don’t consider H.261 and MPEG-1 part 2 as being in the same league
> in terms of coding efficiency or network friendliness.  They clearly are
> not.
> H.261 is what many call the first generation video coding standard.
>  MPEG-1 (and MPEG-2) are second generation.
> MPEG-1 has (arbitrary sized) slices that can be used for MTU size matching
> (although they are not commonly used for that purpose).  H.261 has not.
>  Instead, H.261 has the Group Of Block picture segmentation mechanism, that
> is clearly more optimized for parallel processing than for MTU size
> matching.
> MPEG-1 allows for significantly larger motion vectors (necessitated by B
> frames and the resulting longer prediction interval, but can be used even
> in P frame only coding).
> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (in
> “still image” mode, designed for low frame rate application; could run at
> high frame rate though).
> H.261 was ratified (in its first version) in 1988, and in the for all
> practical purposes final version in 1989.  Most people believe that all
> related patents have expired.
> MPEG-1 was ratified in late 1992.  Its “bug fix” successor MPEG-2 (which
> adds interlace support) was ratified less than a year later.  There are at
> least two major disputes going on today regarding technology allegedly
> infringed by a compliant implementation of MPEG-2.  Based on my technical
> understanding, one of these technologies is not in any way related to
> interlaced.
>   From: Adam Roach <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works out
> to 508 kbits/second total.
>
>
> seems to divide it by two for some reason, although the javascript decode
> does the right thing). This works out to 254 kbps.
>
> /a
>

---

From: Monty Montgomery <[email-masked]>
Date: Fri, 15 Nov 2013 00:39:07 -0500

Stephan just implied strongly they haven't, despite the 20 years.

And, BTW, I was serious when I mentioned Theora earlier as well.

Monty

On Fri, Nov 15, 2013 at 12:33 AM, Leon Geyser <[email-masked]> wrote:
>> frames and the resulting longer prediction interval, but can be used even in
>> P frame only coding).

---

From: Leon Geyser <[email-masked]>
Date: Fri, 15 Nov 2013 07:57:32 +0200

Hi Monty,

I do like Theora; it compares well against MPEG-4 Part 2:ASP, but won't the
reasons why some people don't want to implement VP8 be the same for Theora?

On 15 November 2013 07:39, Monty Montgomery <[email-masked]> wrote:

> decode

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Nov 2013 08:27:10 +0100

> And, BTW, I was serious when I mentioned Theora earlier as well.

If you want this on the list of alternatives, please send an email in
the other thread with the MUST statement. I would also request that you
include a reference to the codec, and any needed scoping of your proposal.

Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Maik Merten <[email-masked]>
Date: Fri, 15 Nov 2013 08:39:59 +0100

> Stephan just implied strongly they haven't, despite the 20 years.

Would sure be nice what those disputes Stephan mentions are actually about.

After all, a major premise of IVC (one of MPEG's efforts to get a RF 
codec) is that MPEG-1 video is considered free by now and I see some 
people being active there that are quite IP-aware.

MPEG-2, in contrast, is clearly a worthy target for disputes, being 
mandatory for DVD and BluRay, and there, e.g., appear to be a swath of 
somewhat "meh" IP claims targeting exactly that application and being 
filed or re-filed or re-re-filed long after the coding technology itself 
was ratified.

I see stuff like

"This is a continuation of application Ser. No. *****, filed Apr. **, 
2009, which is a continuation of application Ser. No. ******, filed Jun. 
**, 2005, now U.S. Pat. No. *****, which is a continuation of 
application Ser. No. *******, filed Apr. **, 1996, now U.S. Pat. No. 
*****, which is a continuation of application Ser. No. ******, filed 
Jan. **, 1994, now abandoned, which is entitled to the priority filing 
date of Japanese application ****** filed on Jan. **, 1993, the entirety 
all of which are incorporated herein by reference."

It's unclear to me what this *means* regarding the usability of old MPEG 
technology.

> And, BTW, I was serious when I mentioned Theora earlier as well.

Theora would clearly be preferable over H.261 or MPEG-1. It has a nice, 
widely deployed and tested implementation with BSD-style license, a 
well-written specification, has better coding efficiency than H.261 or 
MPEG-1 and is quite frugal regarding computation.

Maik

---

From: Maik Merten <[email-masked]>
Date: Fri, 15 Nov 2013 08:54:19 +0100

Dear Stephan,

thanks for highlighting the differences between H.261 and MPEG-1 Part 2.

Regarding just coding efficiency, I guess that apart from the refined 
coding tools in MPEG-1 much of the difference in practice would stem 
from outdated or buggy implementations: I simply cannot find a modern 
H.261 encoder with, e.g., rd optimization on mode decisions or trellis 
quantization (ffmpeg has these options, but crashes when enabling them 
for H.261). H.261 has clearly been neglected in this regard, making it 
difficult to assess the quality that actually can be achieved.

Best regards,

Maik

Am 15.11.2013 02:37, schrieb Stephan Wenger:
> Folks,
> Please don’t consider H.261 and MPEG-1 part 2 as being in the same
> league in terms of coding efficiency or network friendliness.  They
> clearly are not.
> MPEG-1 has (arbitrary sized) slices that can be used for MTU size
> matching (although they are not commonly used for that purpose).  H.261
> has not.  Instead, H.261 has the Group Of Block picture segmentation
> mechanism, that is clearly more optimized for parallel processing than
> for MTU size matching.
> frames and the resulting longer prediction interval, but can be used
> even in P frame only coding).
> MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF
> (in “still image” mode, designed for low frame rate application; could
> run at high frame rate though).
> adds interlace support) was ratified less than a year later.  There are
> at least two major disputes going on today regarding technology
> allegedly infringed by a compliant implementation of MPEG-2.  Based on
> my technical understanding, one of these technologies is not in any way
> related to interlaced.
> From: Adam Roach <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 08:43:09 -0500

As I've stated multiple times before in my own posts, "H.261" is a 
placeholder for "any codec for which IPR has expired".

Feel free to propose alternate codecs, and I believe this detail should 
be explicitly mentioned in the upcoming "vote". Meaning, the option that 
talks about H.261 being MTI should clarify we're talking about a 
placeholder.

Gili

On 14/11/2013 8:37 PM, Stephan Wenger wrote:
> Folks,
> Please don't consider H.261 and MPEG-1 part 2 as being in the same 
> matching (although they are not commonly used for that purpose). 
>  H.261 has not.  Instead, H.261 has the Group Of Block picture 
> segmentation mechanism, that is clearly more optimized for parallel 
> processing than for MTU size matching.
> MPEG-1 allows for significantly larger motion vectors (necessitated by 
> B frames and the resulting longer prediction interval, but can be used 
> (in "still image" mode, designed for low frame rate application; could 
> practical purposes final version in 1989.  Most people believe that 
> all related patents have expired.
> MPEG-1 was ratified in late 1992.  Its "bug fix" successor MPEG-2 
> (which adds interlace support) was ratified less than a year later. 
>  There are at least two major disputes going on today regarding 
> technology allegedly infringed by a compliant implementation of 
> MPEG-2.  Based on my technical understanding, one of these 
> technologies is not in any way related to interlaced.

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 08:47:12 -0500

Magnus,

Couldn't we alter the option with H.261 to state that we're proposing an 
IPR-expired codec *like* H.261? I don't think we need to decide at this 
moment which precise codec that would be.

Gili

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 08:52:43 -0500

Excellent work Adam. I can't speak for others, but at 254 kbps 
(corrected figure from your follow-up post) H.261 is definitely "good 
enough" and better than an audio-only connection.

Gili

On 14/11/2013 6:16 PM, Adam Roach wrote:
> I sent a reply to this earlier, but just now realized that it went 
> only to Justin, not to the list.
>
>
> It looks like the ffmpeg mpeg-1 coder works for arbitrary sizes. I'm 
> not sure what the difference between mpeg-1 and H.261 are, though, so 
> we could be talking apples and oranges (or at least apples and pears) 
> here. I'll note that mpeg-1 came out in 1991, which is a good 22 years 
> in the past. I'm not drawing IPR conclusions for you, but invite you 
> to ponder the implications yourself.
>
>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd 
> -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>
> from Maik's example) or whether any of them would introduce more 
> latency than is reasonable for a real-time conversation, but I will 
> observe:
>
>  3. The video is not, to my eye, unusable (draw your own conclusions,
>     as it's clearly not as nice as modern codecs);
>  4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding
>     works out to 508 kbits/second total.
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Nov 2013 15:22:08 +0100

On 11/15/2013 02:47 PM, cowwoc wrote:
> Magnus,
>
> Couldn't we alter the option with H.261 to state that we're proposing 
> an IPR-expired codec *like* H.261? I don't think we need to decide at 
> this moment which precise codec that would be.

If the proposal isn't for a concrete codec, it's impossible to evaluate.

Please - if you want this option to be on the table, make it a real 
option, not a "someone else should do the work necessary to figure out 
if it's a real option".

---

From: Maik Merten <[email-masked]>
Date: Fri, 15 Nov 2013 16:17:12 +0100

As pointed out by Stephan and after investigating a bit on the format 
specifics I feel compelled to state that H.261 and MPEG-1 are indeed 
different enough from each another so that performance evaluations on 
one codec cannot directly be transferred to the other. I'm still tempted 
to assume that CIF H.261 can deliver acceptable quality for talking head 
scenarios at ~256 kbit/s - however, I've yet to find a reliable H.261 
encoder implementation with up-to-date psychovisual optimizations to 
generate actual test vectors.

Best regards,

Maik

---

From: cowwoc <[email-masked]>
Date: Fri, 15 Nov 2013 10:37:01 -0500

> option, not a "someone else should do the work necessary to figure out 

Agreed. I'll reply to Magnus's thread.

Gili

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Nov 2013 14:00:50 -0800

>From what I understand, the clip from this thread was encoded using MPEG-1,
not H.261. Aside from http://www-mobile.ecs.soton.ac.uk/peter/h261/, I
don't think we have seen any samples of actual H.261 output that give a
good indication of its suitability.

On Fri, Nov 15, 2013 at 5:52 AM, cowwoc <[email-masked]> wrote:

>
> Excellent work Adam. I can't speak for others, but at 254 kbps (corrected
> figure from your follow-up post) H.261 is definitely "good enough" and
> better than an audio-only connection.
>
> Gili
>
>
> I sent a reply to this earlier, but just now realized that it went only to
> Justin, not to the list.
>
>
> sure what the difference between mpeg-1 and H.261 are, though, so we could
> be talking apples and oranges (or at least apples and pears) here. I'll
> note that mpeg-1 came out in 1991, which is a good 22 years in the past.
> I'm not drawing IPR conclusions for you, but invite you to ponder the
> implications yourself.
>
>   ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd -cmp rd -subcmp rd
> -mbcmp rd -precmp rd -trellis 2 -g 100 -vb 256k maven.mpg
>
> I don't really understand most of those options (I just cribbed them from
> Maik's example) or whether any of them would introduce more latency than is
> reasonable for a real-time conversation, but I will observe:
>
>  Source video here, and NASA is acknowledged as the source of the material
> contained therein: http://www.youtube.com/watch?v=ijAO0FFExx0
>
> /a
>
>
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Nov 2013 16:23:38 -0600

On 11/15/13 09:37, cowwoc wrote:
>>> Couldn't we alter the option with H.261 to state that we're 
>>> proposing an IPR-expired codec *like* H.261? I don't think we need 
>>> to decide at this moment which precise codec that would be.
>>
>> option, not a "someone else should do the work necessary to figure 
>> out if it's a real option".
>

Honestly, there aren't really a lot of contenders here. There's really 
not much that predates H.261 (H.120 did, but it is *actually* unusable, 
as opposed to merely whine-worthy). Here's a realistic list of codecs to 
think about, with H.120 added just as an historical backstop to indicate 
"digital video didn't realistically exist before this point in time":

Codec           | Date | Quality (comparable to)
----------------+------+---------------------------
VP8             | 2008 | Broadcast HDTV
H.264           | 2003 | Broadcast HDTV
Theora/VP3/VP4  | 2000 | DivX-encoded movies
H.263           | 1995 | RealVideo circa 2000
H.262/MPEG2     | 1995 | DVDs
MPEG1           | 1993 | CD Videodisc
H.261           | 1988 | Early "videophones"
H.120           | 1984 | Belt-sanding your eyeballs
----------------+------+---------------------------

/a

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Nov 2013 18:18:07 -0800

Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
understand where things go from bad to good.

On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. <[email-masked]> wrote:

>  <http://ge.tt/2bp1Zrz> <http://ge.tt/2bp1Zrz> <http://ge.tt/2bp1Zrz>
> http://ge.tt/2bp1Zrz
>
> options used:
> mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
> irene-256k.h261.avi sign_irene_cif.y4m
>
> mencoder.exe -ovc lavc -lavcopts
> vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
> -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>
> mencoder.exe -ovc lavc -lavcopts
> vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
> -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>
> You can probably derive ffmpeg/avconv options from those.
>
> Notes
>
>    - There's a ticket open about h261
>    <https://trac.ffmpeg.org/ticket/3143>
>    https://trac.ffmpeg.org/ticket/3143
>    - 15999 kbps was not the bitrate irene-highbitrate ended up using;
>    that was more like 1933 kbps
>    - My untrained eye did not see any difference between
>    irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but maybe most of
>    those options are (rightly) ignored for h261.
>
>
> - Hervé
>
> ------------------------------
> From: [email-masked]
> Date: Fri, 15 Nov 2013 14:00:50 -0800
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
> patents evaporated)
>
>
> From what I understand, the clip from this thread was encoded using
> MPEG-1, not H.261. Aside from
> http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have seen
> any samples of actual H.261 output that give a good indication of its
> suitability.
>
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Maik Merten <[email-masked]>
Date: Sat, 16 Nov 2013 14:22:00 +0100

I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg currently 
crashes when enabling a certain encoder feature which turns out to be 
very useful for other codecs ("trellis quantization" - which basically 
means that coefficients to be coded are selected with the encoding costs 
in mind) for the H.261 encoder. This is a rather new encoder feature 
which pays of very nicely for other formats and should be applicable for 
H.261 as well.

A major reason IMO why H.261 performs so badly (apart from the old 
format design) is that nobody seems to have cared to transfer new 
technology for determining smart encoding choices to that old format (it 
just makes little commercial sense to strap rockets onto a pig if a 
newer format such as H.263 or H.264 is available). It appears that 
encoders for H.261 are mostly "1990ies" regarding encoding technology. 
 From today's point of view such encoders are blazingly fast, but better 
quality could be achieved with encoders that spend some computation on 
making smarter encoding choices.

The ffmpeg encoder, while working, appears to be a rather 
straightforward module for ffmpeg's internal MPEG-style encoding 
framework (I quickly skimmed through the encoder source code). I'm 
surprised that the H.261 format appears, e.g., to allow for per-GOP and 
per-Macroblock quantizer settings, which may be useful for encoding 
"important" regions with higher detail than, e.g, the background. The 
ffmpeg encoder, however, does not appear to make use of this potential 
at all - it appears to exist so that ffmpeg can cover the complete 
family of H.26x formats, not primarily to produce the best quality possible.

If somebody knows a H.261 encoder aiming at high visual encoding quality 
(and preferably still maintained and available) this may yield a better 
data point for assessing the quality that can be achieved with H.261.

Maik

Am 16.11.2013 03:18, schrieb Justin Uberti:
> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     <http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz>http://ge.tt/2bp1Zrz
>
>     options used:
>       * There's a ticket open about h261
>         <https://trac.ffmpeg.org/ticket/3143>https://trac.ffmpeg.org/ticket/3143
>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>       * My untrained eye did not see any difference between
>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>         maybe most of those options are (rightly) ignored for h261.
>
>
>     - Hervé
>
>     ------------------------------------------------------------------------
>     From: [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>     CC: [email-masked] <mailto:[email-masked]>
>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>     seen any samples of actual H.261 output that give a good indication
>     of its suitability.
>
>
>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         (corrected figure from your follow-up post) H.261 is definitely
>         "good enough" and better than an audio-only connection.
>
>         Gili
>
>
>             I sent a reply to this earlier, but just now realized that
>             it went only to Justin, not to the list.
>
>
>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>
>
>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>             sizes. I'm not sure what the difference between mpeg-1 and
>             H.261 are, though, so we could be talking apples and oranges
>             (or at least apples and pears) here. I'll note that mpeg-1
>             came out in 1991, which is a good 22 years in the past. I'm
>             not drawing IPR conclusions for you, but invite you to
>             ponder the implications yourself.
>
>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>             -vb 256k maven.mpg
>
>             I don't really understand most of those options (I just
>             cribbed them from Maik's example) or whether any of them
>             would introduce more latency than is reasonable for a
>             real-time conversation, but I will observe:
>
>              1. The encoder claims that it was performing on the order
>                 of 90 - 100 fps on my (admittedly modern) system;
>              3. The video is not, to my eye, unusable (draw your own
>                 conclusions, as it's clearly not as nice as modern codecs);
>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>                 encoding works out to 508 kbits/second total.
>
>
>
>             Source video here, and NASA is acknowledged as the source of
>             the material contained therein:
>             http://www.youtube.com/watch?v=ijAO0FFExx0
>
>             /a
>
>
>

---

From: Maik Merten <[email-masked]>
Date: Sat, 16 Nov 2013 14:27:03 +0100

Typo-correction: H.261 allows for a per-GOB (Group of Blocks) quantizer. 
A per-GOP (Group of Pictures) quantizer setting makes little sense ;)

---

From: Maik Merten <[email-masked]>
Date: Sat, 16 Nov 2013 18:15:55 +0100

I uploaded a set of H.261 encodes of the sign_irene sample, ranging from 
128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my 
comments regarding its H.261 encoder into consideration.

https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=sharing

(btw, transmission of sign language is a nice example where "audio only" 
is not quite useful in case of video codec negotiation failure)

Maik

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 16 Nov 2013 18:17:24 +0000

Hi,
Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
occasional slight drops in frame rate at high motion), including the
cycles needed for G.728 audio.  We got a better quality with those
resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
encoder implementation has a lot of room for improvement.
One thing that is quite obvious in the 128 kbit/s sequence is the presence
of both blocking and mosquito artifacts.  This combination points to an
incorrect tuning of the deblocking filter.  In H.261, one can enable and
disable the deblocking filter on a per macroblock basis.  If you don¹t get
that right, you have a lousy encoder.  The heuristics were secret sauce of
a video conferencing vendor at the time, matched in importance perhaps
only by a useful echo cancellation.  The deblocking filter obviously
reduces noise at the expense of picture fidelity.  The trick is to keep it
on most of the time in areas of high energy, but occasionally (5 picture
interval?  Something like this) switch it off to capture detail, and at
the same time fine-tune the pre filter to smoothen the input signal just a
bit so to avoid creation of excessive mosquito noise, and crank up the QP.
No, I don¹t have the time to develop and contribute a patch for ffmpeg.
Stephan

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 16 Nov 2013 20:23:09 +0100

It is unexpected and good to see the Irene test sequence being reused 
for this purpose.

The sequence was originally provided for explaining the needs for sign 
language transmission, and providing a possibility to evaluate codecs 
and products used for that purpose.
If anyone want to do more experimenting on that base, the original is 
available in a couple of formats at:
http://www.itu.int/net/itu-t/sigdb/genvideo/Hsupp_1.htm

And the document explaining the needs from sign language application is 
available at:
http://www.itu.int/rec/T-REC-H.Sup1/

/Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Sat, 16 Nov 2013 17:11:22 -0500

On 11/15/2013 5:23 PM, Adam Roach wrote:
> not much that predates H.261 (H.120 did, but it is *actually* 
> unusable, as opposed to merely whine-worthy). Here's a realistic list 
> of codecs to think about, with H.120 added just as an historical 
> backstop to indicate "digital video didn't realistically exist before 
> this point in time":
>

Broadcast HDTV is MPEG2, starting circa 1999/2000,and still is so far as 
I know.  I think you mean that Cable/Satellite HDTV started using H.264 
in circa 2003.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Adam Roach <[email-masked]>
Date: Sat, 16 Nov 2013 18:22:56 -0600

On 11/16/13 16:11, Randell Jesup wrote:
> Broadcast HDTV is MPEG2, starting circa 1999/2000,and still is so far 
> as I know.  I think you mean that Cable/Satellite HDTV started using 
> H.264 in circa 2003. 

I'm don't know about the rest of the world, but at least North America 
includes H.264 as one of the supported codecs now:

http://en.wikipedia.org/wiki/Advanced_Television_Systems_Committee_standards#H.264.2FMPEG-4_AVC

Of course, given that this happened after significant hardware was out 
in the field, it's questionable whether there's been much actual *use* 
of H.264 in ATSC.

/a

---

From: Maik Merten <[email-masked]>
Date: Sun, 17 Nov 2013 15:05:53 +0100

Dear Stephan,

thanks for sharing your experience regarding high-performance H.261 
implementations and confirming my suspicion regarding ffmpeg's encoder. 
Do you happen to remember if there was any postprocessing involved at 
the receiving end? I find that playback of the low-bitrate encodes 
becomes somewhat more enjoyable with some postprocessing (deblocking, 
deringing) (mplayer -vf pp) and I wonder if one should assume the 
presence of such filters when assessing the quality achievable (given 
that any modern devices have no trouble with the additional computation).

Maik

---

From: Maik Merten <[email-masked]>
Date: Sun, 17 Nov 2013 15:29:52 +0100

Dear Gunnar,

Irene is one of my favorite test sequences: It's pleasant to look at, 
has interesting texturing detail, complex movement, diverse facial 
expressions and demonstrates an important use case for video 
communication. In fact, I think this use case nicely demonstrates why 
negotiation failure regarding video codecs should be avoided (even if 
this means making an outdated codec MTI, as long as it can transport 
sign language).

Thanks for providing a link to the ITU documentation regarding this 
application profile and test sequence - it's an interesting read!

Best regards,

Maik

Am 16.11.2013 20:23, schrieb Gunnar Hellstrom:
>> On 11.16.2013, 09:15 , "Maik Merten"<[email-masked]>  wrote:
>>
>>>>      From:[email-masked]  <mailto:[email-masked]>
>>>>      To:[email-masked]  <mailto:[email-masked]>
>>>>      CC:[email-masked]  <mailto:[email-masked]>

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 17 Nov 2013 17:23:39 +0000

Yes, post filters are helpful at low bitrates, and especially for codecs
with fixed block sizes such as H.261.  I believe we had a very simple
fixed coefficient 5 tap post filter on the vertical block edges.  Nothing
more due to cycle constrains.  I know that they did something slightly
more sophisticated later (perhaps only adding the horizontal block edges),
but at that time I had left the company.
Stephan

On 11.17.2013, 06:05 , "Maik Merten" <[email-masked]> wrote:

>>>https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=sh
>>>ar
>>> ing
>>>
>>>><http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz>http:
>>>>//
>>>> ge.tt/2bp1Zrz
>>>>
>>>>      options used:
>>>>vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subc
>>>>mp
>>>> =2:preme=2:mbd=0
>>>>vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:su
>>>>bc
>>>> mp=2:preme=2:mbd=0
>>>>              Following Maik's lead with the mpeg-1 js decoder, I put
>>>>this
>>>>              together:
>>>>
>>>>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Nov 2013 09:30:48 -0800

H.264 is also mandated in DVB, the european standard, and i'd be surprised
if there was any region on this planet where H264 is not part of any digital
TVs MTI. 

Some transmission systems like terrestrial in europe DVB-T started after
H.264 was feasible, so they have no MPEG2. All the systems with legacy MPEG2
content/receiver-equipment have some strategy to move to H264. On
the largest satellite provider in europe for example, HD is only H264
because there was no or very little HD capable MPEG2 in before. If
a provider had a lot of HD even before H264, transition is most difficult.
Thats for example the case fo MSOs in the US. 

I think the experience of evolving codecs in RTCweg will be a lot more
painfull than in TV-land if we don't pick a good MTI though because
of the different dynamics.

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Nov 2013 09:56:48 -0800

> making smarter encoding choices.

Right. I think the logics of the market space would make a choice
of h261 as MTI just a big desaster and fruitless exercise
in retro-engineering.

- You start with legacy software, then it breaks under a lot
  more/different use than what it was written for in the 90th and you
  have to invest cycles fixing it.
- You wonder whether you should still optimize it, but ohh, wait,
  lets check IPR on any possible optimization, oh wait, if i need
  to start checking IPR, why the heck did i use this legacy codec.
- You try to figure how to make chips work whose native h261
  support if at all still existing still works. YOu wonder if/how
  the next generation of chips could do better on h261.

Toerless

---

From: Maik Merten <[email-masked]>
Date: Sun, 17 Nov 2013 20:40:29 +0100

>    have to invest cycles fixing it.

Looking around I still see H.261 implementations that are available and 
maintained. Their coding technology may still be "meh", and unless you 
want to resurrect a specific implementation designed for Windows 3.11 
video phones I doubt it's an insurmountable challenge to get something 
up and running. Granted, supporting (n+1) codecs is always more work 
than supporting (n) codecs, and you'd always want to support either 
H.264 or VP8.

>    to start checking IPR, why the heck did i use this legacy codec.

Well, the one thing that makes H.261 somewhat interesting is that most 
people seem to agree that one *can* implement it without running into 
IPR - you don't *have* to strap rockets onto that pig. During the whole 
IPR discussion I think everybody focused on what IPR may or may not 
apply to the respective formats as defined by their normative *de*coder 
specifications - I guess because it's up to the implementor to decide 
upon advanced technologies employed by the *en*coder.

>    the next generation of chips could do better on h261.

Would hardware support for H.261, if still existing, be actually 
relevant in a world where Skype is doing software encoding of H.264 on 
mobile devices?

Best regards,

Maik

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Nov 2013 09:00:31 +0100

On 11/16/2013 02:22 PM, Maik Merten wrote:
> I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg
> currently crashes when enabling a certain encoder feature which turns
> out to be very useful for other codecs ("trellis quantization" - which
> basically means that coefficients to be coded are selected with the
> encoding costs in mind) for the H.261 encoder. This is a rather new
> encoder feature which pays of very nicely for other formats and should
> be applicable for H.261 as well.

Just checking: Do you know the patent status of trellis quantization?

One issue this particular WG has with codecs is that in order to have a
non-IPR-encumbered spec, we need a non-IPR-encumbered encoder too -
unlike the situation for playback-only contexts, where a
non-IPR-encumbered decoder may be enough.

Thus, people who describe a particular quality level achievable with a
non-IPR-encumbered codec would seem to have to describe a
non-IPR-encumbered encoder that can achieve that quality level, too.

---

From: Maik Merten <[email-masked]>
Date: Tue, 19 Nov 2013 13:00:42 +0100

> non-IPR-encumbered encoder that can achieve that quality level, too.

I don't think discussing the IPR-situation of encoder optimizations was 
a topic yet, as implementers can choose what optimization features they 
enable in their encoder deployments. In the case of H.261, I think it is 
undisputed that an "IPR-free", spec-compliant encoder can be created. 
The samples I provided were encoded without modern encoder techniques 
(simply because ffmpeg used to crash when doing the advanced stuff, 
which now has been fixed), but clearly I'm not in a position to report 
on the general IPR situation of ffmpeg's H.261 encoder. Due to H.261's 
special IPR status it may indeed make sense to have both "IPR-safe" 
samples and "rockets attached" samples, once and if such performance 
boosters become available for H.261.

When assessing the performance that is achievable with a given format it 
is natural to try to create the best encodes possible, as has been done, 
e.g., with the VP8 vs. H.264 quality debate here on the list. For 
instance, H.264 was represented by x264 (most likely because of it is 
usually the best performing encoder) and not, e.g., by Cisco's encoder, 
albeit the latter is likely to become more relevant in the form of 
OpenH264. As far as I recall nobody called for a comparative IPR 
analysis regarding, e.g., those two encoder implementations. I assume 
this is because everyone assumes that each implementer will make its own 
risk-assessment regarding deployed encoding techniques. If this is so 
this should apply to H.261 as well.

Maik

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Nov 2013 14:26:19 +0100

On 11/19/2013 01:00 PM, Maik Merten wrote:
> I don't think discussing the IPR-situation of encoder optimizations 
> was a topic yet, as implementers can choose what optimization features 
> they enable in their encoder deployments. In the case of H.261, I 
> think it is undisputed that an "IPR-free", spec-compliant encoder can 
> be created. The samples I provided were encoded without modern encoder 
> techniques (simply because ffmpeg used to crash when doing the 
> advanced stuff, which now has been fixed), but clearly I'm not in a 
> position to report on the general IPR situation of ffmpeg's H.261 
> encoder. Due to H.261's special IPR status it may indeed make sense to 
> have both "IPR-safe" samples and "rockets attached" samples, once and 
> if such performance boosters become available for H.261.
>
> When assessing the performance that is achievable with a given format 
> it is natural to try to create the best encodes possible, as has been 
> done, e.g., with the VP8 vs. H.264 quality debate here on the list. 
> For instance, H.264 was represented by x264 (most likely because of it 
> is usually the best performing encoder) and not, e.g., by Cisco's 
> encoder, albeit the latter is likely to become more relevant in the 
> form of OpenH264. As far as I recall nobody called for a comparative 
> IPR analysis regarding, e.g., those two encoder implementations. I 
> assume this is because everyone assumes that each implementer will 
> make its own risk-assessment regarding deployed encoding techniques. 
> If this is so this should apply to H.261 as well.

In the case of VP8, the patent and copyright grants apply both to the 
decoder and the published reference encoder (which is also the one used 
for the tests).

Choosing x264 for the tests was easy; it's got a reputation for quality, 
and its reference source is available on the Internet, so everyone can 
agree what we're talking about when we say "x264, GIT tag xxxxx".

---

From: Maik Merten <[email-masked]>
Date: Tue, 19 Nov 2013 15:48:39 +0100

> agree what we're talking about when we say "x264, GIT tag xxxxx".

Yeah, just pointing out that IPR discussion wasn't centered on encoder 
implementations, as every specific implementation can open its own can 
of worms which may not strictly be related to the output format itself.

Maik