| 16:00 | <Domenic> | Nobody wants to review https://github.com/whatwg/html/pull/244 ? ;_; |
| 16:17 | <terinjokes> | Domenic: i'm always :+1: for removing dead code |
| 16:37 | <annevk> | Domenic: I thought you wanted to add more things to it |
| 16:37 | <annevk> | Domenic: was "but there are still things to do" not meant as an indication you were going to update the PR? |
| 16:37 | <Domenic> | annevk: oh, no, some time soon I might do the rest, but those two stand alone for now. |
| 16:38 | <annevk> | Domenic: some command concepts remaining seemed a bit confusing, but I think overall it was fine |
| 16:39 | <annevk> | Domenic: so... LGTM |
| 16:39 | <Domenic> | \o/ |
| 16:39 | <annevk> | Domenic: will you rebase & merge? |
| 16:39 | <Domenic> | annevk: yeah |
| 16:44 | <Domenic> | I wonder if we should consider some kind of... background color, maybe? ... for authoring requirements |
| 16:44 | <annevk> | There used to be some kind of switch |
| 16:45 | <annevk> | To highlight the "impl" bits mostly, since sometimes those are intertwined |
| 16:45 | <Domenic> | The w-nodev markers can allow you to remove the impl bits |
| 16:45 | <Domenic> | But the confusion we're seeing most recently is authors saying "but my browser allows this just fine" |
| 16:46 | <Domenic> | i.e. authors not realizing that authoring conformance criteria are meant to constrain them, not to constrain browsers. |
| 16:47 | <annevk> | It probably needs to be called out in text in some way too |
| 16:47 | <annevk> | To make it accessible |
| 16:47 | <Domenic> | I have vague visions of margin annotations |
| 16:47 | <Domenic> | Let me see if I can make a mockup |
| 17:01 | <Domenic> | Something like this maybe https://usercontent.irccloud-cdn.com/file/cO7Wucwf/authoring.png |
| 17:02 | <Domenic> | Would be a lot of work to go find all the authoring requirements though |
| 20:59 | <roc> | is this new Streams spec supposed to obsolete existing transformation APIs such as MediaRecorder? |
| 21:00 | <wanderview> | Domenic: ^^^ |
| 21:00 | <Domenic> | roc: it is a primitive like Promise. Ideally specs upgrade to use it, like they have been doing for callbacks vs. promises |
| 21:00 | <Domenic> | roc: for example I threw together https://domenic.github.io/streaming-mediastreams/ |
| 21:01 | <roc> | is MediaStreamRecorder supposed to be something totally different to MediaRecorder, or did you mean to write MediaRecorder? |
| 21:02 | <Domenic> | roc: it is meant to be an alternative design that is based on streams instead of having ad-hoc stream-esque interfaces |
| 21:03 | <roc> | so the intent *is* to replace MediaRecorder? |
| 21:04 | <Domenic> | roc: yes, I guess. Although it would depend on the relevant people working up the energy to implement something new, which in this particular case seems low. |
| 21:05 | <Domenic> | roc: just like with promises, I'm sure we'll see lots of older APIs stick with the old ad-hoc mismash of patterns (XHR's events, IDB's callbacks, etc.), while new APIs are developed that use promises (Fetch, IDB+Promises draft, ...) |
| 21:05 | <Domenic> | s/use promises/use the new primitive/ |
| 21:05 | <roc> | it certainly makes sense for me for MediaRecorder to be able to produce a readable stream |
| 21:06 | <Domenic> | IMO that would be like saying it make sense for the XMLHttpRequest object to produce a promise. I guess it works, but it'd be better not to have to go through the old interface on your way to the new primitive. |
| 21:07 | <roc> | MediaRecorder has useful state like RecordingState |
| 21:07 | <roc> | and a MIME type |
| 21:08 | <Domenic> | Yes, those are present in MediaStreamRecorder as well. |
| 21:08 | <Domenic> | https://domenic.github.io/streaming-mediastreams/#mediastreamrecorder |
| 21:08 | <roc> | the state isn't, actually, but that's not so important |
| 21:08 | <Domenic> | well, it's in the ReadableStream class (somewhat implicitly) |
| 21:10 | <Domenic> | (We used to expose the state as a sync getter but people preferred not having to shuffle that information back to the main thread in the general case.) |
| 21:10 | <roc> | you don't have pause and resume methods and states on ReadableStreams do you? |
| 21:10 | <Domenic> | roc: they implicitly pause when nobody is reading from them. It's a pull model instead of a push one. |
| 21:10 | <roc> | ok |
| 21:11 | <roc> | suppose I connect a MediaStreamRecorder to an IndexedDB writeable stream |
| 21:11 | <roc> | I'd like to be able to pause() and resume() recording in response to user input |
| 21:11 | <roc> | how do I write that code in your model? |
| 21:12 | <roc> | that aside |
| 21:12 | <Domenic> | You would not use the convenience method pipeTo(idbWS), but would instead write a few lines to do reads from the MSR and writes to the IDB WS |
| 21:12 | <Domenic> | Then you could stop doing reads/writes at will |
| 21:12 | <Domenic> | pipeTo is a convenience for wanting to pipe things unconditionally |
| 21:13 | <Domenic> | The code would be very similar to the second example |
| 21:14 | <Domenic> | I would write it up but I get the sense from your "that aside" that we are moving on now :) |
| 21:14 | <roc> | refraining from reading is not a good signal to pause the MediaRecorder |
| 21:14 | <roc> | obviously there'll have to be some buffering inside the MediaRecorder or we'll lose data |
| 21:15 | <roc> | so pausing-by-not-reading will basically force that buffer to fill and then we'll drop data |
| 21:15 | <roc> | so we'll necessarily incur latency corresponding to the size of the buffer |
| 21:15 | <Domenic> | Oh, sorry, I misunderstood what you meant by "pausing" |
| 21:15 | <Domenic> | I thought you meant "pausing reading" not "pausing recording" |
| 21:16 | <roc> | no I mean this: http://www.w3.org/TR/mediastream-recording/#widl-MediaRecorder-pause-void |
| 21:16 | <Domenic> | Right |
| 21:16 | <Domenic> | I had an answer for this, several months ago, ... trying to dredge it up |
| 21:17 | <roc> | ok, so moving on :-) |
| 21:17 | <roc> | seems to me that MediaStreamRecorder aggregates a readable stream by inheritance |
| 21:17 | <Domenic> | I think it might have been that you can simply cancel the stream and create a new one when you want to resume, with the realization that if that is a naive approach, then it's easy to add pause/resume methods to pause/resume the flow of data into the readable stream |
| 21:18 | <roc> | that's not ideal, yes |
| 21:18 | <roc> | or we would have designed MediaRecorder that way |
| 21:18 | <Domenic> | Fair enough |
| 21:18 | <Domenic> | Re inheritance: yes, the intent is that many consumers of MediaStreamRecorder would treat it as a generic stream-of-blobs. Those who care specifically about the stuff exposed in https://domenic.github.io/streaming-mediastreams/#mediastreamrecorder could use those properties if they wanted. |
| 21:19 | <roc> | the main problem being that the recorded data has headers (and trailers) and it's not always valid to just concatenate blobs to produce a new valid media file |
| 21:19 | <Domenic> | Ah yeah, makes sense |
| 21:20 | <roc> | if MediaRecorder exposed a readable stream as a property, that would be aggregating by membership |
| 21:20 | <roc> | I don't think this is a huge difference |
| 21:21 | <Domenic> | I agree |
| 21:21 | <Domenic> | But MediaRecorder has a bunch of stuff that is just an ad-hoc readable stream interface |
| 21:21 | <roc> | aggregation by membership is often preferred, especially when you might need multiple inheritance, like EventTarget if you want to something to fire custom events at |
| 21:21 | <Domenic> | If the argument is to preserve compat for backward-compat purposes then that makes sense |
| 21:21 | <roc> | I agree, and maybe that can be deprecated or removed later |
| 21:22 | <Domenic> | Yeah, that seems like a reasonable way to evolve |
| 21:22 | <roc> | removing those parts is simpler and less risky than replacing the entire interface |
| 21:22 | <Domenic> | I wasn't really clear what the interop status on MediaRecorder was |
| 21:22 | <roc> | Firefox ships it |
| 21:22 | <roc> | AFAIK Chrome is close to having an implementation |
| 21:23 | <Domenic> | Cool, yeah. |
| 21:23 | <Domenic> | If there were interest I'd be happy to recast this as an extension to existing MediaRecorder. Right now it was mostly just a POC. |
| 21:24 | <roc> | I have another question about structured elements in streams. The spec draft talks about passing video frames and stuff like that |
| 21:24 | <Domenic> | Heh. |
| 21:24 | <roc> | I'm a bit dubious aobut that |
| 21:24 | <roc> | but |
| 21:24 | <Domenic> | Yes, that is a bit handwavey |
| 21:24 | <roc> | I don't have time to talk about it right now! |
| 21:24 | <roc> | so, I'll catch you later :-) |
| 21:24 | <Domenic> | Cool :) |
