Re: [rtcweb] Sanjay Mishra's choices

[cowwoc <[e-mail]>]

On 25/12/2013 8:12 PM, Bjoern Hoehrmann wrote:
> * cowwoc wrote:
>> On 25/12/2013 8:13 AM, Bjoern Hoehrmann wrote:
>>> The answers are insisting that H.264 encoding and decoding are supported
>>> and there are a number of participants who have expressed this sentiment
>>> for various reasons. One being interoperability with legacy systems that
>>> support only H.264 without transcoding the video data. I don't think the
>>> choices here are surprising.
>> i think we need to clarify this point. As far as I know, no legacy
>> system supports WebRTC natively. This means that people will be sticking
>> some sort of WebRTC adapter in between native WebRTC peers and the
>> legacy devices. Under this scenario, won't you need to transform the
>> video in some way along the way?
> Yes, but that operation is more like changing the container format of a
> video stream from AVI to MKV or MP4. Changing the video codec requires
> much more processing. To get a feel for the numbers involved, I would
> recommend using `ffmpeg` like so
>
>    % ffmpeg -i input.avi -vcodec copy ... output.mkv
>
> for changing the container format and whatever is suitable to change the
> video codec. As an example, this is what I use to encode videos for my
> smartphone regardless of input format
>
>    % ffmpeg -n -i input -vf "scale=320:trunc(ow/a/2)*2"
>        -vcodec libx264 -vb 196000 -vprofile "baseline"
>        -acodec aac -ac 2 -ar 64000 -ab 64000
>        -movflags faststart -strict -2 output.mp4
>
> During transcoding, `ffmpeg` should print out how many frames per second
> it is currently transcoding. Between the two commands, the difference on
> my main desktop computer is a factor between 100x and 300x.

I should have been more specific.

I understand that swapping container formats is a lot cheaper, but most 
legacy systems I've seen (e.g. video broadcast systems, conference 
bridges) transcode in order to expose a video stream at multiple 
resolutions. This is a far more expensive operation, and one which they 
already do even though H.264 is available on both ends. Is this a common 
occurrence?

Would anyone care to guess as to what percentage of legacy systems would 
actually use H.264 end-to-end without transcoding if H.264 were selected 
as MTI?

Thanks,
Gili