Re: [rtcweb] Comment on Straw Poll replies

[Stephan Wenger <[e-mail]>]

Hi,

it¹s somewhat funny that, on an IETF RAI area mailing list, people appear
to forget about the arguably prime source of delay in any RTP receiver,
including an RTP receiver in a transcoding box: the jitter buffer.  My
understanding is that most folks who run video over RTP over the Internet
(in contrast to a private IP network) use jitter buffers of hundred
milliseconds plus in size.

Most practical video communication system over the Internet involves forms
of retransmission or forward error correction, or both.  Those add delay
in case they are invoked to recreate packets lost in transmission, in the
transcoder and separately also in the final receiver.

As for the delay introduced by the transcoding engine alone, let me note
that the single or two frame delay commonly attributed to transcoding is
realistic only for straightforward PPP type coding.  My understanding is
that VP8, in its default encoder settings, uses much more complex GOP
structures for error resilience and coding efficiency reasons.  H.264
constrained baseline certainly also allows that (it¹s even more flexible
in that regard).  Complex GOP structures are anywhere between helpful to
essential (depending on your viewpoint) for error resilience.  Complex GOP
structures do not necessarily increase the latency in an overall system
design in the absence of errors (they are not based on MPEG-2 B frame type
of thinking), but when error correction becomes necessary, a transcoder
would need to emulate receiver behavior, and that certainly would induce
delay of several hundred milliseconds which would not be observable in a
transcoder-free operation (under the assumption that the end system
chooses to display slightly distorted video) but will be observable and
unavoidable in the transcoder-based design.

I¹m very familiar with H.264 baseline, and somewhat familiar with the VP8
syntax.  Based on this knowledge, I doubt that one can transcode between
the two formats in the compressed domain, i.e. without full reconstructed
to the sample level.  I am absolutely convinced that compressed domain
transcoding in the direction from H.264 to VP8 is impossible, due to the
larger feature set of H.264.  ³Impossible² means here that I could create
an H.264 compliant bitstream that cannot be transcoded into VP8 in the
compressed domain, because there is no syntax equivalent for an H.264 tool
in VP8.  For example, H.264 constrained baseline supports more than three
reference pictures, whereas VP8 uses no more than three (last frame,
golden frame, and alternate reference frame).  It wouldn¹t take me long to
extend this list to several pages.  I¹m also fairly certain that people
more familiar with the VP8 syntax could similarly identify VP8 features
that have no direct counterpart in H.264.  Insofar, I take any statement
about ²availability² of compressed domain transcoding between the two
coding schemes with a large grain of salt.  It may be possible (I don¹t
know) to transcode in the compressed domain between H.264/VP8 bitstreams
when the respective input bitstream is specifically tailored for that
purpose, and perhaps that is what people have in mind.

Regards,
Stephan


On 1/14/14, 2:22, "DRAGE, Keith (Keith)" <[e-mail]>
wrote:

>In those terms, I do not believe that is what they were showing, at least
>according to the reports I have seen.
>
>Further, apart from any processing power, the critical issue is the delay
>involved in any conversion, and I have no figures for that from this
>demonstration, and I suspect you do not either. Given that you must
>receive frames to do the conversion, my belief is that we will still be
>talking both decode and encode delay at the conversion point of the order
>of 60 - 70 ms, whatever mechanism is used. That is a significant take
>from the limits specified in ITU Recommendation G.114.
>
>Regards
>
>Keith
>
>> -----Original Message-----
>> From: Silvia Pfeiffer [mailto:[e-mail]]
>> Sent: 14 January 2014 01:17
>> To: DRAGE, Keith (Keith)
>> Cc: cowwoc; [e-mail]
>> Subject: Re: [rtcweb] Comment on Straw Poll replies
>> 
>> For all those concerns, please remember that Zingaya
>> showcased a H.264 and VP8 real-time video conversion without
>> transcoding. That to me shows that we may all be
>> over-estimating the complexity involved in transcoding
>> between H.264 and VP8.
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Tue, Jan 14, 2014 at 1:47 AM, DRAGE, Keith (Keith)
>> <[e-mail]> wrote:
>> > Legacy interoperability is important to some of us.
>> >
>> > It is not about preserving our existing equipment.
>> >
>> > It is about the fact the communication involves two or more
>> parties, 
>> > and we want to enable video communication between RTCWEB
>> user and the 
>> > rest of the entities in the world that are capable of
>> video, without 
>> > having to resort to transcoding video on all calls. Yes
>> transcoding is 
>> > possible, but it has a cost that someone will have to pay
>> for, and it 
>> > introduces delay, which can be catered for, but removes the
>> > possibility of someone else in the call path using that
>> delay portion.
>> >
>> > Currently there are a considerable number more of those users using
>> > legacy systems than there are using RTCWEB.
>> >
>> > Keith
>> >
>> > ________________________________
>> > From: rtcweb [mailto:[e-mail]] On Behalf Of cowwoc
>> > Sent: 10 January 2014 16:39
>> > To: [e-mail]
>> > Subject: Re: [rtcweb] Comment on Straw Poll replies
>> >
>> > On 10/01/2014 9:54 AM, [e-mail] wrote:
>> >
>> >
>> > Can I ask why you even bother with WebRTC, if you want to restrict
>> > WebRTC to interoperability with old systems only and
>> therefore to old features only?
>> > I'd like to suggest that such replies should be disregarded because
>> > they look backwards and not forwards.
>> >
>> > I don't think that disregarding replies is a constructive
>> way forward.
>> >
>> > However if you want to go that way, and if you want to get
>> rid of old 
>> > technologies, let's start by disregarding replies from
>> those who could 
>> > live with a WebRTC technology that would specify H.261 as
>> only  MTI codec.
>> > Given your concerns about "old" systems and "od" features, I'm a
>> > little bit surprised that your are part of them.
>> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg10798.html
>> > (note that there is G.711 for audio but NOT as ONLY MTI codec)
>> >
>> >
>> > This is a fallacy. No one is arguing that you should be stuck with
>> > using
>> > *just* H.261. What we are saying is that: if H.264 or VP8 are
>> > available on both end-points, great. If not, you can either:
>> >
>> > Use H.261, or
>> > Transcode, or
>> > Drop Video
>> >
>> > By eliminating H.261 as MTI, you lose the first option and
>> are forced 
>> > to either transcode or drop video. The cost to supporting
>> H.261 is as 
>> > simple as compiling https://github.com/Vproject/p64 and
>> popping it on 
>> > your device. You don't need hardware support because it's
>> so computationally cheap.
>> >
>> > And finally, we're not objecting to the use of H.264, per se, but
>> > rather to the fact that the majority of people who vote for it and
>> > against everything else use "legacy interoperability" as argument.
>> >
>> > WebRTC is a *new* technology. If all we wanted to do was to support
>> > *existing* devices then we would use *existing*
>> technologies. For that
>> > reason, I don't think maintaining backwards compatibility
>> is important 
>> > when breaking it has a noticeable benefit (and in this
>> case, I believe it does).
>> >
>> > Alternatively, please convince MPEG-LA to make H.264
>> available royalty-free.
>> >
>> > Gili
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> 
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb