<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://3682/"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR-CA link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-CA>Hi!<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-CA><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-CA>In my previous post, I forgot to mention that I could get it to work by “cheating” a little bit on the RTP clocks.  If I replace the 16000Hz clock of the mpeg stream by 90000, the same as h264, the two streams sync in the same range and play properly.  I saw some VLC whining in the logs though.  Could it be an overflow somewhere in the timestamps calculations?  I’m pretty sure changing the clock isn’t the solution but maybe it can give a clue on where the issue lies.  <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-CA>If it can help, I’m compiling my module for Windows x64 and I can observe the issue on a Linux 32bits box too.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-CA style='color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:36.0pt'><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>For RTCP-based a/v synchronization to work properly for streams that are sent by the LIVE555 RTSP server implementation, two things have to be true:<o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:36.0pt'><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>1/ The presentation times for each frame have to be accurate (obviously), and<o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:36.0pt'><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>2/ The presentation times have to be aligned with 'wall-clock' time - i.e., times that would be generated by calling "gettimeofday()".<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-CA><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-CA>At first I assumed the timestamps were right because they come out of the live library and my algorithm waits for the RTCP synchronisation to occur before feeding the streams into the rtsp server.  After investigating this second point, I found an issue with my timestamps.  My camera’s date is somewhere in 2003 making synchronized timestamps way back in the past.  If I correct the camera’s date and time it fixes the issue I observed making my module and the proxy server working.  This raises a new question: Is it possible to overcome the case where the sender has an incorrect date and time? For now I can fix the camera’s date and time but I can’t take this for granted when the system will be released.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-CA><o:p> </o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:36.0pt'><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>(Out of curiosity, does VLC play the stream OK (i.e., without any a/v sync problems) if you try playing it directly from the network camera (i.e., not through a proxy)?)<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-CA>Yes, the streams are played properly when vlc connects directly to the camera, even when the camera streams from the past.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-CA><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-CA>Thanks again for your support,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-CA>Bruno<o:p></o:p></span></p></div></body></html>