Opened 8 years ago

Last modified 8 years ago

#5266 new defect

Incorrect sdp file format and rtp timestamps when sending multicast streams

Reported by: Sampsa Riikonen Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: rtp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Hello,

This bug has been tested with ffmpeg version "2.7.6-0ubuntu0.15.10.1" and also with the latest "N-78646-g10fa50c" version from the repository.

I send audio from my local alsa device to a multicast address with the command (1):

ffmpeg -y -f alsa -i default -f mulaw -ar 8k -ac 1 -f rtp rtp://224.168.1.33:50300 > test.sdp

Now I can try to read that .sdp file with (2) ffplay:

ffplay test.sdp

.. or with some other media player, in this case, with vlc (3):

vlc --aout alsa --alsa-audio-channels 1 test.sdp

Case (2) works fine, but (3) fails. We can take a look at file "test.sdp":

SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 224.168.1.33
t=0 0
a=tool:libavformat 56.36.100
m=audio 50300 RTP/AVP 0
b=AS:64

I think the format is wrong here: the first line saying "SDP:" shouldn't be there and it drives vlc crazy.

So, we can fix the file and remove the first line. Now we have a file, lets call it "fixedtest.sdp":

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 224.168.1.33
t=0 0
a=tool:libavformat 56.36.100
m=audio 50300 RTP/AVP 0
b=AS:64

With the fixed sdp file, case (3) works, but only for a while. Eventually vlc tells us that:

[00007f10a4c1de58] core decoder error: Could not convert timestamp 0

I have also seen this:

[00007faeb0c1dbd8] core decoder error: Could not convert timestamp 2777164513959325

If we launch vlc with the verbose flag, i.e. with:

vlc -vvv --aout alsa --alsa-audio-channels 1 fixedtest.sdp

we see that it goes for forever into a buffering state:

[00007fb56c0009b8] core input debug: Buffering 0%

So, there seems to be one or two bugs here:

a) incorrect sdp file format (with an extra line)
b) maybe incorrect timestamps when sending streams with rtp packetization

If (b) is not a bug, but a vlc problem, please let me know and I'll file a bug report at vlc.

Regards,

Sampsa

Change History (3)

comment:1 by Carl Eugen Hoyos, 8 years ago

Component: ffmpegundetermined
Keywords: timestamp multicast removed

Please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

comment:2 by Sampsa Riikonen, 8 years ago

ffmpeg -y -f alsa -i default -f mulaw -ar 8k -ac 1 -f rtp rtp://224.168.1.33:50300 
ffmpeg version N-78646-g10fa50c Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010
  configuration: --pkg-config-flags=--static --enable-gpl --enable-libass --enable-libfreetype --enable-libx264 --enable-libpulse --enable-nonfree
  libavutil      55. 19.100 / 55. 19.100
  libavcodec     57. 24.106 / 57. 24.106
  libavformat    57. 26.100 / 57. 26.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 35.100 /  6. 35.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Guessed Channel Layout for  Input Stream #0.0 : stereo
Input #0, alsa, from 'default':
  Duration: N/A, start: 1456335505.025326, bitrate: 1536 kb/s
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Output #0, rtp, to 'rtp://224.168.1.33:50300':
  Metadata:
    encoder         : Lavf57.26.100
    Stream #0:0: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
    Metadata:
      encoder         : Lavc57.24.106 pcm_mulaw
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> pcm_mulaw (native))
SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 224.168.1.33
t=0 0
a=tool:libavformat 57.26.100
m=audio 50300 RTP/AVP 0
b=AS:64

Press [q] to stop, [?] for help
size=      49kB time=00:00:02.82 bitrate= 141.9kbits/s speed=   1x    
video:0kB audio:22kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 121.660538%

comment:3 by Sampsa Riikonen, 8 years ago

I compiled the latest vlc 3.0.0-git, tried that, and the problem disappeared.. so either (b) is a fixed bug in vlc, or the latest vlc is more tolerant for incorrect timestamps. Sorry for the spam!

Note: See TracTickets for help on using tickets.