[opus] Opus RTP/RTSP support

[Giulio Mazzoleni]

Hi to everybody.
I have conducted some tests with the development version of VLC and it
seems to work quite good.

I have added a few lines to vlc/modules/demux/live555.cpp in order to
accept opus codec as valid

> else if( !strcmp( sub->codecName(), "OPUS" ) )
> {
>   tk->fmt.i_codec = VLC_FOURCC( 'O', 'p', 'u', 's' );
>   if ( sub->rtpTimestampFrequency() )
>     tk->fmt.audio.i_rate = sub->rtpTimestampFrequency();
>   else
>   {
>     msg_Warn( p_demux,"Using 48kHz as default sample rate." );
>     tk->fmt.audio.i_rate = 48000;
>   }
> }

Then i noticed that the codec was expecting to retrieve an ogg header,
so I started to "blindly" modify code to skip the header part and just
instantiated a simple decoder to parse the RTP stream (code attached).
It's no good programming technique and I don't know about VLC internals
so this was just the quickest (and dirty) way to play the stream I could
think of.

RTSP descriptor is being correctly handled by the live555 library and
the opus decoder in VLC (that calls libopus routines) just parses it and
plays correctly.

I have a question about the packetizer.
I am using a 20 ms window, 64 kbit/s CBR, 16 KHz sampling frequency
When sending RTP packets I am packetizing them with
opus_repacketizer_cat in a number of 6 (120 ms).
The packets are being assembled correctly, but the data is being altered
in the process and during decoding I hear much noise.

So I ended up packetizing frames by hand by prepending the toc and the
number of frames bytes by hand and removing the toc from the other
frames. With this trick the opus_decoder is able to correctly decode the
whole packet at once without noise.

I am attaching the code I used to packetize the frames (even if I doubt
it would be useful) and two wireshark grabs of the sama data (packetized
with multiframe and appended by hand one frame after the other (with no
toc alteration - is just frame appending). Data in input has been given
with the same fixed pattern and a few windows have been discarded in
order to let the algorithm to eventually stabilize.

> #if 0
>   if (framesize > 1000 || opus_repacketizer_cat(rep, mp3buffer, numBytesWritten) != OPUS_OK)
>   {
>     num_frames = opus_repacketizer_get_nb_frames(rep);
>     pkt_size = opus_repacketizer_out(rep, fTo, 1200);
>     rep = opus_repacketizer_init(rep);
>     opus_repacketizer_cat(rep, mp3buffer, numBytesWritten);
> 
>     framesize = numBytesWritten;
>     numBytesWritten = pkt_size;
>     frame_done = 1;
>   }
>   else
>   {
>     framesize += numBytesWritten;
>   }
> #else
>   memcpy(fTo+2+framesize, mp3buffer+1, numBytesWritten-1);
>   framesize += numBytesWritten-1;
>   num_frames++;
> 
>   if (framesize >= 1000 || num_frames >= 6)
>   {
>     fTo[0] = mp3buffer[0] | 0x03;	// write TOC
>     fTo[1] = num_frames;		// write frame number
>     numBytesWritten = framesize+2;
>     framesize = 0;
>     frame_done = 1;
> }
> #endif

If I have time to check the behaviour with opusrtp I'll give you a
feedback.

Sorry for the trivial issues I have described, but maybe somebody else
could find the hints useful.

Many thanks and best regards.
Giulio

On Fri, 2012-11-23 at 16:17 -0500, Tristan Matthews wrote:
> 2012/11/23 Giulio Mazzoleni <giulio.mazzoleni at digital-instruments.it>:
> > Il 23/11/2012 17.52, Timothy B. Terriberry ha scritto:
> >> Giulio Mazzoleni wrote:
> >>> Is there any program that is currenlty able to play a RTSP/RTP stream
> >>> encoded with opus?
> >> Both (the current beta release of) Firefox and Chrome (as of M24)
> >> support Opus in (S)RTP as part of WebRTC. Of course, that also requires
> >> ICE and DTLS-SRTP (for Firefox) or SDES-SRTP (for Chrome... DTLS-SRTP
> >> support will be coming in M25), so it may not be the most convenient for
> >> simple testing.
> >>
> >> The underlying media engine used by both browsers can be tested
> >> separately, however. See
> >> <http://www.webrtc.org/reference/getting-started>  to get the code and
> >> build it. After that, you can run voe_cmd_test to set up an RTP receiver
> >> listening for Opus (just follow the on-screen prompts).
> >>
> >> There's no signaling (e.g., SDP), so you'll have to hard-code the
> >> payload type you send on (like opusrtp in opus-tools does), or figure
> >> out how to generate suitable signaling to send to your own application.
> >> The handling of mono and stereo is being changed slightly in
> >> <http://review.webrtc.org/933022/>  (to run on a single payload type to
> >> avoid negotiation failure). We recently clarified how this is supposed
> >> to work in<http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-02>.
> >> _______________________________________________
> >> opus mailing list
> >> opus at xiph.org
> >> http://lists.xiph.org/mailman/listinfo/opus
> > Thanks Timothy for the many info you provided.
> > I'll take some time to go trhough them, but hopefully I'll get a better
> > idea on the subject.
> >
> > In the meantime I come across this post:
> > http://lists.mplayerhq.hu/pipermail/mplayer-users/2012-September/085336.html
> >
> > I was using RTP dynamic payload type 109 as seen i the opurtp code and
> > sending SDP signalling as stated in the RTP draft (mostly about
> > frequency, audio type and subtype).
> >
> > But I'll have to double check all the VLC, mplayer, ffmpeg, and of
> > course Chrome and Firefox to find the easiest tool to debug the system.
> 
> GStreamer also supports opus RTP payloading/depayloading, might be
> worth checking out.
> 
> Best,
> T
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiframe.pcap
Type: application/x-extension-pcap
Size: 1062 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/opus/attachments/20121129/62566d32/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opus.c
Type: text/x-csrc
Size: 4120 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/opus/attachments/20121129/62566d32/attachment.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: singleframe.pcap
Type: application/x-extension-pcap
Size: 1226 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/opus/attachments/20121129/62566d32/attachment-0001.bin