Opened 9 years ago
Last modified 9 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 , 9 years ago
Component: | ffmpeg → undetermined |
---|---|
Keywords: | timestamp multicast removed |
comment:2 by , 9 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 , 9 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!
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.