[Live-devel] RE : Re: bug found and corrected

[Morgan Tørvolt]

May I suggest setting the duration so that every package is sent
instantly? The DVB-T and other DVB standards demand PCR withing 500ns
accuracy, which is probably better than you will ever be able to get.
I think it is safe to assume that the timing of what you receive is
more than good enough, and just drop the MPEG2TransportStreamFramer
code alltogether. For the RTP timestamps to behave you have to set the
durationPerPacket to something sane though, and that will almost
certainly go wrong after a while due to rounding errors. As I have
suggested before, the BasicUDPSink (and others) should be allowed to
receive a timestamp instead of an duration per packet number so that
one can choose the time to be "current time" for every packet, in
effect sending it instantly. I have done this with great success
myself.

This completely removes the need for any PCR compensation, gives no
problems with insane VBR streams (like some of those hundreds of
still-image sex-hotline channels out there. Is it just me or are most
of them from italy? In practise they only sends an I frame from time
to time), and releaves the CPU of doing the PCR calculations.

-Morgan-

On 06/02/2008, roor0735-ml at yahoo.fr <roor0735-ml at yahoo.fr> wrote:
> I agree, it is not really a bug. In fact, your library is used to stream
> live DVB-T MPEG2 Transport stream in real-time over the network. So, I think
> it will be hard to calculate indexes before streaming the recording TS
> files.
> Concerning the proposed changes, I try to find a better way to correct the
> packet duration estimation issues. Normally, the PCR should be annouced with
> a quite regular periodicity. If the packet interval between two PCR
> annoucement is too low compared to the mean periodiciy of the PCR, then the
> PCR must be ignored  in order to not introduce errors in the packet duration
> estimation. So, I introduce a
> new constant called PCR_PERIOD_VARIATION_RATIO that adjusts the minimum and
> tolerated packet interval from the mean PCR announcement period.
>
> For instance, in my sequence, the mean period of PCR announcement converges
> to around 47. The ratio is set to 50%, so the minimum packet interval
> between two PCR is 23. I think this method is less arbitrary than the "20"
> value.
>
> I hope this can help people that wants to broadcast VBR multiplexed
> dataflows.
> Regards,
> Romain
>
>
> Ross Finlayson <finlayson at live555.com> a écrit :
>  Thanks. However, the existing code is not really a 'bug', although
> your suggested change is (arguably) an improvement.
>
> As you noticed, the current per-transport-packet duration estimation
> code has trouble converging on a stable estimate for streams - such
> as yours - that are wildly VBR. Your suggested change will probably
> help things (although I can also imagine streams for which it might
> make things worse by taking longer to converge to the 'correct'
> average duration). I am also a bit concerned about the arbitrariness
> of the constant "20" that you use.
>
> Nonetheless, I'll add your change to the next release of the library.
>
> (Looking longer-term, a better solution for streaming prerecorded
> files (but not live streams) will be to extend the existing "index
> file" mechanism to include accurate durations - which could be
> computed in advance when generating the index file.)
>
>
>  Ross Finlayson
>  Live Networks, Inc. (LIVE555.COM)
>
>
>
>
>  ________________________________
>  Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo!
> Mail
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
>