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