About h.264 encoding supported webcam for getusermedia.

[msu.koo]

Hi.

It looks like that currently chromium only supports raw frame capturing from the webcam. 

But I can see some webcams having H.264 capturing with FHD resolutions but only VGA for raw frames.

(Ex, Logitech C920 can capture H.264 with FHD 30fps, but only 800x480 30fps for YUV.)

Don't Chromium have any plans for supporting h.264 capturing?

Thanks!

[Peter Boström]

What about mjpg resolutions? For H264 capture to work well we'd have to decode and reencode it or we're stuck at the bitrate the camera is providing which is often way too high for the network.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8a9ef5b7-b3bf-459f-8d82-91ce8fc658d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[msu.koo]

MJPEG is fine. It says 30fps for FHD. but if webcam supports H.264 streaming, it might be used to send to the peer directly.

2015년 10월 1일 목요일 오후 3시 58분 50초 UTC+9, Peter Boström 님의 말:

[Alexandre GOUAILLARD]

ms (min-su?)

As peter said, if you use the camera encoder, you will not benefit from bandwidth adaptation, and other mechanisms in the webrtc stack used to improve the user experience. You will be stuck with whatever the camera is giving you. WebRTC stack is in many ways smarter when encoding the streams and will adapt the encoding parameters depending on available bandwidth, CPU consumptions, and multiple other parameters. Unless the CPU consumption is your main bottleneck it s very unlikely to be a good idea to send pre-encoded streams to webrtc.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b3dd3271-02d1-4735-a05d-eb5b22f4757c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Sergio Garcia Murillo]

+1

Also, this kind of encoders are typically optimized for streaming, not for real time, which render them almost useless for WebRTC.

BR
Sergio

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHgZEq717O_%3D9drouA-h0rDQXekZcZ4AgNFv0JpV9jtBjmGR6w%40mail.gmail.com.

[msu.koo]

Oh, I see. Thank you for your answers :)

2015년 10월 1일 목요일 오후 3시 29분 25초 UTC+9, msu.koo 님의 말:

[Devin Heitmueller]

On Thursday, October 1, 2015 at 4:44:07 AM UTC-4, Alexandre GOUAILLARD wrote:

ms (min-su?)

As peter said, if you use the camera encoder, you will not benefit from bandwidth adaptation, and other mechanisms in the webrtc stack used to improve the user experience. You will be stuck with whatever the camera is giving you.

Not necessarily.  Pretty much all hardware encoders let you set the peak and average bitrate at encoder startup, and most will let you change it on-the-fly as well.  I don't see how this is any different than the adaptation you are referring to.  We just need the hooks in webrtc to inform the encoder of the desired bitrate changes.

 

WebRTC stack is in many ways smarter when encoding the streams and will adapt the encoding parameters depending on available bandwidth, CPU consumptions, and multiple other parameters. Unless the CPU consumption is your main bottleneck it s very unlikely to be a good idea to send pre-encoded streams to webrtc.

I'm working on an embedded platform where this is precisely the case.  An SOC with a low performance ARM core with an onboard dedicated H.264 encoder which is tied directly to the image sensor.  I've got the flexibility to adjust all the encoder parameters, but it seems like the problem is the webrtc stack's expectation that the input source will always be either raw or MJPEG.  Because I have no direct access to the sensor data, I cannot simply create a raw capture source from the sensor and then my own encoder block in the pipeline.  I need to essentially combine the two.

I actually started my investigation with a C920.  Given how popular the camera is, I assumed webrtc would support it and then I could just model my approach after how that was done.  Needless to say I was disappointed to see that it's not supported, and if this thread is any indication it seems like none of the primary developers on the project care about this use case.

At this point I'm pursuing an approach which involves a dummy source which delivery empty I420 frames, combined with a new encoder block which ignores whatever it is given on its input and instead delivers NALs from the H.264 encoder block.  Of course this is a huge hack and it would be great to see proper support in the webrtc stack for sources that deliver NALs.

Devin

• 
  

[Peter Boström]

We care about local preview as well (and not all sources are even connected to encoders in the more general case). Assuming though that 150k is your transmit bitrate then your local camera preview will look really bad if you capture 720p as already-encoded H264.

That aside, if the input source has anything per frame (can be represented as a native handle/texture handle), you might be partially covered under work done in https://code.google.com/p/webrtc/issues/detail?id=4993. A webrtc::VideoEncoder instance is informed of bitrate changes through ::SetRates (same regardless of HW encoder or SW). The architecture assumes one capturer multiple encoders (or zero), but so long as you're using just one encoder instance and don't care about local preview/etc. you might be fine.

There's support for packetization of H264, we do this on Android in our encoder wrapper here.

Hope some of that helps,

- Peter

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5427dbe1-df67-46bf-b03d-151dc9b400bc%40googlegroups.com.