Re: [Wish] Initial comments on draft-murillo-whip-02

[Sergio Garcia Murillo <[e-mail]>]

El lun, 30 ago 2021 a las 19:49, Christer Holmberg (<
[e-mail]>) escribió:

>
> > I would prefer to add as few optionalities to the protocol as possible.
> It would be trivial for the server
> > to just return the current URL and not to have to test each
> interoperability with each client for both
> > when the location header is present or not.
>
> I just think it is not a good idea to make changes to core HTTP, so in my
> opinion it is more about HTTP interoperability than WHIP interoperability.
>
> And, what if you are using an HTTP library that will remove the header if
> the endpoint isn't changed?
>
>
Can you point me to the HTTP spec that defines that behaviour of the Link
attribute?


>
> > In terms of features, the WHIP protocol matches the ones offered by RTMP
> which is still widely used
> > and offered on most profesional hardware encoders and main open source
> broadcasting software
> > (i.e. ffmpeg/OBS/vmixer/...). Not sure how that is not suited for
> "professional usages".
>
> RTMP supports PAUSE, RESUME etc commands, doesn't it? :)
>

Hard to know as AMF commands on top of RTMP are quite undocumented. If you
do some archeology on action script reference you can see that the
play/pause are commands send from the player to the media server when
reproducing a video, they are not intended to be used for the publish
command:

https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetStream.html#publish()


> Let me explain how the sport event ingestion software I am using works:
>
> First you establish the session, choose what sports event you are going to
> stream etc.
>
> After that, the media ingestion starts. But, the server does not start the
> broadcasting of the media yet. It only broadcasts the stream to the one
> doing the ingestion, so that he/she can check that everything works.
>
> After that, the user sends a command to the server to start the actual
> broadcasting.
>
> Etc.
>
> So, the user has explicit control of when the actual broadcasting begins,
> even if the media ingestion has began earlier.
>
> As I am not the implementer of the software I don't know all the protocol
> level details, other than it uses RTMP.
>
>
That workflow makes a lot of sense, but not sure how it maps the
pause/resume operation. Typically you will control it from a control panel
on the server side which is not at the encoder.



> > Regarding the metadata exchanged during the session, which could be done
> either by datachannel
> > or by a new whip protocol extension with another http url,
>
> I had a datachannel in mind, and that's why I asked about it earlier :)
>
> But, if commands are outside the scope of WHIP, I think it would be good
> to explcitly say it.
>
>
The way I see it, the problem again is defining and standardizing the
metadata, not about how to transport it. We can state that it is not
supported by this WHIP version.

Best regards
Sergio

>