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

Re: [mediacapture-record] Defer deciding codec until "onstart" fires (#190)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Thu, 17 Oct 2019 10:52:30 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-543119027-1571309548-sysbot+gh@w3.org>
> Secondarily I want to avoid shutting the door on something that would allow an application to dynamically handle track set changes (FWIW issue #4 covered this and is one of the most discussed issues on the spec, but was closed without resolution). Your PR does not achieve that. I could accept shutting this door if the WG discusses this and finds consensus for shutting it.

My PR seems largely irrelevant from that issue.
Prior to my PR it said "Decide mimeType synchronously, then in parallel start encoding."
After my PR it says "In parallel, decide mimeType and start encoding."

I have not changed when encoding starts. The only change to be spec-compliant before vs now is to not surface the mimeType synchronously. If anything this adds flexibility, it doesn't remove it. If you think this is a problem, please explain what you mean.

> I see two ways out that avoid both situations above:
> - Letting the UA start encoding data synchronously in start() although it won't fire "start" (or reveal its mimeType) yet.

If you want to change when encoding starts I think that should be discussed in a separate issue and PR. This is already something that happens in parallel. And considering encoding is something that happens in parallel, I don't think it makes sense to say to "start encoding synchronously" unless you intend to move encoding to the main thread. The best you can get is "in parallel, start encoding as soon as possible". If you want to keep track of order of starting and stopping and being able to control things synchronously for the purpose of modifying track sets I think you can do that _with or without this PR_. Again, that seems like a separate issue?

> - Letting the UA guess (I imagine there's a bunch of heuristics the UA could use to guess right) mimeType synchronously in start() and avoiding transcoding iff the guessed codec and the actual codec match.
> I'll review the details of the PR if we can move forward with one of the three options mentioned above.

Why does the application - or implementation for that matter - need to know mimeType synchronously at start() when encoding, and all events related to encoding (onstart, onstop, ondataavailable, onpause, onresume, onerror) happen later?

GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/190#issuecomment-543119027 using your GitHub account
Received on Thursday, 17 October 2019 10:52:31 UTC

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