Bizare behaviour with RTP mpegts sources
|Reproduced by developer:
|Analyzed by developer:
Summary of the bug:
I'm transcoding a bunch of SD sources from SPTS mpegts transported on different multicast addresses with RTP on port 5530. (VBR h264 video, mp2 audio)
When I transcode the first source from mcast IP1:5530 the output is sort of OK (occasional green patches and false reporting of unsupported source features)
Once I run a second ffmpeg instance to transcode source IP2:5530 the second instance is not ingesting IP2 content but IP1 and both instances start to interfere and they don't even come to a state to start transcoding.
It's bizare that even two ffplay instances tuned to different sources play back the same content!
I tried playing back with vlc and there is no such problem.
% ffmpeg -y -f mpegts -i rtp://@18.104.22.168:5530 -threads 0 -acodec libfdk_aac -ab 64k -ar 44100 -vcodec libx264 -vprofile baseline -vlevel 1.3 -x264opts fps=25:keyint=100:bitrate=200 -s 320x240 -f mpegts udp://22.214.171.124:5004?pkt_size=1316 I uploaded a sample of my mpegts on: ftp://upload.ffmpeg.org/MPlayer/incoming/ts__sample.ts ffmpeg version 2.1.git built on Jan 30 2014 12:22:30 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.
Change History (10)
comment:1 by , 10 years ago
|Bizare behaviour with RTP mpegts sources, → Bizare behaviour with RTP mpegts sources