Advice received is that the packetization-format says what you can receive, and that almost all serious systems today (including Firefox) support mode 1. Priority of supporting mode 0 is thus not very high.

Some Traditional SIP/H.323 endpoints do not support packetization-mode 1. so communication b/w WebRTC and Traditional endpoints will become easier and efficient if packetization-mode 0 is enabled.  

WebRTC in Chrome doesn't support H.323 anyway. I guess the gateway can cope, for now.

The Media is RTP, so if packetization mode 0 is enabled a simple media-bypass will do, else it requires media transcoding.

hta@, can you own this one?

I'll have to ask *bos for help in finding the OpenH264 switch to choose packetization mode (if it exists). Otherwise yes.

https://github.com/cisco/openh264/blob/master/test/api/BaseEncoderTest.cpp
from this example. setting "uiMaxNalSize" should help.

and in
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/rtp_rtcp/source/rtp_format_h264.cc

RtpPacketizerH264::GeneratePackets

we should expose a flag so that we don't call PacketizeStapA.

i have further studied into the API.

for the base layer we also have to set the following.
considering
SEncParamExt param;
and 
SSpatialLayerConfig* layer = &param.sSpatialLayers[0];
we have to set.
layer->sSliceArgument.uiSliceMode = SM_SIZELIMITED_SLICE;
layer->sSliceArgument.uiSliceSizeConstraint = param.uiMaxNalSize;

Trying to follow this advice, I find:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/openh264/src/codec/api/svc/codec_app_def.h&q=SM_SINGLE_SLICE&sq=package:chromium&type=cs&l=271

that SM_SIZELIMITED_SLICE does not seem to exist. Is there another name, or do I need to update the OpenH264 version?

Hi hta,

please see this url https://github.com/cisco/openh264/blob/master/codec/api/svc/codec_app_def.h

OK, I see this was introduced at https://github.com/cisco/openh264/commit/33c378f7b791310e4cb64b53e2bb8f3f3bded105 where version was changed from 1.5 to 1.6.

I will add a note to our code of the new value for 1.6.

Any update on this issue?

thanks

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/ceecea4559894d680daa689eef3677a612c9e7ec

commit ceecea4559894d680daa689eef3677a612c9e7ec
Author: magjed <magjed@webrtc.org>
Date: Mon Nov 28 15:20:21 2016

Pass selected cricket::VideoCodec down to internal H264 encoder

Pass the selected cricket::VideoCodec to H264EncoderImpl::H264EncoderImpl. The cricket::VideoCodec contains relevant information for H264 about selected profile and packetization mode.

BUG= chromium:600254 , webrtc:6402 ,  webrtc:6337 

Review-Url: https://codereview.webrtc.org/2474993002
Cr-Commit-Position: refs/heads/master@{#15270}

[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/media/engine/internalencoderfactory.cc
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/modules/BUILD.gn
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/modules/video_coding/DEPS
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/modules/video_coding/codecs/h264/h264.cc
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/modules/video_coding/codecs/h264/include/h264.h
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/modules/video_coding/codecs/test/videoprocessor_integrationtest.cc
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/video/BUILD.gn
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/video/end_to_end_tests.cc
[modify] https://crrev.com/ceecea4559894d680daa689eef3677a612c9e7ec/webrtc/video/video_quality_test.cc

Any update for this ussue?

When the fix will be taken into account?

Thanks

The work on setting the packetization mode is done, but the work on negotiating it in SDP isn't, I think.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/3409cfa378e75c0c08d900e0848147929249a62b

commit 3409cfa378e75c0c08d900e0848147929249a62b
Author: Taylor Brandstetter <deadbeef@webrtc.org>
Date: Wed May 23 17:18:14 2018

Start supporting H264 packetization mode 0.

The work was already done to support it, but it wasn't being negotiated
in SDP.

This means we'll now see 8 H264 payload types instead of 4; one for each
combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
This could be problematic in the future, since we're starting to run
out of dynamic payload types (using 25 of 32).

Bug:  chromium:600254 
Change-Id: Ief2340db77c796f12980445b547b87e939170fae
Reviewed-on: https://webrtc-review.googlesource.com/77264
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23372}
[modify] https://crrev.com/3409cfa378e75c0c08d900e0848147929249a62b/modules/video_coding/codecs/h264/h264.cc

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/223cc4b0e7d726fecb8edaafd6e5894791755d8a

commit 223cc4b0e7d726fecb8edaafd6e5894791755d8a
Author: Taylor Brandstetter <deadbeef@webrtc.org>
Date: Wed May 23 18:17:25 2018

Revert "Start supporting H264 packetization mode 0."

This reverts commit 3409cfa378e75c0c08d900e0848147929249a62b.

Reason for revert: Broke WebRtcBrowserTest.RunsAudioVideoWebRTCCallInTwoTabsH264 on Windows 7/10 bots

Original change's description:
> Start supporting H264 packetization mode 0.
> 
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
> 
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
> 
> Bug:  chromium:600254 
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}

TBR=deadbeef@webrtc.org,magjed@webrtc.org,sprang@webrtc.org

Change-Id: I2f2a2b4ca20ba883764cd5265911e1453d3df66e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  chromium:600254 
Reviewed-on: https://webrtc-review.googlesource.com/78398
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23374}
[modify] https://crrev.com/223cc4b0e7d726fecb8edaafd6e5894791755d8a/modules/video_coding/codecs/h264/h264.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6705ca906863c6f5f96e3cf8f8cf4a381ba491b

commit a6705ca906863c6f5f96e3cf8f8cf4a381ba491b
Author: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Mon May 28 07:54:11 2018

Roll src/third_party/webrtc/ 547e3169d..d7a076cc8 (39 commits)

https://webrtc.googlesource.com/src.git/+log/547e3169d9e0..d7a076cc8e3f

$ git log 547e3169d..d7a076cc8 --date=short --no-merges --format='%ad %ae %s'

Created with:
  roll-dep src/third_party/webrtc
BUG= chromium:846615 ,chromium:None,chromium:843477,chromium:None,chromium:None,chromium:None,chromium:None,chromium:749455,chromium:600254,chromium:600254,chromium:None,chromium:776681,chromium:None


The AutoRoll server is located here: https://webrtc-chromium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: Ib82ca259df1fa58c02182b7bcf69740af5b766bc
Reviewed-on: https://chromium-review.googlesource.com/1074448
Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#562203}
[modify] https://crrev.com/a6705ca906863c6f5f96e3cf8f8cf4a381ba491b/DEPS

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/28deb90728c06a35d8847d2aeda2fc1aee105c5e

commit 28deb90728c06a35d8847d2aeda2fc1aee105c5e
Author: Taylor Brandstetter <deadbeef@webrtc.org>
Date: Fri Jun 01 18:03:06 2018

Reland "Start supporting H264 packetization mode 0."

This is a reland of 3409cfa378e75c0c08d900e0848147929249a62b

Needed to change RtpVideoStreamReceiver to stop deregistering a payload
type if two payload types refer to the same codec (which now happens,
with the packetization mode 0/1 payload types). It's not clear why this
was being done in the first place.

Original change's description:
> Start supporting H264 packetization mode 0.
>
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
>
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
>
> Bug:  chromium:600254 
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}

Bug:  chromium:600254 
Change-Id: Ice1acc05acd1543d9b46e918de2bba0694d86259
Reviewed-on: https://webrtc-review.googlesource.com/78399
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23494}
[modify] https://crrev.com/28deb90728c06a35d8847d2aeda2fc1aee105c5e/modules/rtp_rtcp/include/rtp_payload_registry.h
[modify] https://crrev.com/28deb90728c06a35d8847d2aeda2fc1aee105c5e/modules/rtp_rtcp/source/rtp_payload_registry.cc
[modify] https://crrev.com/28deb90728c06a35d8847d2aeda2fc1aee105c5e/modules/video_coding/codecs/h264/h264.cc
[modify] https://crrev.com/28deb90728c06a35d8847d2aeda2fc1aee105c5e/video/rtp_video_stream_receiver.cc
[modify] https://crrev.com/28deb90728c06a35d8847d2aeda2fc1aee105c5e/video/rtp_video_stream_receiver.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc774bff4774a7c7cdf0d31fb02c82ba23562ff3

commit dc774bff4774a7c7cdf0d31fb02c82ba23562ff3
Author: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Fri Jun 01 21:22:08 2018

Roll src/third_party/webrtc 56df67b..28deb90 (2 commits)

https://webrtc.googlesource.com/src.git/+log/56df67b..28deb90


git log 56df67b..28deb90 --date=short --no-merges --format='%ad %ae %s'
2018-06-01 deadbeef@webrtc.org Reland "Start supporting H264 packetization mode 0."
2018-06-01 buildbot@webrtc.org Roll chromium_revision 29e2805f88..3a0333ff4e (563524:563625)


Created with:
  gclient setdep -r src/third_party/webrtc@28deb90

The AutoRoll server is located here: https://webrtc-chromium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng

BUG= chromium:600254 ,chromium:None
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I09cea8554c796af845d5a4cd9713510e1f50bb02
Reviewed-on: https://chromium-review.googlesource.com/1082959
Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#563800}
[modify] https://crrev.com/dc774bff4774a7c7cdf0d31fb02c82ba23562ff3/DEPS

Seems to be working as expected in Canary.

 Issue webrtc:9394  has been merged into this issue.

Has this been released to the beta build yet? The bug ( http://crbug.com/841444 ) I'm trying to verify is blocked by this one. I just tried it with 68.0.3440.42 (Official Build) beta (64-bit) and for me it is still a problem.

It looks like this fix is in M69. So canary/dev only as of right now.

I did try the canary build and it works for me. I guess my bug was a duplicate of this one.

 Issue 841444  has been merged into this issue.