Negotiated bandwith for screen share video is not honored
Reported by
martin71...@googlemail.com,
May 16 2018
|
||||||
Issue descriptionUserAgent: 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.
,
May 16 2018
,
May 17 2018
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..
,
May 17 2018
,
May 17 2018
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?
,
May 22 2018
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.
,
May 22 2018
Did this work better in earlier versions of Chrome?
,
May 22 2018
I tested with the previous chrome version and the problem was the same.
,
May 28 2018
Erik, is this something you and Ilya know about?
,
May 29 2018
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?
,
May 29 2018
The problem does not occur with video in the chrome-to-chrome variant nor in the chrome-to-mcu variant.
,
May 29 2018
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.
,
May 29 2018
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.
,
May 30 2018
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.
,
May 30 2018
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.
,
May 30 2018
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.
,
May 31 2018
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.
,
Jun 4 2018
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?
,
Jun 4 2018
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 ?
,
Jun 19 2018
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 |
||||||
Comment 1 by viswa.karala@chromium.org
, May 16 2018