issue with a stream already used

[Nic01as]

Hello, Your server is really great, I use it quite a lot! I just have one issue: sometimes, I can't read the stream provided by Ateme or other encoders because I am receiving some wrong streams descriptions. I noticed that this occurs when the streamid has already been used in the past. I'm sending 1 mpegts feed with 1 audio stream and 1 video stream. With ffprobe, I get this:

Input #0, mpegts, from 'srt://XXXX':
  Duration: N/A, start: 12937.733333, bitrate: N/A
  Program 1
    Stream #0:0[0x101]: Video: - (Main) ([27][0][0][0] / 0x001B), 0x0 [SAR 1:1 DAR 16:9]
    Stream #0:1[0x102]: Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 0 Hz
    Stream #0:2[0x1]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:3[0x2]: Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp

My player doesn't understand the feed correctly because there are some 'fake' and wrongly described streams (one or two) without video size or audio sample rate, in addition of the correct and 'real' streams. If I stop and resend my feed with the same configuration with another streamid, everything works just find and this is what I get from ffprobe:

Input #0, mpegts, from 'srt://XXXX':
  Duration: N/A, start: 12937.733333, bitrate: N/A
  Program 1
    Stream #0:0[0x101]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1[0x102]: Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp

I've set the idle_streams_timeout property at 10 in my configurations and waited more than 1 hour between the two connections.

thanks for your help !

[Nic01as]

Same issue today, now I make some capture.

First, My encoder is in autoreconnect mode, send 1 audio et 1 video streams. if I restart SRT server, my ateme encoder reconnect automatically.

My encoder publish and I can't read it, with ffprobe, I have that :

Now I restart server, after reconnexion, I have that :

Do you have an idea ?

[Edward-Wu]

hi, Nic01as It seems to like there are duplicated stream info in the playing stream. And when encoder auto-reconnected, which changed the video pid from 0x100 to 0x101. Because SLS saved the stream info such as sps and pps at the begining of pushing stream and inserted the stream info in the player stream. In the normal case if the stream info is not changed when encoder auto-reconnected the player will work normally.

So please update the following two functions in SLSMapData.cpp to test, in this code the old stream info was eased when encoder auto-reconnected. If this code can resolve this issue please tell me , I 'll update the github.

thank you.

---

int CSLSMapData::remove(char *key) { int ret = SLS_ERROR; std::string strKey = std::string(key);

CSLSLock lock(&m_rwclock, true);

//remove the ts info
std::map<std::string, ts_info *>::iterator item_ti;
item_ti = m_map_ts_info.find(strKey);
if (item_ti != m_map_ts_info.end()) {
    ts_info *ti = item_ti->second;
    if (ti) {
        delete ti;
    }
    m_map_ts_info.erase(item_ti);
}

//remove the array data
std::map<std::string, CSLSRecycleArray *>::iterator item;
item = m_map_array.find(strKey);
if (item != m_map_array.end()) {
    CSLSRecycleArray * array_data = item->second;
    sls_log(SLS_LOG_INFO, "[%p]CSLSMapData::remove, key='%s' delete array_data=%p.",
            this, key, array_data);
    if (array_data) {
        delete array_data;
    }
    m_map_array.erase(item);
    return SLS_OK;
}
return ret;

}

void CSLSMapData::clear() { CSLSLock lock(&m_rwclock, true); std::map<std::string, CSLSRecycleArray >::iterator it; for(it=m_map_array.begin(); it!=m_map_array.end(); ) { CSLSRecycleArray array_data = it->second; if (array_data) { delete array_data; } it ++; } m_map_array.clear();

std::map<std::string, ts_info *>::iterator item_ti;
for(item_ti=m_map_ts_info.begin(); item_ti!=m_map_ts_info.end(); ) {
    ts_info *ti = item_ti->second;
    if (ti) {
        delete ti;
    }
    item_ti ++;
}
m_map_ts_info.clear();

}

[Nic01as]

Ok, I make change ! :)

I try that and back to you

[RichardCowart]

I am having the same exact issue. I will let you know when I test.

[RichardCowart]

I have tested the recommended solution and it works properly now. There are no previous stream stream parameters being forwarded in the bitstream now.

[Edward-Wu]

great job! thank you.

[VideoFX]

I am still experiencing this issue. Is the fix confirmed yet?