Use correct Transport Stream standard for SRT

[themaxsmith]

Unable to stream to SRS 4.0

https://github.com/ossrs/srs/
https://github.com/ossrs/srs/blob/4.0release/trunk/src/srt/ts_demux.cpp

Crashes SRS with error
srs: ./src/srt/ts_demux.cpp:415: int ts_demux::pes_parse(unsigned char*, size_t, unsigned char**, size_t&, uint64_t&, uint64_t&): Assertion 0x80 == p[pos]' failed.
`
I believe this is due to TSWriter. OBS and FFMPEG work fine so I believe it is the config in Hashinkit.
Here is the defaults for FFMPEG
https://ffmpeg.org/ffmpeg-formats.html#mpegts

I am looking into this but I would love it if someone else can also attempt to take a look at solving this.

[themaxsmith]

https://en.wikipedia.org/wiki/Packetized_elementary_stream

[themaxsmith]

https://github.com/shogo4405/HaishinKit.swift/blob/master/Sources/ISO/TSWriter.swift

[themaxsmith]

ffprobe shows this error Invalid timestamps stream=1, pts=8999, dts=11999, size=3497 throughout stream - stream 1 = video stream. also missing ts metadata service_name and serivce_provider.

[RobbieElias]

@themaxsmith Did you ever figure this out?

[themaxsmith]

@themaxsmith Did you ever figure this out?

I ended up using srt-live-server instead of srs on the server-side. It will accept the SRT output then you can use an HTTP callback to create an FFmpeg instance that generates the correct timestamps then you can send it to SRS or any type of media server.

[RobbieElias]

@themaxsmith I actually got it working by simply changing the profile level to baseline.

Example:
srtStream.videoSettings = [.profileLevel: kVTProfileLevel_H264_Baseline_3_1]

[themaxsmith]

@themaxsmith I actually got it working by simply changing the profile level to baseline.

Example:
srtStream.videoSettings = [.profileLevel: kVTProfileLevel_H264_Baseline_3_1]

Good to know there is a workaround. The only problem is that the baseline profile is significantly worse on picture quality compared to high and uses 50% more bandwidth to create a similar quality picture. Can't use it on commercial products were paying customers may be limited on bandwidth and expect a high-quality stream. It is okay where you may not have to worry about bandwidth. It is also possible that since srt standard is not well defined when it comes to the TS format that SRS follows ffmpeg default values (so does OBS) and TSWriter may be following the HLS default values. It may be fixed in the future but for now, I think the best idea is to switch it to RTMP with generated timestamps on the server-side to prevent corruption. This is what we are doing at SeasonCast for a few hundred srt streams every night using this library and we have gotten a good result from it (extremely better than RTMP). From what I learned, you want to also build in some type of adaptive bitrate handling.

[RobbieElias]

@themaxsmith I was able to find another workaround, while still using the Main or High profiles. I modified the H264Encoder.swift file to disable frame reordering in the encoder:

Change:
kVTCompressionPropertyKey_AllowFrameReordering: !isBaseline as NSObject,

To:
kVTCompressionPropertyKey_AllowFrameReordering: kCFBooleanFalse,

I'm not sure if there are any drawbacks to this, but I haven't experienced any so far.

[shogo4405]

stream.videoSettings[.allowFrameReordering] = false option is now available.
shogo4405/HaishinKit.swift#1050