Use correct Transport Stream standard for SRT about srthaishinkit.swift HOT 9 CLOSED

@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.

from srthaishinkit.swift.

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

from srthaishinkit.swift.

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

from srthaishinkit.swift.

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.

from srthaishinkit.swift.

@themaxsmith Did you ever figure this out?

from srthaishinkit.swift.

@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.

from srthaishinkit.swift.

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

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

from srthaishinkit.swift.

@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.

from srthaishinkit.swift.

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

from srthaishinkit.swift.