Then Dave is permitted to send a stream between matching
compliant applications using an 89999 Hz media clock, 12857
ticks per frame, exactly 7 frames per second. Or: a 70000 Hz
clock, 10000 ticks per frame.
An alternate video source, playing nice and sending at
90 kHz, is guaranteed to be able to talk successfully to
Dave's receiver application.
Dave's special source may not be able to send successfully
to the majority of J2K receiver applications.
Is this a high enough level of interoperability?
Regards,
Chuck
Magnus Westerlund wrote:
Dave Singer skrev:
> RTP payload formats may be used for all sorts of purposes and (varying)
> frame rates. I disagree that we in the AVT group 'know best' and that
> any payload format should mandate a particular clock frequency. It's
> perfectly legitimate for me to send material at say 7 fps, and 90000 is
> not suitable for that -- the frames would appear to have varying
> duration, and there is risk of round-off.
I know that AVT is not knowing best. However, I asked this questions so
that we could be educated and take an informed decision. However I think
there are definitely an trade-off between using a fixed timestamp clock
rate and allow any rate to be used.
>
> Any payload format should recommend ('should') something, but mention
> that other possibilities exist.
As this have shown to create problems in implementations. For example it
showed up in an interop test creating problems for the packet-based
streaming service where people sent MPEG-4 content using RFC3016
packetization using non 90kHz clock. This occurs because the wiggle room
was given and most implementors do no understand the implications of
using another clock. Sure, we didn't document well enough all the
downsides with choosing something else. Also we really should provide
some lower and upper boundaries on these values.
>
> Very high clock frequencies (e.g. 27 MHz) bring their own problems
> (frequent wrap-around being one). For a given program, it is usually
> the case that one can easily find a number that
> a) doesn't wrap around too often
> b) is high enough for accurate jitter calculations
> c) is an integer multiple of the frame rate, or, for variable frame
> rate, allows each frame to have an integer timestamp which has not been
> rounded-off
>
Yes, and that have so far been 90kHz to satisfy this. If there are cases
when this is not true I would like to know about them. But I think we
should be clear on why we are allowing any wiggle room at all. 90kHz do
support quite a lot of different frame rates. I am not saying that there
doesn't exist such rate. But given a blank card on what rate to use adds
complexities. If we rather could enumerate a small set of possible rates
to cover the known cases that would make me much happier.
>
But Ali's example is not something that can be solved using the RTP
timestamp rate if I understand this correctly. Simply because 27 MHz
gets us into the problem with frequent wrap around.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt