Issue metadata
Sign in to add a comment
|
Chrome stalls when downloading video stream
Reported by
j.christ...@gmail.com,
Jun 29 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.9.3 Example URL: Steps to reproduce the problem: 1. Try a video player that serves MP4 streams using Content-Range requests and where the video is streamed with a single request 2. After initially downloading ~3.3MB Chrome stalls for seconds and from then loads 1MB, stalls, loads 1MB 3. If the stalling period is longer than the socket timeout used on ther server side, the server will kill the connection which usually results in a stopped video in Chrome. What is the expected behavior? Chrome should always continue to download (enlarging the available buffer locally) the video stream to avoid any socket timeout problems. What went wrong? Chrome pauses the download of a video stream for more than 20 seconds which is the default timeout for Tomcat, so the video stream fails. Did this work before? Yes Don't know but this problem was introduced with one of latest releases. Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 67.0.3396.99 (Official Build) (64-bit) (cohort: Stable) Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: 30.0.0.113 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 Viz Service Display Compositor: Disabled 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 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 Viz service display compositor is not enabled by default. Disabled Features: viz_display_compositor Checker-imaging has been disabled via finch trial or the command line. Disabled Features: checker_imaging Version Information Data exported 2018-06-29T15:45:29.196Z Chrome version Chrome/67.0.3396.99 Operating system Windows NT 6.1.7601 SP1 Software rendering list URL https://chromium.googlesource.com/chromium/src/+/a337fbf3c2ab8ebc6b64b0bfdce73a20e2e2252b/gpu/config/software_rendering_list.json Driver bug list URL https://chromium.googlesource.com/chromium/src/+/a337fbf3c2ab8ebc6b64b0bfdce73a20e2e2252b/gpu/config/gpu_driver_bug_list.json ANGLE commit id 702006f4a07e 2D graphics backend Skia/67 baf6686f92df805d3e25e80a0f3c79597cb3a6a5- Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end Driver Information Initialization time 67 In-process GPU false Passthrough Command Decoder false Direct Composition false Supports overlays false Sandboxed true GPU0 VENDOR = 0x10de, DEVICE= 0x13c2 *ACTIVE* Optimus false AMD switchable false Desktop compositing none Diagonal Monitor Size of \\.\DISPLAY3 22.0" Diagonal Monitor Size of \\.\DISPLAY2 22.0" Diagonal Monitor Size of \\.\DISPLAY1 24.0" DX12 false Vulkan false Driver vendor NVIDIA Driver version 23.21.13.9135 Driver date 3-23-2018 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 970 Direct3D11 vs_5_0 ps_5_0) GL_VERSION OpenGL ES 2.0 (ANGLE 2.1.0.702006f4a07e) 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: 00000000000347f0) Window system binding version 1.4 (ANGLE 2.1.0.702006f4a07e) 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 EGL_ANGLE_create_context_extensions_enabled 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 1920x1200], workarea=[0,0 1920x1200], scale=1, external. Color space information {primaries_d50_referred: [[0.6669, 0.3330], [0.2338, 0.7179], [0.1593, 0.0774]], transfer:0.0000*x + 0.0000 if x < 0.0000 else (1.0000*x + 0.0000)**2.2000 + 0.0000, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[2779098405] bounds=[-1920,-65 1920x1200], workarea=[-1920,-65 1920x1200], scale=1, external. Color space information {primaries_d50_referred: [[0.6666, 0.3332], [0.2462, 0.7088], [0.1631, 0.0893]], transfer:0.0000*x + 0.0000 if x < 0.0000 else (1.0000*x + 0.0000)**2.2000 + 0.0000, matrix:RGB, range:FULL} Bits per color component 8 Bits per pixel 24 Info Display[2841568472] bounds=[1920,0 1920x1200], workarea=[1920,0 1920x1200], scale=1, external. Color space information {primaries_d50_referred: [[0.6665, 0.3334], [0.2380, 0.7121], [0.1595, 0.0776]], transfer:0.0000*x + 0.0000 if x < 0.0000 else (1.0000*x + 0.0000)**2.2000 + 0.0000, 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 ... loading ... Log Messages GpuProcessHostUIShim: The GPU process exited normally. Everything is okay. [3904:1208:0629/161641.390:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 3146 [3904:1208:0629/161641.390:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 2379 [3904:4248:0629/162058.670:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 3146 [3904:4248:0629/162058.670:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 2379 [3904:2688:0629/162723.186:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(47,8-58): 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(55,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:9868:0629/164309.823:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1 [3904:5844:0629/164655.886:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(49,8-58): 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(57,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:10576:0629/164655.900:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(29,8-58): 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(37,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:5844:0629/164655.911:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(46,8-21): 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(54,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:10576:0629/164655.924:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(46,8-58): 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(54,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:9868:0629/164844.038:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1 [3904:9868:0629/164844.038:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1 [3904:9868:0629/164844.039:ERROR:gles2_cmd_decoder.cc(18055)] : [.DisplayCompositor-0000000009692360]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name [3904:9868:0629/164844.039:ERROR:gles2_cmd_decoder.cc(10173)] : [.DisplayCompositor-0000000009692360]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering. [3904:9868:0629/164844.080:ERROR:gles2_cmd_decoder.cc(10173)] : [.DisplayCompositor-0000000009692360]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering. [3904:9348:0629/164844.122:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(46,8-58): 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(54,8-28): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them [3904:9868:0629/173614.330:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
,
Jun 30 2018
The video starts playing and stops after ca. 90secs. Usually the logs show 3 timed out connections (first after sending 3.3MB, then after 1MB) in such a case. The Developer Console shows the content length mismatch error which is of course correct because Tomcat killed the socket before all data was transmitted. I totally understand that you don't want to waste the user bandwidth, but stalling for more than 20 seconds while Tomcat tries to send 2048 bytes seems to be a bit too conservative too me.
,
Jul 1
Just a second thought: If you want to preserve the bandwidth why not sending Ranged Requests with an upper limit (with a header like "Range: bytes=1234560-2234560"), so instead of stalling after 1MB just request only the required data and create another request for the next data when needed. The web server could then handle this gracefully and would not run into errors.
,
Jul 1
,
Jul 2
j.christoph.wagner@ Thanks for the issue. Request you to provide a sample file/URL where this issue can be reproduced, which will help in further triaging of the issue. Thanks..
,
Jul 2
Please try this URL for reproducing: http://demo.attention.dk/avm/embed/volvo+video/-S5Idr3nA After ~1:45 you will see the first error appearing in the dev console. After another minute the playback will stop completely. Please let me know if you need more information.
,
Jul 2
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 2
Isn't the same issue going to occur if the user pauses the video and comes back later? What request is the content length changing for? I wouldn't expect the total content length to ever change. The linked video plays through at least ~3 minutes fine on Linux, though the console does show a couple 400 errors.
,
Jul 3
I don't think the Content-Length itself is the problem. It's Chrome not reading data in a sensible manner. It sometimes stops reading any bytes from the server from the open socket for more than 30 seconds. And the server than decides to closes the socket with now Chrome complaining that it didn't get the data advertised in the header. We haven't tried Linux but it stops on at least 4 different Windows machines here. If that's not reproducible even on Windows for you we could try a different video which requires less data transmitted because that will probably fail earlier.
,
Jul 3
j.christoph.wagner@ Thanks for the update. Able to reproduce this issue on Windows 10 on the latest Stable 67.0.3396.99 and latest Canary 69.0.3480.0 as per comment #6. Issue is not reproducible on Mac OS and Ubuntu 14.04. Bisect Information: =================== Good Build: 64.0.3255.0 Bad Build : 64.0.3256.0 Unable to run the per-revision bisect as error is coming up and unable to play the media file on Chromium build, hence providing the manual Changelog URL from Omahaproxy. https://chromium.googlesource.com/chromium/src/+log/64.0.3255.0..64.0.3256.0?pretty=fuller&n=10000 From the above Changelog, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/689818 posciak@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Thanks
,
Jul 3
Hmm, I'm not sure what's going here, but +network,loader folks since this has a bisect, though I wasn't able to reproduce so it may be a flaky bisect.
,
Jul 9
This doesn't seem like a network stack issue - we read data as the renderer requests it. If the renderer isn't requesting more data, it's expected that we don't read more data from the network. We can't just buffer an infinite amount of data in memory, or cache an arbitrarily large file.
,
Jul 18
=>hubbe@ to either WontFix or provide more commentary.
,
Jul 24
I'm not sure what's going on here. If the server closes the connection, chrome should just start a new one when it needs more data. For some reason I'm getting an audio decode error while playing back the example in #6 though. The video seems to play back fine if I download it first, and doing range requests against the server seems to work ok too.
,
Jul 24
I see this error in media-internals: 00:05:58 745 error Failed to send audio packet for decoding: timestamp=358954666 duration=21333 size=263 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0) 00:05:58 745 error audio decode error 00:05:58 764 error audio error during playing, status: PIPELINE_ERROR_DECODE Not sure if it's the cause of the problem or caused by the problem though.
,
Jul 24
Ok, so it looks like this problem is on the server side. When tomcat (or whatever is serving the file in #6) closes the connection due to a timeout, it also corrupts the data somehow. I wrote a program that reads random ranges from the server. If I insert a sleep(60) in it, the connection closes, but before it closes the connection, it emits some data that doesn't match what I get if I just download the whole file. I have attached my test program.
,
Jul 24
@hubbe: Thank you for the test script. I tried to reproduce the issue here in a test environment and it always breaks with an error after waiting for the server to close the connection. Then I patched the server to mark the sent byte arrays with 0xAA 0x__ at the beginning and 0xEE 0xFF at the end. The __ placeholder was used as am increasing block counter to check which block failed. Then I could see blocks like this: 00040000: aa41 0000 0000 0100 0002 0000 0000 0200 ... 00040ff0: 0004 0000 0000 0100 0000 0000 0000 eeff which is block 0x41 transferred completely. But the next block looks bad: 00041000: aa42 0000 0000 0100 000a 0000 0000 0100 ... 00041f40: 0004 0000 0000 0100 0000 0000 0000 01aa 00041f50: 4100 0000 0001 0000 0200 0000 0002 0000 where it seems like the last byte got truncated and the previous block 0x41 was repeated instead. Assuming this is a server problem I wrote my own little test script but this did not give me the problem. Hmm. My last attempt was using Wireshark to completely see the data going over the line from the server when running your script. I could clearly see the increasing block count until it started to sent block 0x42 when the connection was closed. I could NOT see block 0x41 being transmitted again after block 0x42. From my point of view this indicates that the Pike script is not really doing what I would expect from looking at the code. It's returning data that is definitely not going over the socket (I tried multiple times). So I hope the WONTFIX is not the final result in this case. Thanks a lot for your time. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Jun 29 2018