[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]

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:              11-30-2007 15:50 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.
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 11-30-07 15:50  
---------------------------------------------------------------------- 
I'm a little confused about this patch.  It appears that all you're doing
it swapping the order of checking subclass again AST_FORMAT_AUDIO_MASK and
AST_FORMAT_VIDEO_MASK.

The problem with this is, as far as I know, frames only have either audio
or video - not both.

If a subclass is in AST_FORMAT_AUDIO_MASK, it cannot also be in
AST_FORMAT_VIDEO_MASK (and vice versa).  Thus, changing the order would do
nothing... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-30-07 15:50  qwell          Note Added: 0074618                          
======================================================================