Subject: RE: [AVT] Working group last call: JPEG-2000 payload format

From: "Boudani Ali" <[email-masked]>
Date: Wed, 30 May 2007 16:26:27 +0200

>Can you please clarify why it isn't enough with a 90 kHz clock even for

>professional video? When is their need for time jitter related to when
a 
>frame was sampled needs to be smaller than what a 90kHz clock provide. 
>specially considering that most of the frame rates used will have 
>perfect match to a particular tick increment per frame. I don't think
we 
>have heard any such issues being raised in AVT before. If we do miss a 
>critical motivation then this applies to all our video payload formats,

>not only one.

I didn't say smaller. The RTP timestamp in the draft is used also as a
presentation time. So in that case, if you want to mix two frames, you
need the pixel precision (The clock frequency used in SD is 27MHz).
That's why I am saying that 90KHz (one and only) is not enough. If you
put "SHOULD be 90 KHz", that may be a solution since the user could then
put its frequency value in rtpmap (a=rtpmap:..../frequency) in the SDP
session.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 May 2007 16:38:09 +0200

> put its frequency value in rtpmap (a=rtpmap:..../frequency) in the SDP

I don't really see how this is applicable. Why would you use the RTP 
timestamp to accomplish analog video signal synchronization to pixel 
level when you can mix the video frames in the digital domain and then 
send the mixed video frames to the digital to analog transmission 
converter? That way you only need to accomplish the association of the 
frames from the different streams that needs to go together. That 
synchronization can be accomplished even if one used a clock ticking at 
the frame-rate.

Also, are you really expecting these operations to happen on the 
JPEG-2000 video format? I can maybe understand if we where talking about 
the uncompressed video format that handles individual pixels.

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: [email-masked]
----------------------------------------------------------------------

---

From: Dave Singer <[email-masked]>
Date: Wed, 30 May 2007 10:15:43 -0700

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.

Any payload format should recommend ('should') something, but mention 
that other possibilities exist.

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

At 16:38  +0200 30/05/07, Magnus Westerlund wrote:
>>>frame was sampled needs to be smaller than what a 90kHz clock 
>>>provide. specially considering that most of the frame rates used 
>>>will have perfect match to a particular tick increment per frame. 
>>>I don't think
>>we
>>>have heard any such issues being raised in AVT before. If we do 
>>>miss a critical motivation then this applies to all our video 
>>>payload formats,
>>
>>>not only one.
>>
>level when you can mix the video frames in the digital domain and 
>then send the mixed video frames to the digital to analog 
>transmission converter? That way you only need to accomplish the 
>association of the frames from the different streams that needs to 
>go together. That synchronization can be accomplished even if one 
>used a clock ticking at the frame-rate.
>
>JPEG-2000 video format? I can maybe understand if we where talking 
>about the uncompressed video format that handles individual pixels.

-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 31 May 2007 10:19:32 +0200

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.

> 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.

> 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

---

From: Dave Singer <[email-masked]>
Date: Thu, 31 May 2007 10:08:44 -0700

I think we are in general agreement here, that we should recommend a 
clock rate, and lay out the factors that go into the choice, so that 
sources choose well.

You asked for a reason to pick another rate.  An obvious one is when 
you are given a file to send (e.g. a QuickTime movie, MP4, 3GP file) 
in which the media track has a clock that is not the same as 90 kHz, 
but is nonetheless suitable.  If I choose the same clock for RTP, I 
am assured I won't have any conversion problems as I am not doing 
conversion -:)

For example, files with a clock at 24000 are not uncommon (for film 
material).  It *may be* that all the timestamps are, in fact, 
integral when converted to 90 kHz, but I cannot tell that without 
scanning the file.

I think the example of source material timed at 27 MHz is probably similar.

-- 
David Singer
Apple Computer/QuickTime