[asterisk-bugs] [Asterisk 0011429]: Sent RTP video packets have a timestamp based on a 8000 Hz clock instead of 90000 Hz when mark bit is on
noreply at bugs.digium.com
noreply at bugs.digium.com
Tue Dec 11 13:18:43 CST 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=11429
======================================================================
Reported By: sperreault
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 11429
Category: Core/RTP
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 90351
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 11-30-2007 14:53 CST
Last Modified: 12-11-2007 13:18 CST
======================================================================
Summary: Sent RTP video packets have a timestamp based on a
8000 Hz clock instead of 90000 Hz when mark bit is on
Description:
When you ast_write() a video packet, you are supposed to put the mark bit
into the LSB of the subclass member:
f->subclass = AST_FORMAT_H263 | 1;
This makes this conditional in ast_rtp_raw_write() true while it should be
false:
if (f->subclass & AST_FORMAT_AUDIO_MASK) {
The solution is simple: invert the video and audio code paths. First check
for video, and then if video is not present check for audio.
======================================================================
----------------------------------------------------------------------
sperreault - 12-11-07 13:18
----------------------------------------------------------------------
Is there anything I can do to help get this fixed?
Issue History
Date Modified Username Field Change
======================================================================
12-11-07 13:18 sperreault Note Added: 0075228
======================================================================
More information about the asterisk-bugs
mailing list