The VLC team's job is to review and integrate patches from the community. If patches are not sent, they bugs won't get fixed. It's as simple as that.
As the other thread revealed, this function depends on the library from the FFmpeg folks, so I don't know how that affects our ability to develop a solution.
Another fact revealed that these RTP packets are framed in 16ms bursts instead of the desired 20ms and it was suggested that the Windows low resolution clock at 16milliseconds was the reason. I have an executable (that I can not share, unfortunately) that plays files to a unicast address or i.p. multicast group in a mu-law 8000bits/second format and sounds as good as can be expected on an AudioMate 360 gateway that sends and receives such RTP streams. I ran this executable on this HP laptop running Windows XP (I'm typing on it now), so I don't think that the Windows low resolution timebase is the limiting factor in getting this to work. At least it doesn't have to be the limiting factor because the fileplayer worked as expected.
viewtopic.php?f=4&t=63667&p=279607&hilit=0.016#p229605
I am not a C developer, so I can be of little use in writing code, but I do have some resources here that might help a real developer. At the very least I can test on my stuff where I do contract work, since RTP streams are their bread and butter.
It seems that there is a demand for this ability as there are Nortel and Cisco phone systems out there that could benefit from it. I sure hope the community can come up with a useful solution.