Profile is ignored in mimetype when recording h264 video with MediaRecorder
Reported by
donald@donaldharvey.co.uk,
May 25 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Set up a MediaRecorder instance with mimeType='video/webm;codecs="avc1.4d000a"' (main level 1) 2. Record a video. What is the expected behavior? The output file should use the specified H264 profile, or throw an error stating that the profile provided is not supported. What went wrong? The recording is encoded with the default H264 encoding (I think just baseline?) and the provided profile is ignored, regardless of whether or not it is supported in hardware. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.11.6 Flash Version: For doing high-quality video recording using MediaRecorder, it would be really useful to have more control over the encoding parameters, at least by being able to specify the profile. For hardware-accelerated encoding, Chrome already internally detects the hardware-supported profiles, so the MediaRecorder API would just have to expose these and hook them up with the internal VEAEncoder instance. I think OpenH264 doesn't yet support anything other than baseline, so this feature would only be useable if hardware-accelerated encoding is available.
,
May 26 2017
@donald-- Could you please provide us the sample test file /js fiddle /test case to reproduce the issue and also please provide us the expected and actual result screenshot or screencast for better traiging purpose. Thanks!
,
Jun 1 2017
Thinking about it, there are really two issues here. The first is that MediaRecorder.isTypeSupported doesn't actually parse and check whether h264 profiles are supported -- provided the overall codec is supported, it just returns True (see https://jsfiddle.net/da5pqv5f/). The second issue is that MediaRecorder itself ignores the provided profile, as described above; I don't have a test case for this, but I've looked at the source code and it's clear that the provided profile isn't passed to VEAEncoder, and that a default profile are used.
,
Jun 1 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 5 2017
,
Jun 7 2017
,
Jun 7 2017
,
Jun 12 2017
,
Oct 13 2017
This is correct: avc1 codec is not further parsed [1] and only the name is passed to VideoTrackRecorder [2], and this ends up in the default (baseline) 264 encoder [3]. I won't have much time to work on this, but I can review patches if you would like to provide the code. [1] https://cs.chromium.org/chromium/src/content/renderer/media_recorder/media_recorder_handler.cc?sq=package:chromium&dr=CSs&l=131 [2] https://cs.chromium.org/chromium/src/content/renderer/media_recorder/video_track_recorder.cc?sq=package:chromium&dr=CSs&l=379 [3] https://cs.chromium.org/chromium/src/content/renderer/media_recorder/video_track_recorder.cc?sq=package:chromium&dr=CSs&l=469 |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kavvaru@chromium.org
, May 25 2017