Hi
mit der 0.62er klappt bei mir die ggrab-Engine auch ohne Artefakte (udp, prio high) - bei nem 1minuten test ... bei den Versionen davor (glaub mit der 0.60 hab ich zuletzt getestet) gabs nur artefakte - aber die Version spinnte bei MIR ja total ....
Jetzt die Frage: rein aus technischen Hintergrund ist ggrab da das UDP-Protokoll verwendet wird, zum Streamen doch eigentlich viel besser geeignet als die wingrabbengine die HTTP/TCP nutzt (was eigentlich net zum realtime-streamen gedacht ist und eigentlich viel Datenmüll [in diesem Fall] produziert) ... nur trotzdem wird http/tcp wohl bevorzugt genommen - warum? Hat die ggrab-engine nen hacken? andere Probleme die udp "untauglicher" machen als tcp? Spuckt JtG unter nutzung von ggrab auch fehlermeldungen aus wenn welche kommen? Resyncs? Jitter? Verlorene Frames?
Hab derzeit Probleme mit den Bitrate-Königen der ARD und des ZDFs .... zig tausend jitter-Meldungen (750kb log in 2,5min) und irgendwann dann so ne 3-4 Zeilen Meldung das was verloren gegangen (meist in der 11. Minute) ist - die Prem Plus-Sender produzieren das übliche 3kb Log ohne Fehler ...
Nutze derzeit wingrabengine und Programmstream (0.62b)
Bis denne
Wulfman
ggrab oder wingrab-Engine?
Okay, nochmal 
UDP ist schon ne geile Angelegenheit, aber das TCP nur Datenmüll prodziert ist Unsinn.
Durch TCP ist der Netzwerkktraffic höher, weil die Pakete bestätigt werden.
ggrab hat den "Haken", dass die Weiterverarbeitung des Streams manchmal sehr problemtaisch bis unmöglich ist.
Sämtliche Meldungen von ggrab werden auch ausgegeben. Allerdings gibt es bei ggrab keine ReSyncs, denn dass ist die Philosophie von ggrab. Der Stream wird so wie er kommt gemuxt und geschrieben. Und aus genau diesem Grund, gibt es eben Stress mit der Weiterverarbeitung.
Nach der Aussage von Gandalfx, will er diese Philosopie aber nochmal überdenken und evtl. eine neue ggrab schreiben.
Levi
UDP ist schon ne geile Angelegenheit, aber das TCP nur Datenmüll prodziert ist Unsinn.
Durch TCP ist der Netzwerkktraffic höher, weil die Pakete bestätigt werden.
ggrab hat den "Haken", dass die Weiterverarbeitung des Streams manchmal sehr problemtaisch bis unmöglich ist.
Sämtliche Meldungen von ggrab werden auch ausgegeben. Allerdings gibt es bei ggrab keine ReSyncs, denn dass ist die Philosophie von ggrab. Der Stream wird so wie er kommt gemuxt und geschrieben. Und aus genau diesem Grund, gibt es eben Stress mit der Weiterverarbeitung.
Nach der Aussage von Gandalfx, will er diese Philosopie aber nochmal überdenken und evtl. eine neue ggrab schreiben.
Levi
Hi
... wenn die Box so nen 128MB-Cache hätte, wär das aber schon interessant
nur wie bekommt man den darein *GGGG*
Bis denne
Wulfman
Jo das meinte ich mit Datenmüll "in diesem Fall" ... bestätigung der Pakete bei nem Stream sind müll - wenn nen paket nicht angekommen ist, gibt es keine möglichkeit dieses Paket nochmal anzufordern - weg ist weg.UDP ist schon ne geile Angelegenheit, aber das TCP nur Datenmüll prodziert ist Unsinn.
Durch TCP ist der Netzwerkktraffic höher, weil die Pakete bestätigt werden.
... wenn die Box so nen 128MB-Cache hätte, wär das aber schon interessant
nur wie bekommt man den darein *GGGG* Bis denne
Wulfman