New issue
Advanced search Search tips

Issue 843593 link

Starred by 40 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Negotiated bandwith for screen share video is not honored

Reported by martin71...@googlemail.com, May 16 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Create a webrtc session with video capture between chrome and 3rd party MCU
2. Observe bandwitdh via wireshark.

What is the expected behavior?
Chrome should honor negotiated bandwidth limitation AS=300.

What went wrong?
It seems the negotiated bandwitdh limitation is only(?) honored if transport-cc is negotiated. If only google REMB is negotiated, the created VP8 stream does not care for the bandwidth limit.

Did this work before? N/A 

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? N/A

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

Contents of chrome://gpu: 

Graphics Feature Status
Canvas: Hardware accelerated
CheckerImaging: Disabled
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Hardware accelerated
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_accelerated_vpx_decode
disable_delayed_copy_nv12
disable_direct_composition
disable_discard_framebuffer
disable_dxgi_zero_copy_video
disable_framebuffer_cmaa
exit_on_context_lost
force_cube_complete
scalarize_vec_and_mat_constructor_args
texsubimage_faster_than_teximage
Problems Detected
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
TexSubImage is faster for full uploads on ANGLE
Applied Workarounds: texsubimage_faster_than_teximage
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
ANGLE crash on glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
Direct composition flashes black initially on Win <10: 588588
Applied Workarounds: disable_direct_composition
Zero copy DXGI video hangs on shutdown on Win < 8.1: 621190
Applied Workarounds: disable_dxgi_zero_copy_video
Use GL_INTEL_framebuffer_CMAA on ChromeOS: 535198
Applied Workarounds: disable_framebuffer_cmaa
Zero-copy NV12 video displays incorrect colors on NVIDIA drivers.: 635319
Applied Workarounds: disable_dxgi_zero_copy_video
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
VPx decoding isn't supported well before Windows 10 creators update.: 616318, 667532
Applied Workarounds: disable_accelerated_vpx_decode
Delayed copy NV12 displays incorrect colors on NVIDIA drivers.: 728670
Applied Workarounds: disable_delayed_copy_nv12
Don't expose disjoint_timer_query extensions to WebGL: 808744
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Checker-imaging has been disabled via finch trial or the command line.
Disabled Features: checker_imaging
Version Information
Data exported	2018-05-16T15:43:05.430Z
Chrome version	Chrome/66.0.3359.181
Operating system	Windows NT 6.1.7601 SP1
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/a10b9cedb40738cb152f8148ddab4891df876959/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/a10b9cedb40738cb152f8148ddab4891df876959/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	22c768fbda54
2D graphics backend	Skia/66 773868fdade5f9f0e7697e6d09c9bd80aaa9b402-
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	243
In-process GPU	false
Passthrough Command Decoder	false
Direct Composition	false
Supports overlays	false
Sandboxed	true
GPU0	VENDOR = 0x10de, DEVICE= 0x1381 *ACTIVE*
Optimus	false
Optimus	false
AMD switchable	false
Desktop compositing	Aero Glass
Diagonal Monitor Size of \\.\DISPLAY2	22.0"
Diagonal Monitor Size of \\.\DISPLAY1	25.5"
Driver vendor	NVIDIA
Driver version	9.18.13.4725
Driver date	1-9-2015
Pixel shader version	5.0
Vertex shader version	5.0
Max. MSAA samples	8
Machine model name	
Machine model version	
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (NVIDIA GeForce GTX 750 Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 2.1.0.22c768fbda54)
GL_EXTENSIONS	GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions	EXT_disjoint_timer_query EXT_disjoint_timer_query_webgl2
Window system binding vendor	Google Inc. (adapter LUID: 00000000000337be)
Window system binding version	1.4 (ANGLE 2.1.0.22c768fbda54)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	Software only
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	GPU_READ, SCANOUT
RGBA_8888	GPU_READ, SCANOUT
BGRX_8888	Software only
BGRX_1010102	Software only
RGBX_1010102	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Display(s) Information
Info	Display[2528732444] bounds=0,0 1920x1080, workarea=0,0 1920x1040, scale=1, external
Color space information	{primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Bits per color component	8
Bits per pixel	24
Info	Display[2779098405] bounds=1920,0 1680x1050, workarea=1920,0 1680x1050, scale=1, external
Color space information	{primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Bits per color component	8
Bits per pixel	24
Video Acceleration Information
Decode h264 baseline	up to 1920x1088 pixels
Decode h264 main	up to 1920x1088 pixels
Decode h264 high	up to 1920x1088 pixels
Diagnostics
0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	11
dwHeight	1080
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1920
iAdapter	0
lDriverSize	17250776
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	GeForce GTX 750
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Integrated RAMDAC
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	
szDescription	NVIDIA GeForce GTX 750
szDeviceId	0x1381
szDeviceIdentifier	{D7B71E3E-50C1-11CF-9D65-23161FC2C435}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	4025 MB
szDisplayMemoryLocalized	4025 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (60Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (60Hz)
szDriverAssemblyVersion	9.18.13.4725
szDriverAttributes	Final Retail
szDriverDateEnglish	1/10/2015 10:07:47
szDriverDateLocalized	10.01.2015 10:07:47
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
szDriverNodeStrongName	oem31.inf:NVIDIA_SetA_Devices.NTamd64.6.1:Section139:9.18.13.4725:pci\ven_10de&dev_1381
szDriverSignDate	
szDriverVersion	9.18.0013.4725
szKeyDeviceID	Enum\PCI\VEN_10DE&DEV_1381&SUBSYS_362E1458&REV_A2
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{CF0992BB-D6BF-4D56-BA8D-3EA4068CD0D5}\0000
szManufacturer	NVIDIA
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00E02001
szRegHelpText	
szRevision	
szRevisionId	0x00A2
szSubSysId	0x362E1458
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x10DE
1
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	11
dwHeight	1050
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1680
iAdapter	1
lDriverSize	17250776
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	GeForce GTX 750
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Integrated RAMDAC
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	
szDescription	NVIDIA GeForce GTX 750
szDeviceId	0x1381
szDeviceIdentifier	{D7B71E3E-50C1-11CF-9D65-23161FC2C435}
szDeviceName	\\.\DISPLAY2
szDisplayMemoryEnglish	4025 MB
szDisplayMemoryLocalized	4025 MB
szDisplayModeEnglish	1680 x 1050 (32 bit) (60Hz)
szDisplayModeLocalized	1680 x 1050 (32 bit) (60Hz)
szDriverAssemblyVersion	9.18.13.4725
szDriverAttributes	Final Retail
szDriverDateEnglish	1/10/2015 10:07:47
szDriverDateLocalized	10.01.2015 10:07:47
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
szDriverNodeStrongName	oem31.inf:NVIDIA_SetA_Devices.NTamd64.6.1:Section139:9.18.13.4725:pci\ven_10de&dev_1381
szDriverSignDate	
szDriverVersion	9.18.0013.4725
szKeyDeviceID	Enum\PCI\VEN_10DE&DEV_1381&SUBSYS_362E1458&REV_A2
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{CF0992BB-D6BF-4D56-BA8D-3EA4068CD0D5}\0001
szManufacturer	NVIDIA
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00E02001
szRegHelpText	
szRevision	
szRevisionId	0x00A2
szSubSysId	0x362E1458
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x10DE
Log Messages
[11580:7320:0516/093926.388:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(65,10-42): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(87,10-42): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[11580:11584:0516/125932.384:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1

The attached files starting with SDP contain the offer and answer parts for the video negotiation. The png file show a statistics about send video data over time from wireshark.
The version with 1611 in the name are the good case using transport-cc in chrome-to-chrome case. The variant with 1714 in the name are the bad case which uses goog-remb and  violates the negotiated bandwidth limit.
 
hack_wired_encrypted_1to1_300Kbit_20180516_1611.png
108 KB View Download
hack_wired_encrypted_group_300Kbit_20180516_1714.png
103 KB View Download
SDP_between_Chrome_and_chrome_transportCC_1611.txt
5.1 KB View Download
SDP_between_Chrome_and_MCU_remb_1714.txt
3.9 KB View Download
Labels: Needs-Triage-M66
Components: -Internals>Media Blink>WebRTC
Labels: Triaged-ET TE-NeedsTriageHelp
martin716929@ Thanks for the issue.

As the above said setup is not available at TE end to test this issue, adding 'TE-NeedsTriageHelp' label and requesting someone from Blink>WebRTC team to look into the issue and help in further triaging.

Thanks..
Components: -Blink>WebRTC Blink>WebRTC>Video
It is certainly possible that some bug causes us to ignore the bitrate constraint. However, based on the graphs of wireshark data, it is not clear to me that this is the case.

A bitrate constraint means that the average over time should not be above a certain limit. However, we do allow short burst of data at a higher rate. The graphs only seem to contain isolated points that are above the limit, so it could be an effect of natural pacing variations coupled with the sampling in your wireshark plotting tool.

holmer@, WDYT?
I can offer another example. The chrome-to-chrome version from 13:51 almost never violates the 1000 KBit/s bandwidth limit. On the other hand the chrome-to-MCU variant from 19:57 violates the limit several times.
In my eyes I "see" the wish to keep the limit in the 13:51 variant and on the other hand the 19:57 variant mostly does not stop or "nearly" keep 1000 KBit/s bandwidth.
Jira_encrypted_wired_1to1_1000KBit_qp40_7fps_20180517_1351.png
108 KB View Download
SDP_between_Chrome_and_chrome_transportCC_1350.txt
5.3 KB View Download
Jira_encrypted_wired_group_1MBit_qp40_7fps_20180517_1957.png
123 KB View Download
SDP_between_Chrome_and_MCU_remb_1957.txt
4.1 KB View Download

Comment 7 by holmer@chromium.org, May 22 2018

Did this work better in earlier versions of Chrome?
I tested with the previous chrome version and the problem was the same.

Comment 9 by holmer@chromium.org, May 28 2018

Cc: ilnik@chromium.org
Owner: sprang@chromium.org
Status: Assigned (was: Unconfirmed)
Erik, is this something you and Ilya know about?
Cc: sprang@chromium.org
Owner: holmer@chromium.org
Martin, is this isolated to screen sharing or does it happen with a camera feed as well?

I'm not sure I'm the right person for this, but if I might venture a guess... When send-side cc is used, remb can still be active and is used to signal an upper bound. It might be the case that this code path was assumed to work for the sdp negotation as well. If so, as soon as we get a new remb the old negotiated value would be overridden. This is just a theory.

holmer@, can you assign to someone who knows the bwe/cc plumbing better, srte@ maybe?


The problem does not occur with video in the chrome-to-chrome variant nor in the chrome-to-mcu variant.
Hm, I don't see why this should be content specific. The only thing I can think of is that it's related to ALR probing.
I don't understand #11. When does the problem occur?

It would be really helpful if you could collect an RTC event log. (chrome://webrtc-internals > Create dumps > Select "Enable packet and event recording". Then reproduce the issue and attach the log to the bug.)

I'm still not convinced that there is any problem with the bandwidth estimation. The main difference seems to be that your MCU-case produces and sends a lot less data.
The problem occurs when using screen share between chrome and MCU. If you have a look at the last pair of graphics I attached to this bugreport, you can see the scale on the left hand side.
In the graphics for the chrome-to-chrome(1to1) scenario the send data is almost always below 1.1 MBit/s.
If you have a look at the graphics of the chrome-to-MCU(group) scenario there are multiple peaks up to 2 MBit/s and the limit of 1 MBit/s is somewhere in the middle of the graphics. In the time 240 - 300 seconds less data was sent, but I assume the available bandwidth proposed by remb was decreased for an unknown reason. Except for this section I think the amount of sent data is not much less than in the chrome-to-chrome scenario.
Each pair of graphics was created on sending the SAME video multiple times by chrome.
I created RTC event logs and append it to this bug.
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1053.png
138 KB View Download
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_46.log
166 KB View Download
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_47.log
5.9 KB View Download
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_48.log
5.9 KB View Download
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_49.log
5.9 KB View Download
Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_50.log
2.9 MB View Download
According to the video tests, which did not show the problem: For screen share I use 1080p resolution. For video the client uses only VGA. This might influence the result. I am going to try to modify the client to send a 1080p video and check again.
I was able to modify the client to send 1080p, but the resolution is decreased if there is too much bandwidth needed.Overall the negotiated bandwidth was honored in the chrome-to-chrome amd the chrome-to-MCU szenario.
I assume for video another algorithm is used, because the framerate stayed at 30 fps for video. For screenshare the framerate was decreasing on high bandwidth.
Can we add ability to inject this negotiated max bitrate in the loopback tests? Then it would be trivial to repro with both send-side and receive-side bandwidth estimation in various conditions.
The logs you attached seems to be audio-only.

You're supposed to get one log per peerconnection. If you only have one peerconnection, you should only get one log file.

Which chrome version are you using?
I used the last chrome version at that point of time:
Version 66.0.3359.181 (Offizieller Build) (64-Bit)

There should be 4 peer connections:
- 1 audio and video (incoming and outgoing) only audio should be used in the test
- 2 incoming video, which should be unused
- 1 screen share, which should be used for sending screen share.

A renegotiation is done on starting screenshare. I assume that is the reason for the fifth logfile. Did you check all logs ? I guess the largest logile contains screenshare data : Solid_encrypted_wired_group_2MBit_qp40_7fps_20180530_1038_event_log_20180530_1039_42_50.log

I do not know how to check/read the content of these logfiles. Can you give me a hint how to do that ? 
I did not receive any answer on my last post. Are the logs okay or do you need other logs ? 
Is there a tool to read such logs and check the mediatype ?

Sign in to add a comment