RTP Packetization of H264 video

[Harshitha H.S]

Hi,

I see that the code inside H264 folder(rtp_rtcp module) is available for H264 RTP packetization but i also see that, this code is not being connected to any other modules or video engine. The same applies for parsing the RTP header at the receiver end too.

-> Is there a seperate branch/code which i should look at for H264 RTP packetization and its connectivity with other modules.. ofcourse within webrtc trunk?

-> If not, is there any read through which explains me on what should be done to use the H264 RTP packetization code with the existing webrtc video engine?

-> I didnot see the code for H264_receiver. Any details on this would be helpful 

Thanks in Advance!!

Regards,

Harshita

[Niklas Enbom]

In short, H.264 is not supported.

Niklas

[samba]

Hi, Harsh

Did you find the way to register the external codec for webrtc?

I face the same problem as you. VP8 is not enough for me at this time as for its poor performance on android platform.

在 2012年3月27日星期二UTC+8下午5时41分28秒，Harsh.HS写道：

[Harshitha H.S]

Hi Samba,

Yes. I did find a way to register to an external codec. 

http://www.webrtc.org/reference/webrtc-internals/vieexternalcodec  

- Here it is - read through for registering the external send and receive codec.

Registering the external codec for self video playback(self video on PIP) , you may have to tweet/modify the "vie_capturer.cc" to register the external codec for local playback too. Interface for this(self video playback using external codec) is not available in webrtc.

Regards,

Harshitha

--
 
 
 

[Liu Robin]

Thank you, Harshitha .

But moreover it seems that we should modify the rtp_rtcp module to packetize another codec h.264 for example, isn't it?

How did you fix it?

Regards 

2012/8/6 Harshitha H.S <hars...@gmail.com>

--
 
 
 

[Harshitha H.S]

Yes!. rtp_rtcp module has to be modified to include the external codec<H264>  support.

RTP packetization/RTP parser - has to be added.

-Harshitha

--
 
 
 

[Liu Robin]

Any detailed info? please

Thank you

2012/8/6 Harshitha H.S <hars...@gmail.com>

--
 
 
 

[med...@gmail.com]

Hi Nick,

You can check the implementation of h264 in our MCU:

http://sourceforge.net/p/mcumediaserver/code/668/tree/trunk/mcu/src/h264/

Best regards
Sergio

El 19/12/2012 21:53, Nicholas Padilla escribió:

Hello Harshitha,

I was hoping you might be able to provide the updated code for the h.264 support.  Any code examples, even if they are not fully functional, would be a huge help!  

Thanks!

Nick

--
 
 
 

[SRIRAM YARLAGADDA]

Hi

can any one say the code modification to get h264 video stream.

Regards,

sriram

[SProgrammer]

http://code.google.com/p/webrtc4all/

- H.264 is there, but is it original WebRTC? or Fake / Spammer of WebRTC framework?

[Alexandre GOUAILLARD]

@sprogrammer, doubango are spammers and fakers? interesting claim. 

for the rest, wrong again …

doubango solutions is made of many parts.

webrtc4all is a collection of plugins that extend the browsers API but do *NOT ADD* capacity. if the browser does not support h.264 it will not support it after you install webrtc4all. webrtc4all supports the "bowser" experiment from ericson which was one of the earliest webrtc implementation and which was supporting h.264. if you look at the source code, you will se a switch which check the browser and the implementation.

they have a "gateway" product webrtc2sip which handles transcoding to/from h.264/263/261, but they do not have a plugin or any mechanism which would add h.264 encoding or decoding capacity to browsers. (mamadou, feel free to correct me here if any of my statement regarding your products is wrong)

@SRIRAM:

if you want it in a browser, you will have to provide the functionality as a plug in.

The other way for you to provide this capacity to your customers is a native app or desktop client.

grab the original code, look into the video engine and add capacity for a new codec. It has been reported has being more challenging for video than for audio where a switch is already in place.

You might alternatively start from the mozilla code, which is based on a cisco SIP soft phone, and is very likely to have 264 capacity already.

Be aware that adding 264 capacity might expose you to royalties claim from MPEG-LA.

On Tue, Dec 24, 2013 at 7:49 PM, SProgrammer <sha...@companysocia.com> wrote:

http://code.google.com/p/webrtc4all/

- H.264 is there, but is it original WebRTC? or Fake / Spammer of WebRTC framework?

--
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Shamun Toha Md]

Thank you. 

# Here few words in terms of (fake), addressed to webRTC4all fans not for webRTC hero's

- Try it with all the browsers specially Internet explorer, Safari it does not work, it crash instantly over and over, and simply waste of time (all the josh disappears after trying to use it)

- webRTC4all to me like troll, saying lot of words but doing nothing at all (tests does not work and broken, old, no new releases, like getting dead)

# H.264 - is the BEST of all for crisp and clear image

- use VLC (they have a browser plugin you have to change in the source), Mplayer, FFmpeg, Gstreamer to get all the encoder / decoder (those are the toys for big boys http://www.collabora.com/ )

- For license agreement contact MPEG-LA, they will have reports from you its very simple nothing to get worried about, but its also free to use for a certain amount of users

- be aware that H.264 is best codec out of all, which still VP8 is trying to be knock out

- VP8 is not crisp and clear for quality of image (it has acceptable level but there is more picture quality level required in many cases), 

when you have camera with higher megapixels + highest frame per seconds + zero latency requirement + lot of motions 

and you need to keep best quality without having the pictures with big pixelation blocks, 

then still what H.264 algorithm can do is priceless compared to VP8. 

http://www.streamingmedia.com/articles/editorial/featured-articles/first-look-h.264-and-vp8-compared-67266.aspx

reg

/sham

[Alexandre GOUAILLARD]

hi sham,

maybe you know better than all the experts in the corresponding IETF group working on deciding the MTI codec for RTCWEB:

after several round of expertise, counter expertise, tuning, debates, with all the major players involved, they all concluded that VP8 encoded and H.264 encoded video, all other things being equal, were of almost equal quality, close enough for the decision not to be based on quality.

If you want to make your OWN opinion, instead of picking up a random post written 3 years ago(!!), the tests used by the IETF members are open, including input data and parameters, for all to reproduce and make their own conclusion, like "big boys" do. The results have been proposed first by google (a VP8 proponent) and double checked intensively by ericson (a H.264 proponent) and others in the past weeks/months.

You can find the test code and the parameters on the public thread:

[rtcweb] Comments on H.264 and VP8 performance comparisons

and more comments on the results here:

[rtcweb] More H.264 vs VP8 tests

Rule of the thumb: do not believe other people results. If the entire process, including parameters, to reproduce the results is not provided, then it's marketing. If you cannot reproduce  yourself, don't believe.

But again, since you seem to know better, I suggest you provide the test process you followed to reach your own conclusion, put it open for other to reproduce, and join the debate. 

The corresponding mailing list is there:

https://www.ietf.org/mailman/listinfo/rtcweb

alex.

[Mamadou]

@SProgrammer

My name is Mamadou DIOP and I'm working for Doubango Telecom, the company behind webrtc4all. I confirm that it' fake and we're spammers.

We're not trying to force you (or any other company) to use our products. Please don't use  our product.

Merry christmas and happy new year.

[Mamadou]

@SProgrammer (or @Shamun)

As it looks like you hate GPL (https://code.google.com/p/webrtc2sip/issues/detail?id=101#c6) I also confirm that webrtc4All is GPL. So, don't waste your (and our) time reporting issues in our (Doubango) dev-group

On Tuesday, December 24, 2013 12:49:25 PM UTC+1, SProgrammer wrote:

[Mamadou]

@Alexandre

webrtc4all is based on Doubango code and include many H.264 implementations: Intel Quick Sync, NVIDIA Cuda, FFmpeg+x264 and Microsoft MF (Win8 only).

The h264 implementations are distributed as plugins. Same as Boghe: https://code.google.com/p/boghe/wiki/ExtraFeatures

[Alexandre GOUAILLARD]

thanks mamadou for the precision, I stand corrected.

[SProgrammer]

Dear Alex,

Thank you very much. Will do and thank you for your feedback, appreciating.

I have been since day 1 testing VP8 vs H.264. All developers + marketing people proved that VP8 is perfect (like pushed so much so that all say yes its accurate, by ignoring the reality and stop improving it more)

 but the truth is that VP8 is not H.264 comparable yet, algorithm of H.264 is much much advanced and rich for crisp and crystal clear image to keep while doing zero latency, lipsync, zero level of big block pixelation.

- I have lot of video clips with random motions, scenarios and different 3D rendered highest frames oriented video clips. Which was prepared to test VP8 and H.264 video codec.

H.264 algorithm is mind blowing each and every pixel + frames are taken care by this algorithm

VP8 algorithm is mind-satisfaction (Saying your mind, ok who cares so much?)

- Enterprisy: Sony PCS XG (the god father of this business, quality guru), Polycom, LifeSize (tested), they use H.264 video codec since we all were child on this subject.

To them, VP8 is just considered as give them a chance poor little encoder.

- VP8 speed and H.264 speed of encoding i have doubt since day 1. 

When you do lot of editing like real-time chroma-key, input-selector (multi-input sources), video editing on the fly, motion/face detection etc involved, with VP8 encoder, it cant handle it + system get frozen or cause to crash, even you give all the threads to use by VP8

where as H.264 never does that even extreme load is given

In my experience VP8 is OK, not Perfect as H.264 (e.g: hey dude we are ok, to be get used as FREE, and who care so much! we are doing little mistakes in our encoder for quality issues, which we ignore, that's fine for all of us.... ).

Many thanks

Best regards

/Sham

P.S: Do not get me wrong, rude, just sharing experience open/friendly as always (we all love WebRTC, VP8, and our community)

[SProgrammer]

Hello Mamadou DIOP,

Thank you, Merry Christmas and wish you very very happy new year.

- WebRTC4all the way it was introduced is excellent, mind blowing, very catchy. But when you start to test it, use it, or contribute on it, you feel doubt on it because the first step is it does not work (wrong impression for the starters)

- Thanks for the confirmation. Confusion started because says officially in there page:

Source code freely provided to you by Doubango Telecom ® under GPL v3 terms.

• Compatibility
• Codecs
• Javacript API
• Sample Code
• Technical help

webrtc4all is a WebRTC extension for Safari, Firefox, Opera and IE9+. This extension is part of sipML5 solution and implements Javascript PeerConnection API as defined in draft-uberti-rtcweb-jsep-02. 

If you clearly read the line "Safari, IE9+" and then go for testing, none of them works. Gives the impression that its fake/lie. then you stop moving forward. 

- We love your framework, but release something in official sites, which works for the community please, we can put also some cocktail frameworks too and make it GPL using VLC, Gstreamer, but what is the point if it does not do what it says it does?

Thank you so much.

Best regards

/Sham

[YARLAGADDA SRIRAM]

@Alexandre GOUAILLARD:

I had already download the source and build successfully. In that code i want to add H.264 codec instead of vp8.

can you help me to modify the code.

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/tWxcdJCk49E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Harald Alvestrand]

Sham,

you quote a lot of issues that are implementation specific (like crashing), yet you are not saying what your implementation is. Which one is it that you are referring to?

Also, you say "When you do lot of editing like real-time chroma-key, input-selector (multi-input sources), video editing on the fly, motion/face detection etc involved, with VP8 encoder, it cant handle it + system get frozen or cause to crash, even you give all the threads to use by VP8" - I assume that you're using the reference encoder, yet, again, you don't say what the software context is. The VP8 encoder cannot do these things by itself, so it's fair to assume that it's embedded in some product.

If you know that some issues are with the VP8 encoder specifically - have you filed bugs for these issues? Do you have working reproductions of these bugs?

I love to have more information about the performance of my codecs. I hate to not be able to reproduce issues encountered.

[SProgrammer]

Hello Harald Alvestrand,

Regarding VP8 vs H.264 testing the best test would be using Gstreamer (optionally VLC, if doubt with Gstreamer)

both encoders where used to test same cases:

- capture 60 frames per second 

   + 1080p or 720p resolution per frame from Sony camera's (enterprise cameras, higher frame + higher resolutions using HDMI/SDI interface + 8-bit to 10-bit color space)

- input source->camera: 

    + real time capture

    + change the green chroma key with black key 

    + resize / crop / effects apply 

    as input source 1 ( https://developer.gnome.org/gst-plugins-libs/unstable/gstreamer-plugins-input-selector.html )

- input source->document_laptop_over_vga_capture: 

    + real time capture 

    + resize/crop/effects apply as input source 2 ( https://developer.gnome.org/gst-plugins-libs/unstable/gstreamer-plugins-input-selector.html )

- input source->movie_clip_capture: 

    + real time capture 

    + resize/crop/effects apply as input source 3 ( https://developer.gnome.org/gst-plugins-libs/unstable/gstreamer-plugins-input-selector.html )

- input source->RTP_or_RTSP_stream_ptop_for_mcu_peer1andN: 

    + real time capture 

    + resize/crop/effects apply as input source 3 ( https://developer.gnome.org/gst-plugins-libs/unstable/gstreamer-plugins-input-selector.html )

# Now those 4 input sources are real-time running live (no pause, no stream break, they are live stream, cant be stopped anytime requires to seamlessly render to avoid any kind of latency/delay in user Life Size experience)

- from those input source, we used encoder VP8 (danger) or H.264 (safe) or H.263 (to be 100% success) encoder

- now on the fly we switch channel input source from 1, 2, 3 repeat 3, 2, 1, repeat 2, 1, 3 repeat, 3, 1, 2

- and stream it as RTP stream (optionally SDP)

* -  with VP8 it is strange with performance issue / frozen issues/ if the VP8 encoder is used there is a huge lipsync/latency/delay

* + with H.264 and H.263 there is no issue simply works

Note: Now, those tests were closed source for the company i worked before to prepare the whole demo version. 

(i wont be able to share the code references but above description draws it clearly what exactly i was trying to do, which failed ) 

we stopped the project because of VP8 encoder was main planning to use, but it was crashing and freezing the input source to capture smoothly and on the fly switch it , keep the live stream alive, 

where H.264 worked perfectly, but company cant afford H.264, so that project was dropped, you can simulate it using Gstreamer and VP8 and x264enc pipes by mixing the input-selector adapter)

Thank you so much. Hope it helps. 

Best regards

/Sham