Re: [rtcweb] VP8 / H.264 conversion without transcoding

[Justin Uberti <[e-mail]>]

Even if we could do this conversion in real-time on a mobile device...
since you have both codecs present, why not just send the desired format in
the first place?


On Thu, Nov 21, 2013 at 11:25 AM, Gili <[e-mail]> wrote:

> Cullen,
>
> Thanks for the background information. I also remember them saying that we
> are only at the beginning of this process and that they expect more
> performance improvements in the upcoming months.
>
> It would be nice to gauge how far we are from being able to do this kind
> of conversion in real-time on a mobile device (I suspect very far, but it's
> worth asking). This has implications for P2P interoperability between VP8
> and H.264 peers without a middleman.
>
> Gili
>
>
> On 21/11/2013 10:46 AM, Cullen Jennings wrote:
>
>> It's a cool demo and I talked to the team that did it. This is only
>> possible because VP8 and H.264 are very similar codecs. The idea is to not
>> redo the motion vector computations or the DCT but just reuse the values
>> from one format in the other since they are the same. They hope that this
>> can provide reduce the CPU by 1/3 from a full decode then re-encode. It
>> also help reduce loss of quality for video. Other people have talked about
>> this idea over the years and many people think it can give a 2 to 3 speed
>> up so that seems consistent with their goals.
>>
>> It still requires the same bandwidth, and has similar other impacts. I
>> can not see any way that it would not require MPEG-LA IPR for 264.
>>
>>
>> On Nov 21, 2013, at 6:27 AM, Mo Zanaty (mzanaty) <[e-mail]>
>> wrote:
>>
>>  This probably refers to an intelligent transcoder versus a brute force
>>> transcoder. An intelligent transcoder harvests more data during decoding
>>> than just the raw output pixels, and uses this extra data to ease encoding.
>>> Data like block partitions, motion vectors, intra modes, quantization
>>> parameters, etc.
>>>
>>> This is common for common conversions, like MPEG2 to H.264. VP8 and
>>> H.264 are much closer formats, so this can significantly improve transcoder
>>> performance.
>>>
>>> However, this is strictly a performance optimization, with no impact on
>>> IPR or licensing issues.
>>>
>>> Mo
>>>
>>>
>>> On Nov 21, 2013, at 2:51 AM, "Bossiel" <[e-mail]> wrote:
>>>
>>> This could be true if they can also walk on water and change it into
>>> wine.
>>> To be serious, no it's not possible.
>>> Mamadou
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 21, 2013, at 3:13, Gili <[e-mail]> wrote:
>>>
>>>  Hi,
>>>>
>>>> I'm at the WebRTC World conference. If I understood correctly, Zingaya
>>>> just demoed what they claim is a VP8 to H.264 bridge that converts the
>>>> video without transcoding. My interpretation is that they convert the
>>>> surrounding packet format without re-encoding the actual video. Someone who
>>>> understands codec internals (I don't) might want to validate this claim,
>>>> because it could have a significant impact on the MTI debate.
>>>>
>>>> It sounds far fetched, but imagine the possibilities:
>>>>         • If the video is not being re-encoded, do H.264 royalties
>>>> apply?
>>>>         • If the conversion is really cheap, is it feasible to connect
>>>> a H.264 peer to a VP8 peer and have one of them convert in-line (no MCU)?
>>>> 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
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>