[Live-devel] Adding support for DV video

Ben Hutchings ben at decadent.org.uk
Sun Apr 26 07:24:39 PDT 2009


On Sat, 2009-04-25 at 22:21 -0700, Ross Finlayson wrote:
[...]
> >According to the RFC, each packet must contain a whole number of DV
> >blocks (i.e. the RTP payload size must be a multiple of 80) but it
> >doesn't appear to be possible to control fragment sizes in this way in
> >liveMedia.
> 
> In fact, this is determined (in "MultiFramedRTPSink.cpp") by the 
> result of the "allowFragmentationAfterStart()" virtual function.  By 
> default, this function returns False, meaning that no 'frames' can be 
> fragmented across more than one RTP packet, unless the RTP packet 
> contains only a single 'frame' that is too large for a single RTP 
> packet.
> 
> A 'frame' in this context is a single discrete chunk of data that is 
> input (one at a time) to the "MultiFramedRTPSink" (subclass).  If you 
> are assuming that juse one "DV block" is input at time (I haven't yet 
> looked at your code closely enough to see if that is, in fact, the 
> case), then you should get the desired behavior automatically.
[...]

In fact I use a whole DV frame (120000-576000 bytes), which will then be
split across a large number of packets.  I take it this is not the
correct way to use frames in liveMedia?

Given that a DV stream has at least 45000 blocks per second, I suspect
that it would be sensible to pack blocks together. We need to see at
least 6 blocks to identify the DV profile in use, and 480 bytes plus
headers should still be less than IPv4's minimum MTU of 576 bytes, so I
would go with that.  That would also match Firewire.

How should the receiving application cope with packet loss?  My
application, DVswitch, currently receives DV over TCP and does not have
any logic to deal with incomplete DV frames.  If I convert it to use
liveMedia, as I intend to, then it will have to do so in some way.  It
seems to me that it would need to have its own reassembly logic.

Ben.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090426/f4a3bfae/attachment.bin>


More information about the live-devel mailing list