When converting RTMP to HLS and generating TS files, there is a possibility of incorrect determination between Annex B and IBMF, which can result in a distorted playback of the generated TS files.

[xiaoninger]

srs_avc_startswith_annexb determines that if it encounters 000001, it is considered to be in annexb format. It could also be in ibmf format, but the length happens to be the same. For example, 00000122 could possibly be in ibmf format, with a length of 290 bytes.

TRANS_BY_GPT3

[winlinvip]

Make sense.

[Antony-An]

Have you ever encountered the annexb format in rtmp?
Is it possible to use the annexb format only when consecutive n frames are annexb? Are there any other better methods?
I feel like no matter what we do, there will always be a possibility of misjudgment.

TRANS_BY_GPT3

[winlinvip]

SRS 5.0, add a new configuration to specify guessing IMBF first:

vhost __defaultVhost__ {
    publish {
        # When parsing SPS/PPS, whether try ANNEXB first. If not, try IBMF first, then ANNEXB.
        # default: on
        try_annexb_first on;
    }
}

Today, a friend encountered a screen flickering issue, and it was found that there was an extra byte in the TS, causing an abnormal GOP.

TRANS_BY_GPT3