New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 735335 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug


Participants' hotlists:
Hotlist-1


Sign in to add a comment

append behavior on source buffer for media already played. Chrome rejects the appended fragment including moov, causing subsequent decode error.

Reported by saima8...@gmail.com, Jun 21 2017

Issue description

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

Example URL:
http://www.ptdemos.com/html5/internal/bug_repros/chrome/test.html

Steps to reproduce the problem:
1. Go to http://www.ptdemos.com/html5/internal/bug_repros/chrome/test.html
2. Click on button "Click to get started"
3. Only first fragmented mp4 appended to source buffer is played. Appending the next causes media decode error

What is the expected behavior?
All fragments appended play

What went wrong?
It seems chrome rejects the append to source buffer if time is before/overlapping with currentTime of HTMLMediaElement. Problem is, when quality switch happens, and rejected fragment contained a moov box, it is also rejected. Subsequent append of the new quality causes a decode error. In the attached repro test.html, replace 300-scte.8008.mp4 with 300-scte.8008_withmoov.mp4, and it plays back fine.

This should be fixed because:
a. It would be performance hit to append moov every time
b. It would be difficult to predict on client side all the time if fragment to be appended has overlapping time with current playhead. 

This is causing a lot of decode errors in bitrate switching scenarios for us. 

Verified on Firefox and IE Edge, same scenario works fine and entire content is played.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 26.0 r0

Contents of chrome://gpu: 
Graphics Feature Status
Canvas: Hardware accelerated
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: Software only, hardware acceleration unavailable
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_direct_composition
disable_discard_framebuffer
disable_dxgi_zero_copy_video
disable_framebuffer_cmaa
disable_nv12_dxgi_video
exit_on_context_lost
force_cube_complete
scalarize_vec_and_mat_constructor_args
texsubimage_faster_than_teximage
Problems Detected
VPx decoding isn't supported before Windows 10 anniversary update.: 616318
Disabled Features: accelerated_vpx_decode
GPU rasterization should only be enabled on NVIDIA and Intel DX11+, and AMD RX-R2 GPUs for now.: 643850
Disabled Features: gpu_rasterization
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
NV12 DXGI video hangs or displays incorrect colors on AMD drivers: 623029, 644293
Applied Workarounds: disable_dxgi_zero_copy_video, disable_nv12_dxgi_video
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Version Information
Data exported	6/21/2017, 10:25:13 AM
Chrome version	Chrome/58.0.3029.110
Operating system	Windows NT 6.1.7601 SP1
Software rendering list version	12.20
Driver bug list version	9.36
ANGLE commit id	461d9a3060e3
2D graphics backend	Skia/58 4c81ba6ba3a3270db809bf7d4c3bc782694a56a4
Command Line Args	Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	453
In-process GPU	false
Passthrough Command Decoder	false
Sandboxed	false
GPU0	VENDOR = 0x1002, DEVICE= 0x68f2
Optimus	false
Optimus	false
AMD switchable	false
Desktop compositing	none
Diagonal Monitor Size of \\.\DISPLAY2	23.9"
Diagonal Monitor Size of \\.\DISPLAY1	21.5"
Driver vendor	Advanced Micro Devices, Inc.
Driver version	12.100.0.0
Driver date	1-15-2013
Pixel shader version	5.0
Vertex shader version	5.0
Max. MSAA samples	4
Machine model name	
Machine model version	
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (AMD FirePro 2270 Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 3.0 (ANGLE 2.1.0.461d9a3060e3)
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_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_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float 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_norm16 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_EGL_image_external_essl3 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_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
Window system binding vendor	Google Inc. (adapter LUID: 000000000000c5c3)
Window system binding version	1.4 (ANGLE 2.1.0.461d9a3060e3)
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_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXT_pixel_format_float EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	1
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
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	Software only
BGRX_8888	Software only
BGRA_8888	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
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	1137152
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	ATI display adapter (0x68F2)
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal DAC(400MHz)
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Not Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C
szDescription	AMD FirePro 2270
szDeviceId	0x68F2
szDeviceIdentifier	{D7B71EE2-2BB2-11CF-3E77-2C21BEC2C535}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	207 MB
szDisplayMemoryLocalized	207 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (60Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (60Hz)
szDriverAssemblyVersion	12.100.0.0
szDriverAttributes	Final Retail
szDriverDateEnglish	7/26/2013 16:05:12
szDriverDateLocalized	7/26/2013 4:05:12 PM
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dll
szDriverNodeStrongName	oem71.inf:ATI.Mfg.NTamd64.6.1:ati2mtag_EvergreenC_GL:12.100.0.0:pci\ven_1002&dev_68f2&subsys_01261028
szDriverSignDate	
szDriverVersion	8.17.0010.1190
szKeyDeviceID	Enum\PCI\VEN_1002&DEV_68F2&SUBSYS_01261028&REV_00
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{7BB142A0-B571-4796-9237-4A9124CDE97B}\0000
szManufacturer	Advanced Micro Devices, Inc.
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Not Supported
szRankOfInstalledDriver	00E60001
szRegHelpText	
szRevision	
szRevisionId	0x0000
szSubSysId	0x01261028
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	0x1002
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	1080
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1920
iAdapter	1
lDriverSize	1137152
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	ATI display adapter (0x68F2)
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal DAC(400MHz)
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Not Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C
szDescription	AMD FirePro 2270
szDeviceId	0x68F2
szDeviceIdentifier	{D7B71EE2-2BB2-11CF-3E77-2C21BEC2C535}
szDeviceName	\\.\DISPLAY2
szDisplayMemoryEnglish	207 MB
szDisplayMemoryLocalized	207 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (60Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (60Hz)
szDriverAssemblyVersion	12.100.0.0
szDriverAttributes	Final Retail
szDriverDateEnglish	7/26/2013 16:05:12
szDriverDateLocalized	7/26/2013 4:05:12 PM
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.1
szDriverModelLocalized	WDDM 1.1
szDriverName	aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dll
szDriverNodeStrongName	oem71.inf:ATI.Mfg.NTamd64.6.1:ati2mtag_EvergreenC_GL:12.100.0.0:pci\ven_1002&dev_68f2&subsys_01261028
szDriverSignDate	
szDriverVersion	8.17.0010.1190
szKeyDeviceID	Enum\PCI\VEN_1002&DEV_68F2&SUBSYS_01261028&REV_00
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{7BB142A0-B571-4796-9237-4A9124CDE97B}\0001
szManufacturer	Advanced Micro Devices, Inc.
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Not Supported
szRankOfInstalledDriver	00E60001
szRegHelpText	
szRevision	
szRevisionId	0x0000
szSubSysId	0x01261028
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	0x1002

This is causing decode errors and other issues in production

 

Comment 1 by saima8...@gmail.com, Jun 22 2017

Any update on this? This is impacting playback.
Cc: chcunningham@chromium.org
Components: -Internals>Media Internals>Media>Source
Owner: wolenetz@chromium.org
Status: Assigned (was: Unconfirmed)
Confirmed repro on Windows 58.0.3029.110 (Official Build) (64-bit) (using gpuvideodecoder)
(No repro on linux M59, ffmpeg s/w decoder)

This suggests probable bitstream issue with hardware decode.

media-internals log from windows M58 successful repro:

00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 00	url	blob:http://www.ptdemos.com/932f9bdb-1fe1-4c79-b2af-7a8bb2ca6edf
00:00:00 06	pipeline_state	kStarting
00:00:00 894	found_video_stream	true
00:00:00 894	video_codec_name	h264
00:00:00 894	found_audio_stream	true
00:00:00 894	audio_codec_name	aac
00:00:00 898	audio_dds	false
00:00:00 898	audio_decoder	FFmpegAudioDecoder
00:00:00 898	debug	Video rendering in low delay mode.
00:00:00 894	duration	unknown
00:00:01 15	video_dds	false
00:00:01 15	video_decoder	GpuVideoDecoder
00:00:01 15	pipeline_state	kPlaying
00:00:01 16	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01 58	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01 58	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01 58	event	PLAY
00:00:09 112	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:00:09 112	pipeline_buffering_state	BUFFERING_HAVE_NOTHING
00:00:09 218	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:09 218	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:10 59	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:10 243	error	video decode error
00:00:10 243	pipeline_error	pipeline: decode error
00:00:10 243	pipeline_state	kStopping
00:00:10 244	pipeline_state	kStopped
00:00:10 244	event	PAUSE
Similarly, after updating to current stable on Windows 59.0.3071.109 (Official Build) (64-bit) (cohort: 59_104_Win), successful repro:

00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 00	url	blob:http://www.ptdemos.com/abcd992b-15e5-4bbd-a743-736f8f4d7d03
00:00:00 07	pipeline_state	kStarting
00:00:00 773	found_video_stream	true
00:00:00 773	video_codec_name	h264
00:00:00 773	found_audio_stream	true
00:00:00 773	audio_codec_name	aac
00:00:00 800	audio_dds	false
00:00:00 800	audio_decoder	FFmpegAudioDecoder
00:00:00 801	debug	Video rendering in low delay mode.
00:00:00 871	video_dds	false
00:00:00 871	video_decoder	GpuVideoDecoder
00:00:00 871	pipeline_state	kPlaying
00:00:00 873	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:00 942	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:00 942	height	288
00:00:00 942	width	512
00:00:00 942	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:00 942	event	PLAY
00:00:00 773	duration	unknown
00:00:08 709	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:08 958	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:08 976	error	video decode error
00:00:08 977	pipeline_error	PIPELINE_ERROR_DECODE
00:00:08 977	pipeline_state	kStopping
00:00:08 977	pipeline_state	kStopped
00:00:08 977	event	PAUSE
Cc: jbau...@chromium.org wolenetz@chromium.org
Components: Internals>Media>Hardware
Owner: sande...@chromium.org
Status: WontFix (was: Assigned)
No repro on Linux 59.0.3071.86 (Official Build) (64-bit) (No decode error. Playback proceeds and then stalls around 15 seconds, with one continuous buffered range).

Further to #3-4, the 'video decode error' log entry indicates this is a real decode error (something in the bitstream fed to the GPU video decoder itself, not a parse error.

Rereading the post, to be absolutely clear, the MSE spec requires all newly appended media segments to use the decoder configuration most recently appended (at the time the media segment is appended). In MSE ISOBMFF, the moov is the init segment, and the moofs are media segments. If you're considerably changing the decoder configuration across media segments, but you do not append an appropriate init segment before the media segment with a new decoder configuration, decode error is indeed something to expect.

The fact that s/w video decoder is more lenient in this particular test case shouldn't imply that h/w video decoder must also be lenient.

saima8788@, what is actually changing in the decoder config in the "rejected" moov that you don't append, relative to the first moov?

sandersd@ FYI - there might be some edge case for windows GPU video decoder here *if* the decoder config change (that's omitted in a repro) is something which really shouldn't cause a hardware video decode error on attempting decode of subsequent media.

Marking WontFix unless this diagnosis is deemed incorrect.

Also, FYI as of M59, MediaError.message provides more detail on the suspected root cause of the error, if available. In such a repro here, it contains a combination of the pipeline error and the "video decode error" log entry. This can help production services aggregate errors more precisely.

Comment 6 by saima8...@gmail.com, Jun 22 2017

@wolenetz, I understand you are right about the spec. The scenario is below :
1. Append 480-scte.0.mp4  (moov + moof)
2. Append 300-scte.0.mp4 (decoder config changed, so append moov + moof) --> Seems like moov for this append was ignored, because playback had passed the time for this data
3. Append 300-scte.8008.mp4 (only moof)

My concern is, unless I know for sure that (2) append would be rejected, I cannot ensure that I add moov in (3) as well. Is there a sure way to check while appending? This becomes even more difficult when we convert hls to fmp4 on the fly, we don't always write the moov box.

Thanks for the MediaError.message tip.
Status: Assigned (was: WontFix)
@saima8788 / #6 :
Append #2, if it produced new configs, would internally result in adding the internal vector of known configs and tag any subsequently appended moof's coded frames with the index of the most recently appended config's index. While feeding frames to the decoder, if there is a change in the tagged config, we go through a decoder config change sequence before attempting further decode.

Essentially, if any buffers from append #2 or #3 get sent to the decoder, they will be tagged with the config from the moov in append #2, and when there's a change detected between configs, then decoder is reconfigured.

We still suspect there's something wrong in the bitstream or the handling of it by the hardware decoder.

sandersd@ and I will take a closer look (it'll take a bit since we'll need to custom build for the repro (windows) platform):
I'll look over the MSE API's parser logs to ensure they're detecting distinct configs on append #2, and sandersd@ will look into the windows h/w decoder side if needed to see what sorts of reconfiguring are/aren't done in the scenarios in #6 and optionally in #6 where append 3 uses 300-scte.8008_withmoov.mp4.
MSE parser and demuxer logs show correct / match expectation on a repro.
Notably, with playback *not* started until append 1+2+3 occur, there is still a repro.

sandersd@ is digging further.
We also confirmed no-repro for each of:
a) just append 2+3
b) append 1+2+3withmoov

The fundamental problem here is that avcC provided in 300-scte.0.mp4 and 300-scte.8008_withmoov.mp4 does not contain valid SPS units. The complicating factor is that fallback to software decode is triggered in some, but not all, of the playback scenarios.

ffplay reports this error as:
  [h264 @ 0x7fc2c0004f60] cpb_count 33 invalid
  [h264 @ 0x7fc2c0004f60] Decoding sps 0 from avcC failed

(The value isn't actually 33, though, ffmpeg seems to be clamping it. The actual cpb_count_minus_1 encoded in the SPS is 9373.)

I will adjust the fallback algorithm to be more reliable in this case, but the correct solution here is to re-encode the content.
Project Member

Comment 11 by bugdroid1@chromium.org, Aug 8 2017

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

commit 134faa57d0833002fa84cbffff2d30977a43d310
Author: Thomas Guilbert <tguilbert@chromium.org>
Date: Tue Aug 08 04:03:18 2017

Reset fallback state on decoder reinit

Currently, in DecoderStream, the following scenario can happen:
A DecoderStream is properly initialized and the decoder emits a frame.
We set a flag that indicates that no decoder fallbacks should be
attempted. Then, a config change is received, the decoder is
reinitialized, and the first decode fails (because the new config is not
valid for this decoder). The DecoderStream then errors out completely.

This change resets the fallback flag on decoder reinit, in order to
allow attempts to fallback to a new decoder after config changes.

Bug:  735335 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I4fd6105768058e2ec3c8b3bcd7f4fdce00f0b90b
Reviewed-on: https://chromium-review.googlesource.com/601210
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492526}
[modify] https://crrev.com/134faa57d0833002fa84cbffff2d30977a43d310/media/filters/decoder_stream.cc
[modify] https://crrev.com/134faa57d0833002fa84cbffff2d30977a43d310/media/filters/video_frame_stream_unittest.cc

Status: Fixed (was: Assigned)
The patch in #11 should have made fallback to software decode robust in this case.

Sign in to add a comment