W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

Re: [mediacapture-record] Input width, height MUST be recorded and playable (#172)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 Jul 2019 14:58:48 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-509261504-1562597926-sysbot+gh@w3.org>
> It seems reasonable to expect the video to be recorded with dynamically changing resolution, so that input frames are correctly represented in the output. The main issue I see though, is if recording into a container that doesn't support changing resolution dynamically. Should that be an error? Or should it be left to the UA to take an alternative approach, like scale, crop, etc?
> I don't know the container landscape well enough to say whether, or which, containers support this, but I imagine there are some that don't. Others might know better.

@Pehrsons Interestingly see [Unexpected Error when appending webm files: mkvmerge throws error when width and height are different](https://gitlab.com/mbunkus/mkvtoolnix/issues/2582) at https://gitlab.com/mbunkus/mkvtoolnix/issues/2582#note_189360046

> This is not a bug. Matroska doesn't support changing pixel widths/heights in the middle of the stream.

Though that is evidently not the case as demonstrated by the output of `MediaRecorder` at Firefox. If that were/is the case per some inconspicuous note or detail at a controlling Matroska or WebM specification then Firefox is beyond the cutting edge as to writing Matroska-based WebM files and further the Firefox implementation needs to be the example of how such functionality IS achieved, which should lead to the relevant specifications being updated to reflect what is actually possible using the Matroska-based webm container.

GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/172#issuecomment-509261504 using your GitHub account
Received on Monday, 8 July 2019 14:58:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:25 UTC