Re: [xine-devel] Multicast video

[shaheed <sr...@ie...>]

On Saturday 25 August 2001 5:39 am, Paul Flinders wrote:

> If we're talking about multicast IP then IGMP will be present, even if
> no-one's
> listening to it. Yes you could set things up on a LAN so that several
> services
> were multicast on the same address but with varying ports but it would be
> a broken set up (IMO). Possibly it would make sense to send two related
> streams on same group+different port but I haven't seen that done outside
> of RTP which uses the port to distinguish the data from the RTCP
> protocol. IP-TV
> (which uses RTP for the transport) even uses different groups for the
> audio+video
> for a singal programme.
>
> But it probably won't hurt to assume that the stream is identified by
> group+port
> rather than just group

I think we'll have to agree to disagree about whether IGMP will be guaranteed 
to be present, but the good news is that we agree that group+port can be used!

> >>>This was my point in a much earlier mail where I mentioned that a
> >>> network (multicast or unitcast) receiver would likely need some logic
> >>> to acquire, and check transport sync. The kind of algorithm I have used
> >>> to acquire sync is:
> >
> >...
> >
> >>I don't think that you need to do anything at the TS packet level.
> >>Multicast video is UDP
> >>and whole numbers of TS packets (7 for ethernet) are placed in a frame.
> >>As UDP preserves
> >>packet boundaries you should always find your reads are a multiple of
> >>188 bytes with 0x47
> >>at the start and every 188 bytes after that. If not it's probably not an
> >>MPEG stream.

See below.

> >Your assumptions may be valid sometimes, but there are plenty of
> >circumstances where making them will just prove to be a pain. For example,
> >most video servers prefer to use larger UDP packet sizes because it is
> > more efficient for them to do so (for example, OVS by default uses 8192
> > byte UDP packets). Then again, don't forget about jumbo size packets on
> > GigE, or IP over FC, or ...
>
> BUT packet boundaries are still preserved - UDP is "unreliable" but if I
> get the
> packet it should be what the server sent. It might not arrive or it
> might arrive
> out of sequence but if it arrives it should be intact (UDP has
> checksums). You'd
> only need to search for the sync byte if the server splits TS packets
> across frame
> boundaries. I'm not aware of any that do.
>
> I thought that OVS was RTSP+RTP anyway. RTP should place an integral
> number of TS packets in each frame. RFC 2238 says so quite explicitly in
> fact.

RTP is transport independent and RFC 2250 (sucessor to 2038) does indeed 
mandate an integral number of TS packets in a RTP payload *packet* but this 
is in no way related to Ethernet *frame* size. So, a server using 8192 byte 
UDP packets will split TS packets across Ethernet frames (or whatever network 
layers are in use), but a client application will not see this since the UDP 
protocol stack will have reassembled the *packet* before anyone really cares. 
I think we agree so far.

But, OVS predates RTSP+RTP. It, like much other equipment (e.g. servers, 
encoders, test equipment from all the major vendors), is perfectly capable of 
handling data over raw UDP. And then no assumptions about TS packet alignment 
can be made. Why restrict the xine multicast plugin from interoperating with 
this stuff? If you mean a multicast RTP plugin, then that is a different 
matter!

> It is probably worth some sanity checks (is byte 0  and byte 188 equal
> to 0x47)
> but I think that searching for sync bytes is probably over-engineered
> (humm, I suppose
> that would let you watch an RTP stream without being able to understand
> RTP, although if you want to watch RTP streams then they should be decoded
> as such).

You are assuming RTP. I think we need to support raw UDP too.

> >Also, see my point about non-UDP transports. The API can and IMHO should
> > be made generic. There is no reason why xine should not used to receive
> > data from a DVB broadcast of some kind, given a suitable input
> > card+driver.
>
> For non-udp transports you probably ought to have a separate input plug-in
> and you may have more of a point there - I don't know. Does the "suitable
> input card+driver" exist? I had a look around for a ditigal TV tuner
> last month
> and couldn't find one - plenty of analogue cards but nothing digital (in
> the UK
> anyway).

Genroco have some nice cards for DVB-ASI I/O. Lots of people use Fore/Marconi 
cards for MPEG over AAL5. My point is that for receive, you really only need 
two input plugins for COTS and CLTS. The only transport-specific code should 
be address handling (e.g. as in the use of different structures for IPV4 and 
IPV6 addresses). Double that for RTP variants and suddenly 4 input plugins 
will handle all standard network technologies!

> >>You almost certainly _do_ want to throw anything before the first I
> >>frame away though.
> >
> >I myself would not make the input stage care about I frames. IMHO it
> > should concentrate on the job of adpating the incoming transport (be it
> > TS over "file:" or "udp:") to the demuxer and that is all. There is no
> > reason to restrict the input stage to video after all!
>
> It doesn't really matter who throws it away, it's just that you get
> wierd effects
> from if you start decoding P&B frames from some other I frame.

Hence my point that the input stages (including probably demuxers) need the 
ability to reset the downstream decoders. This is much more generic, reliable 
and efficient than building content aware input plugins.