[jitsi-dev] Should I use SynchronizerImpl or something else?

Mondain · 2014-12-17 16:58:14 UTC

I'm looking for some clarification on timestamps within jitsi. I want to
have "usable" audio and video timestamps per decoded media sample / frame,
but both the javax.media.Buffer.getTimeStamp() and
javax.media.Buffer.getRtpTimeStamp() return odd looking long values
(positive one moment and negative the other..). I looked around a bit and
found the org.jitsi.impl.neomedia.recording.SynchronizerImpl class in
libjitsi and I wonder if it might be what I need to translate the RTP times
to sample / frame time, or is there somewhere else I should be looking?

Regards,
Paul

Boris_Grozev · 2014-12-17 17:20:46 UTC

Hello,

···

On 17/12/14 18:58, Mondain wrote:

I'm looking for some clarification on timestamps within jitsi. I want to
have "usable" audio and video timestamps per decoded media sample /
frame, but both the javax.media.Buffer.getTimeStamp() and
javax.media.Buffer.getRtpTimeStamp() return odd looking long values
(positive one moment and negative the other..). I looked around a bit
and found the org.jitsi.impl.neomedia.recording.SynchronizerImpl class
in libjitsi and I wonder if it might be what I need to translate the RTP
times to sample / frame time, or is there somewhere else I should be
looking?

SynchronizerImpl is meant to allow for the correct translation of RTP timestamps from two or more streams coming from one endpoint into a local timestamp. It needs valid RTP timestamps to begin with.

I would expect that Buffer.getTimestamp() is what you need, however I don't know why you are seeing weird values.

Boris

Mondain · 2014-12-17 17:38:02 UTC

Thanks for the quick response Boris; I'll dump my time stamps and look them
over again to verify what I was seeing last night.

···

On Wed Dec 17 2014 at 12:21:54 PM Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 17/12/14 18:58, Mondain wrote:
> I'm looking for some clarification on timestamps within jitsi. I want to
> have "usable" audio and video timestamps per decoded media sample /
> frame, but both the javax.media.Buffer.getTimeStamp() and
> javax.media.Buffer.getRtpTimeStamp() return odd looking long values
> (positive one moment and negative the other..). I looked around a bit
> and found the org.jitsi.impl.neomedia.recording.SynchronizerImpl class
> in libjitsi and I wonder if it might be what I need to translate the RTP
> times to sample / frame time, or is there somewhere else I should be
> looking?

SynchronizerImpl is meant to allow for the correct translation of RTP
timestamps from two or more streams coming from one endpoint into a
local timestamp. It needs valid RTP timestamps to begin with.

I would expect that Buffer.getTimestamp() is what you need, however I
don't know why you are seeing weird values.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Mondain · 2014-12-18 14:52:28 UTC

I've found that the video buffer timestamp is set to -1
or Buffer.TIME_UNKNOWN (The getTimeStamp method return this value if the
time stamp of the media is not known); does this mean there is a bug in the
h264 decoder?

···

On Wed Dec 17 2014 at 12:38:00 PM Mondain <mondain@gmail.com> wrote:

Thanks for the quick response Boris; I'll dump my time stamps and look
them over again to verify what I was seeing last night.

On Wed Dec 17 2014 at 12:21:54 PM Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 17/12/14 18:58, Mondain wrote:
> I'm looking for some clarification on timestamps within jitsi. I want to
> have "usable" audio and video timestamps per decoded media sample /
> frame, but both the javax.media.Buffer.getTimeStamp() and
> javax.media.Buffer.getRtpTimeStamp() return odd looking long values
> (positive one moment and negative the other..). I looked around a bit
> and found the org.jitsi.impl.neomedia.recording.SynchronizerImpl class
> in libjitsi and I wonder if it might be what I need to translate the RTP
> times to sample / frame time, or is there somewhere else I should be
> looking?

SynchronizerImpl is meant to allow for the correct translation of RTP
timestamps from two or more streams coming from one endpoint into a
local timestamp. It needs valid RTP timestamps to begin with.

I would expect that Buffer.getTimestamp() is what you need, however I
don't know why you are seeing weird values.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Mondain · 2014-12-18 14:56:57 UTC

Sorry, I mis-typed in the previous email; I'm using the
org.jitsi.impl.neomedia.codec.video.h264.JNIEncoder not the decoder.

···

On Thu Dec 18 2014 at 9:52:26 AM Mondain <mondain@gmail.com> wrote:

I've found that the video buffer timestamp is set to -1
or Buffer.TIME_UNKNOWN (The getTimeStamp method return this value if the
time stamp of the media is not known); does this mean there is a bug in the
h264 decoder?

On Wed Dec 17 2014 at 12:38:00 PM Mondain <mondain@gmail.com> wrote:

Thanks for the quick response Boris; I'll dump my time stamps and look
them over again to verify what I was seeing last night.

On Wed Dec 17 2014 at 12:21:54 PM Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 17/12/14 18:58, Mondain wrote:
> I'm looking for some clarification on timestamps within jitsi. I want
to
> have "usable" audio and video timestamps per decoded media sample /
> frame, but both the javax.media.Buffer.getTimeStamp() and
> javax.media.Buffer.getRtpTimeStamp() return odd looking long values
> (positive one moment and negative the other..). I looked around a bit
> and found the org.jitsi.impl.neomedia.recording.SynchronizerImpl class
> in libjitsi and I wonder if it might be what I need to translate the
RTP
> times to sample / frame time, or is there somewhere else I should be
> looking?

SynchronizerImpl is meant to allow for the correct translation of RTP
timestamps from two or more streams coming from one endpoint into a
local timestamp. It needs valid RTP timestamps to begin with.

I would expect that Buffer.getTimestamp() is what you need, however I
don't know why you are seeing weird values.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Mondain · 2014-12-18 15:08:25 UTC

I just reviewed the the JNIEncoder and it just uses the incoming buffer
timestamp ~line 769 outBuffer.setTimeStamp(inBuffer.getTimeStamp());
And since my path is VPXDecoder -> YUV -> JNIEncoder I looked at the
VPXDecoder and it is in fact setting the time stamp to -1 on the output
buffer; is this by-design? Shouldn't it just copy the timestamp from the in
buffer like the h264 encoder, instead of setting it to -1 and thus leaving
me with unusable timestamps.

···

On Thu Dec 18 2014 at 9:56:56 AM Mondain <mondain@gmail.com> wrote:

Sorry, I mis-typed in the previous email; I'm using the
org.jitsi.impl.neomedia.codec.video.h264.JNIEncoder not the decoder.

On Thu Dec 18 2014 at 9:52:26 AM Mondain <mondain@gmail.com> wrote:

I've found that the video buffer timestamp is set to -1
or Buffer.TIME_UNKNOWN (The getTimeStamp method return this value if the
time stamp of the media is not known); does this mean there is a bug in the
h264 decoder?

On Wed Dec 17 2014 at 12:38:00 PM Mondain <mondain@gmail.com> wrote:

Thanks for the quick response Boris; I'll dump my time stamps and look
them over again to verify what I was seeing last night.

On Wed Dec 17 2014 at 12:21:54 PM Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 17/12/14 18:58, Mondain wrote:
> I'm looking for some clarification on timestamps within jitsi. I want
to
> have "usable" audio and video timestamps per decoded media sample /
> frame, but both the javax.media.Buffer.getTimeStamp() and
> javax.media.Buffer.getRtpTimeStamp() return odd looking long values
> (positive one moment and negative the other..). I looked around a bit
> and found the org.jitsi.impl.neomedia.recording.SynchronizerImpl
class
> in libjitsi and I wonder if it might be what I need to translate the
RTP
> times to sample / frame time, or is there somewhere else I should be
> looking?

SynchronizerImpl is meant to allow for the correct translation of RTP
timestamps from two or more streams coming from one endpoint into a
local timestamp. It needs valid RTP timestamps to begin with.

I would expect that Buffer.getTimestamp() is what you need, however I
don't know why you are seeing weird values.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Boris_Grozev · 2014-12-18 15:09:06 UTC

Hello,

···

On 18/12/14 16:56, Mondain wrote:

Sorry, I mis-typed in the previous email; I'm using the
org.jitsi.impl.neomedia.codec.video.h264.JNIEncoder not the decoder.

The encoder preserves the timestamp of the input Buffer (which usually comes from the device), so it depends on how you use it.

Boris

Mondain · 2014-12-18 15:15:42 UTC

I see that now and its ok, but the real issue is in the decoder. I filed a
bug: https://github.com/jitsi/libjitsi/issues/28

···

On Thu Dec 18 2014 at 10:11:02 AM Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 18/12/14 16:56, Mondain wrote:
> Sorry, I mis-typed in the previous email; I'm using the
> org.jitsi.impl.neomedia.codec.video.h264.JNIEncoder not the decoder.

The encoder preserves the timestamp of the input Buffer (which usually
comes from the device), so it depends on how you use it.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev