[vlc-devel] Streaming wizard issues

[Rémi Denis-Courmont]

On Mon, 30 Nov 2009 09:02:41 +0100, Marian Ďurkovič <md at bts.sk> wrote:
>> * Disabling transcode does not seem to work in 1.0-bugfix. Did we forget
> to 
>> backport something?
> It does work, but the procedure is counter-intuitive. You need
> to uncheck transcoding first, and only then add e.g. RTP output.

That looks like a bug still.

>> * It does not make sense to have Audio and video port for RTP, since
>> we're only offering RTP/TS, does it?
> Yes, those are confusing. However, we have another problem here as well:
> this tab was purposedly kept in sync with Open Network tab and (here) we
> were always telling our users that those two should be used the same
> way. Now, the Open Network doesn't have the 'Port' field, and port needs
> to be specified as ':1234', so we should use the same here. 
> 
>> * Should we split RTP into RTP/AVP and RTP/TS?
> TS-muxed output is prevalent in any production environment, and for
proper
> IP-muxed RTP we still need to implement RTCP & A/V sync. Even if that's
> in, (live555) the spec has shortcomings preventing proper sync until RTCP
> packets for all streams were received. That said, I don't think we need
> IP-muxed RTP in the GUI.

That's also what I said on IRC yesterday. But some people want native RTP
anyhow, e.g. because the receiver does not do TS. Also I am not sure if
native TS supports all codecs that our RTP output supports.

>> * Is "UDP" not a bit confusing (RTP is UDP too)? 
>> How about "MPEG-TS over UDP" ?
> Everyone uses udp in the URLs, so the main title should say UDP, maybe
> a smaller explanation somewhere in the tab saying we're packing it
> into MPEG-TS will be useful. Same for RTP. 

The point is that I have witnessed quite a lot of confused users with this.
If you're saying "screw them", I cannot agree. And if you're saying let
them use raw UDP when they could do RTP, I cannot agree either.

>> * Could we prefill the RTP address to some pseudo-random ASM group?
> No. We don't know whether the user wants to use global ASM group, GLOP
> or some of the local group addresses.

And then what? If you want to do something else, you can always change the
group address. Putting a default has many advantages:
1/ it provides an example, which helps people to understand what to put
there,
2/ it saves a lot of time if the user does not care,
3/ it reduces the risk of obscure errors due to invalid input (lets face
it, VLC's error reporting sucks big time).

>> * Could we enable SAP by default and prefill it to "<user>'s stream" or 
>> whatever?
> No. Universities typically have global multicast connectivity, and not
> everyone wants his stream to be publicly visible from the whole world.

Pierre just said the exact opposite.

It is questionable that you'd want to use the VLC Qt4 wizard for production
use. AFAIK, people normally use scripts or even DVBlast instead. The point
is to make the wizard easy, which is how it's supposed to be in the first
place. You can always turn SAP off. Universities with multicast are not the
"benchmark" for the wizard; IMHO, the default should be aimed at the
majority.

>> * If SAP is disabled, could we grey out SAP and SAP group fields?
> Yes
> 
>> * Shouldn't SAP and group be greyed out or absent if there are no RTP
> nor UDP 
>> targets?
> Yes
> 
>> * Is "group name" really useful? Isn't it confusing? (Honestly, I first 
>> thought it meant multicast group IP address)
> We're using that a lot, maybe it could be renamed to something less
> confusing like "Playlist category" or so.
> 
> One additional item:
> * TTL is by default set to 1, which was supposed to limit multicast to
the
> LAN scope. But it's highly confusing for users and multicast scoping
> shouldn't be done via TTL hacks as it might put too much burden on
routers
> where TTL expires. TTL should be set to 255 by default. 

Sorry, but universities with multicast routing are the exception rather
than the rule. TTL 1 is the default for IPv4 on all operating systems, and
I don't see any reason why VLC should depart from that. In fact, I don't
want people accidentally flooding their entire network, and/or their
upstream link(s). I'm fine defaulting to 255 for IPv6 though.

I would also be fine with a simple "Route[d] multicast" check box instead
of the integer field.

-- 
Rémi Denis-Courmont