注意：不提供以下信息的Issue会被直接删除(Please follow issue template, or we will delete it)
注意：咨询和讨论请提交到SRS星球(Please ask question at) http://bbs.ossrs.net
描述(Description)
描述你遇到了什么问题(Please description your issue here)
- SRS版本(Version):
4.0.178 - SRS的日志如下(Log):
xxxxxxxxxxxx- SRS的配置如下(Config):
listen 1940;
max_connections 1000;
daemon off;
srs_log_tank console;
srs_log_level verbose;
http_server {
enabled on;
crossdomain off;
listen 8040;
dir ./objs/nginx/html;
}
http_api {
crossdomain off;
enabled on;
listen 1945;
}
stats {
network 0;
}
rtc_server {
enabled on;
listen 9999;
# @see https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#config-candidate
candidate 178.76.25.21;
}
vhost webrtc {
rtc {
enabled on;
rtc_to_rtmp on;
}
http_remux {
enabled on;
mount /[app]/[stream].flv;
}
}重现(Replay)
重现Bug的步骤(How to replay bug?)
Push WebRTC to serverStart playing FLV in Chrome with Flv.JS
期望行为(Expect)
描述你期望发生的事情(Please describe your expectation)
Continuous playback, no pause
Some bugs
- First, when downloading (stream.flv from SRS server), the server gives a 404 error, if you repeat it, the download will start. If you stop downloading and start snoring, then the server again gives a 404 error, after 5 times the server sends the file successfully
- The video is interrupted approximately every 5 seconds. At the same time, errors like
`
net::ERR_INCOMPLETE_CHUNKED_ENCODING
[IOController] > Loader error, code = undefined, msg = Fetch stream meet Early-EOF
[TransmuxingController] > IOException: type = UnrecoverableEarlyEof, code = undefined, msg = Fetch stream meet Early-EOF
...
reload flv
....
net::ERR_FAILED 404
...
reload flv again
...
net::ERR_INCOMPLETE_CHUNKED_ENCODING 200
[IOController] > Loader error, code = undefined, msg = Fetch stream meet Early-EOF
[TransmuxingController] > IOException: type = UnrecoverableEarlyEof, code = undefined, msg = Fetch stream meet Early-EOF
...
reload
...
[MSEController] > MediaSource onSourceOpen
[FLVDemuxer] > Parsed AudioSpecificConfig
[FLVDemuxer] > Parsed AVCDecoderConfigurationRecord
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
[FLVDemuxer] > Found another AVCDecoderConfigurationRecord!
...
infinite
`
3条答案
按热度按时间ohtdti5x1#
It's because the SPS/PPS changes every N seconds.
SRS can not fix it because it's the codec gap between WebRTC and RTMP.
However, there is a workaround, please use FFmpeg to transcode RTMP stream:
webrtc://localhost/live/livestreamrtmp://localhost/live/livestream_ffmpeghttp://localhost:8080/live/livestream_ffmpeg.flvIs this solution OK?
xmd2e60i2#
i was able to transcode
The problem was in the rtmp ports. In the config I changed the default rtmp port 1935 to 1940 (listen). The problem is that SRS still uses port 1935 instead 1940.
Template doesn't work (I am currently using version SRS 2, everything is fine there)
Check this moment
Transcoding didn't solve the problem.
I researched a similar problem a year ago with freezing a video received from a WebRTC stream (project Intel OWT). I started debugging chrominum and came to the conclusion that the video freezes due to the SPS\PPS (as it turned out, there were other bugs along the way). At the moment, I successfully send a WebRTC stream to the server (OWT), converted into rtmp and distributed through the SRS into HTTP-FLV, HLS etc.
Recently I noticed and was glad that you managed to make friends with WebRTC, but unfortunately the current implementation is not suitable for production
Take a look at this thread, it discusses a problem similar to ours.
https://bugs.chromium.org/p/chromium/issues/detail?id=1111273#c170
In particular, pay attention to
https://bugs.chromium.org/p/chromium/issues/detail?id=1111273#c170
Perhaps your ID changes in SPS\PPS. The main thing: do not send SPS\PPS unnecessarily, this will reset the configuration in the players and the video will freezes. Send SPS\PPS only when the configuration is changed (width, height, etc).
I have uploaded sample videos.
https://github.com/thegobot/srs/raw/master/webrtc_from_http_remux.flv
https://github.com/thegobot/srs/raw/master/html5_from_rtmp.flv
os8fio9y3#
I found a place in the code, SrsRtmpFromRtcBridger::packet_video_key_frame
srs/trunk/src/app/srs_app_rtc_source.cpp
Line 1486 in e222f0d
| | payload.write_1bytes(0x0); // avc_type: sequence header |
Always mux as a AVCSequenceHeader(type=)0, instead of NALU (type=1 в flv format). This is not true. I'm not strong in c ++, I fixed similar code in java, but I can't do it here. If you find the strength, correct this code, there are actually 10 lines to write
Well, I on the client (chrome player) then ignore the second header, just skip it if it comes again from the server. That's how it works.