- From: jnoring via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Jul 2019 15:22:38 +0000
- To: public-webrtc-logs@w3.org
> @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. I haven't found any evidence this is true. There's certainly nothing in the standard (https://www.matroska.org/technical/specs/index.html) that explicitly precludes this that I could find. I'd also point out if you read Matroska's goals as a project (https://www.matroska.org/technical/whatis/index.html), I would fully expect them to support this. Format changes mid-stream are possible (and even common) in many video codecs, including major ones like H.264 and VP8/VP9. It _is_ true that Matroska has a container level width/height that gets set, and so it's possible that value could be misleading if a client is expecting no change to the format of the stream--but I also don't think it's unreasonable to set those values to whatever the video stream starts at, and expect clients to be able to understand stream-level format changes that roll through as they process data from the container. Also ffmpeg handles dynamic resolution changes just fine in mkv (I've been processing mkv's with dynamic format changes via ffmpeg for years now). -- GitHub Notification of comment by jnoring Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/172#issuecomment-509271127 using your GitHub account
Received on Monday, 8 July 2019 15:22:39 UTC