<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Rémi et al,<BR><BR>Hi, and thanks for your reply. Sure not knowing exactly what the ulaw <BR>encoding in the following statement then I guess its difficult for me to <BR>understand whether something is wrong, or whether its a feature request:<BR><BR>"C:\Program Files\VideoLAN\VLC\vlc.exe" c:\3.wav --sout <BR>"#transcode{acodec=ulaw,ab=32,scale=0,channels=1,ar=8000}:rtp{dst=172.30.1.26,port-audio=30000}" <BR>vlc://quit<BR><BR>The last message from Lordnk sort of suggests that it exists but needs <BR>further tweeking, unfortunately there isnt a lot more informaton like the <BR>actual code changes and I presume that his changes were never included in a <BR>VLC release (again not sure how I would check).<BR><BR>Everyone suggests that this is an easy fix, but right now not sure what to <BR>do, ANY help please!!<BR><BR><SNIP><BR>I was able to get VLC to stream g711 correctly using an sout chain of <BR>transcode:rtp. VLC does not seem to read ulaw from file correctly, so a new <BR>demux was needed. In fact, VLC demuxes ulaw as standard pcm, so it reads the <BR>file completely off-target.<BR><BR>Creation of a new FrameInfo type for ulaw at the demux stage allowed to <BR>control the incoming byte stream chunk size, which then in turn would then <BR>send packets to the sout module(s) in the correct size and with the correct <BR>timestamp. Creation of a new packetizer for g711 over RTP allowed control of <BR>the Source Identifier and Timestamp formats.<BR><BR>The end result on the wire is now:<BR><BR><BR>  Code: Select all<BR>    0.019982 192.168.1.73 -> 239.1.1.1    RTP PT=ITU-T G.711 PCMU, <BR>SSRC=0x852D, Seq=38586, Time=4941928<BR>    0.020000 192.168.1.73 -> 239.1.1.1    RTP PT=ITU-T G.711 PCMU, <BR>SSRC=0x852D, Seq=38587, Time=4942088<BR>    0.019986 192.168.1.73 -> 239.1.1.1    RTP PT=ITU-T G.711 PCMU, <BR>SSRC=0x852D, Seq=38588, Time=4942248<BR>    0.019990 192.168.1.73 -> 239.1.1.1    RTP PT=ITU-T G.711 PCMU, <BR>SSRC=0x852D, Seq=38589, Time=4942408<BR><SNIP><BR><BR><BR>----- Original Message ----- <BR>From: "Rémi Denis-Courmont" <<A href="mailto:remi@remlab.net">remi@remlab.net</A>><BR>To: <<A href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</A>><BR>Cc: "Nigel Warburton" <<A href="mailto:warburton_nigel@hotmail.com">warburton_nigel@hotmail.com</A>><BR>Sent: Saturday, January 09, 2010 5:45 PM<BR>Subject: Re: [vlc-devel] FW: Can anyone help please?<BR><BR><BR>Hello,<BR><BR>Le jeudi 7 janvier 2010 21:46:43 Nigel Warburton, vous avez écrit :<BR>> Basically I was looking at using VLC to steam uLaw at 20ms so that it <BR>> could<BR>>  be received by a Cisco IP Phone. Today the VLC player does not seem to<BR>>  support it although I have seen a number of requests for support.<BR><BR>Those are not requests for support. Those are requests for a new feature.<BR><BR>> So that leaves me a bit stuck between waiting to see if this feature comes<BR>>  into VLC and works, use something else, or see if anyone fancies to help<BR>>  for a pat on the back, chocolate or cash.<BR><BR>As I already said, it does not seem particularly difficult, but it needs <BR>time<BR>and motivation.<BR><BR>> I really think this fix would be really useful, today afaik 16ms isnt used<BR>>  by any devices.<BR><BR>It's not really 16ms. It's just a side effect.<BR><BR>-- <BR>Rémi Denis-Courmont<BR><A href="http://www.remlab.net/">http://www.remlab.net/</A><BR><A href="http://fi.linkedin.com/in/remidenis">http://fi.linkedin.com/in/remidenis</A><BR>_______________________________________________<BR>vlc-devel mailing list<BR>To unsubscribe or modify your subscription options:<BR><A href="http://mailman.videolan.org/listinfo/vlc-devel">http://mailman.videolan.org/listinfo/vlc-devel</A><BR>                                           <br /><hr />Got a cool Hotmail story? <a href='http://clk.atdmt.com/UKM/go/195013117/direct/01/' target='_new'>Tell us now</a></body>
</html>