HEVC Parsing about srtrelay HOT 7 CLOSED

Hi,
yeah that would be necessary, although it probably doesn't need much code.
I would say just orient on the h.264 code, but sadly it doesn't really work yet. I will have to write a good test to actually find out whats wrong about the h.264 initialization, I guess it's only a couple of bits here and there.

The initialization is also not strictly necessary. I only thought it might improve client behaviour, so it's more of a proof of concept right now. But you could just disable it by commenting out the block at

from srtrelay.

From the point to the srt-transmit demo application, does the go implementation need an extra parsing when we chunk and restream the incoming mpegts packets that included the hevc and audio package? We do not have an HEVC or H.264 parser in the original srt-transmit-live demo application. I study go for some days and would like to see how it can perform in a benchmark with multi-connections.

from srtrelay.

Hi, I am not sure what you mean. The relay code currently tries to find a h.264 keyframe if it encounters a mpegts video stream. That means a mpegts with h.265 will not work out of the box. So either the parsing could be disabled because its not strictly required or an exception for h265 could be added or the parsing is fixed and implemented for h265. However I probably won't have time to look at this before new years.

You can also answer in german if you prefer.

from srtrelay.

Hi iSchluff,

danke für die Hilfe. Wenn wir ein Standard Encoder mit HEVC in MpegTS verpacken und ich diese über die Standard SRT-Live-Transmit Applikation schicke, braucht dieser keinen H.264/ HEVC Parser um eine Server-Client Verbindung aufzubauen.

Die Codec-Struktur ist hier transparent zu dem MpegTS Container in den 188 Byte Chunks.
https://github.com/Haivision/srt/blob/master/apps/srt-live-transmit.cpp

Hier mal ein Beispiel:
./stransmit srt://192.168.1.100:1234?'mode=server' srt://192.168.1.100:1235?'mode=listener' -v

Jetzt ist es egal ob ich ein H.264 oder HEVC zu der stransmit Application sende.

Ich gebe einen Livestream mit HEVC rein und kann diesen als Client auch wieder abholen. Der Encoder hat eine GOP-Size von 25.

Übersehe ich vielleicht was?

Ich finde die GO Applikation schon sehr interesant. Sie scheint besser zu performen als die NODEJS Version.

Frohe Weihnachten.

from srtrelay.

Hi rebotnix,
Das ist richtig, man braucht prinzipiell keinen Parser. Aktuell versuche ich allerdings im go mit dem H264-Parser den Einsprungpunkt für den Client zu finden und direkt mit einem Keyframe anzufangen. Das funktioniert allerdings im Moment noch nicht korrekt.
Für h265 geht es im Moment nicht, weil ich noch keine Unterscheidung im mpegts dafür eingebaut habe und das die gleichen Table IDs verwendet.

Wie du schon sagst kann man aber auch einfach das Parsing komplett abschalten, vllt. baue ich dafür nochmal eine Option ein. Im Moment schaut das Relay nach ob der Content MpegTS ist und schaltet nur dann den Parser zu.

Frohe Weihnachten,
Anton

from srtrelay.

Hi Anton,

danke für die Antwort. Beide Modies ergeben einen sinn. Wenn ein Encoder GOP-Size 250 hätte und wir mit einem Client zwischen dem nächsten Keyframe springen würden, hättest Du ein niedrige Latenz vom Client. Mein Erfahrung arbeiten die meisten Encoder mit einer GOP von 25 oder kleiner. Wenn Du den Modie ohne MpegTS einbaust, teste ich das gerne mit allen Hard und Software Encodern die ich hier habe. Wie ich übrigens im ersten Benchmark testen konnte, ist deine GO Version des Relays ca. 30% weniger CPU hungrig in einem Thread als die NODEJS und nur 2% langsamer als die Native C Version von der offiziellen Demo Transmit App. Letztes läßt sich aber nicht vergleichen, weil hier nur eine Client zu testen gibt aufgrund der Single Socket Limitierung der Demo. Werde auch noch mal mit den anderen Engines es testen.

VG
Gary

from srtrelay.

Hi Gary, Ich habe das syncing jetzt per default erstmal abgeschaltet und eine Option dafür eingebaut. Damit kann ich jetzt ohne weiteres HEVC relayen. Performancetechnisch gibt es eigentlich noch keine Optimierungen, denke da könnte man in der Zukunft aber noch mehr machen.
VG Anton

from srtrelay.