Bug 201870

Summary: [GStreamer] isAVC1CodecSupported is crashing several media source tests due to avc1.4d4001 codec type
Product: WebKit Reporter: Charlie Turner <cturner>
Component: WebKitGTKAssignee: Charlie Turner <cturner>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, calvaris, cgarcia, commit-queue, ews-watchlist, gustavo, menard, pnormand, vjaquez
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch for landing
none
Patch for landing none

Charlie Turner
Reported 2019-09-17 06:02:04 PDT
GStreamerRegistryScanner::isAVC1CodecSupported is a little sloppy not checking NULL returns from the gst_codec_utils* family which is causing the crashes. But there's a deeper problem, the NULL return is for when the h264 codec utility thinks there's an erroneous input. Particularly, it doesn't like the level_idc in the SPS for avc1.4D4001. There's nothing wrong with that according to the spec, so there's two bugs, 1. Fix the sloppy NULL checking in WebKit 2. Fix GStreamer to correctly parse the level_idc
Attachments
Patch (3.18 KB, patch)
2019-09-17 07:30 PDT, Charlie Turner
no flags
Patch for landing (3.35 KB, patch)
2019-09-23 00:48 PDT, Charlie Turner
no flags
Patch for landing (3.36 KB, patch)
2019-09-23 02:45 PDT, Charlie Turner
no flags
Charlie Turner
Comment 1 2019-09-17 07:30:05 PDT
Charlie Turner
Comment 2 2019-09-17 07:30:57 PDT
I am mistaken about point 2. In fact, the web tests are doing some weird encoding level idc's with multiplying by 10. The GStreamer function is expecting the correct things, so we have to special case here for test conformance.
Xabier Rodríguez Calvar
Comment 3 2019-09-18 02:44:13 PDT
Comment on attachment 378962 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=378962&action=review > Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:322 > + char levelAsStringFallback[2] = { '\0', '\0' }; This is a bit too tricky so I would recommend adding a with this bug number to enable a very quick access to the info.
Philippe Normand
Comment 4 2019-09-18 18:16:55 PDT
Instead of a bug link I would suggest an explanation similar to the one present in the ChangeLog (or copy/paste :)) because when ChangeLogs roll-over, keeping track of the code change reasoning becomes harder.
Charlie Turner
Comment 5 2019-09-23 00:48:51 PDT
Created attachment 379359 [details] Patch for landing
WebKit Commit Bot
Comment 6 2019-09-23 00:51:04 PDT
Comment on attachment 379359 [details] Patch for landing Rejecting attachment 379359 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 379359, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in Source/WebCore/ChangeLog contains OOPS!. Full output: https://webkit-queues.webkit.org/results/13059974
Charlie Turner
Comment 7 2019-09-23 02:45:08 PDT
Created attachment 379361 [details] Patch for landing
WebKit Commit Bot
Comment 8 2019-09-23 03:31:30 PDT
Comment on attachment 379361 [details] Patch for landing Clearing flags on attachment: 379361 Committed r250227: <https://trac.webkit.org/changeset/250227>
WebKit Commit Bot
Comment 9 2019-09-23 03:31:32 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.