Test Movieplayer mit "(c) Wabber-Queue"

Beitrag von **kroki** » Montag 10. April 2006, 09:20

@all

Die Werte 24 -128 kommen aus dem genpsi. Wenn ich das richtig interpretiere nimmt genpsi einen Mindestwert von 24 und einen Max Wert von 128. Also wenn man auserhalb dieser Werte liegt wird nur min bzw. max genommen.

Ich will das genpsi auch nicht abschaffen, sondern nur die "WABBER-Header" nicht schreiben und auch nicht auswerten......

Kroki

Beitrag von **Tommy** » Montag 10. April 2006, 10:26

@kroki: Du solltest Dich am besten mit gmo "zusammensetzen". Wir wissen ja nicht 100pro was er so vorhat (auch in Bezug auf streamer). Nicht das Ihr Euch gegenseitig ein Bein stellt. Ich finde es auf jeden Fall toll das Du dich kümmerst

Beitrag von **petb** » Dienstag 11. April 2006, 13:05

@gmo18t
Hi,
ich habe eine Frage.

Habe heute einiges probiert.
Unter anderem habe ich gleichzeitig, mit 4 Boxen aufgenommen und auf 2 Boxen abgespielt.

Dabei hat der MP bei hochratigen Aufnahmen immer wieder gepuffert.
Bei niederratigen nur selten.
Das war auch zu erwarten.

Aber leider passiert es immer wieder das er nach dem puffern zwar den Ton einwandfrei bringt, aber das Bild nicht sauber weiterläuft, stockt oder steht, etc.

Hast du da vieleicht eine Idee, warum das so ist ?
Danke.

@kroki
@gmo18t

Habt ihr mal kurz miteinander gesprochen ob kroki die GUI etc. so ändern kann, das wir die Größe des Puffers selbst in der GUI einstellen können ?

Denn allein schon das der Puffer vorhanden ist, verbessert mein oben genanntes Szenario im Vergleich zu früher.

Da bin ich mal gespannt wie es aussieht wenn ich den Puffer größer einstellen kann.
Denn Aufnahmefehler hab ich keine bekommen.
Der Server blockt immer nur kurz den Ausgabestrom.
(Der switch kann nicht mehr blocken, 2 Boxen die abspielen sind in einem anderen/eigenen netzwerksegment als die aufnehmenden Boxen siehe hier)

Danke

bye
PetB

Beitrag von **gmo18t** » Mittwoch 12. April 2006, 12:41

petb hat geschrieben:@gmo18t
...
Aber leider passiert es immer wieder das er nach dem puffern zwar den Ton einwandfrei bringt, aber das Bild nicht sauber weiterläuft, stockt oder steht, etc.

Hast du da vieleicht eine Idee, warum das so ist ?
Danke.

Das "Einfrieren" beim Puffern basiert auf dem gleichen Prinzip wie "Pausieren" mit Taste Gelb. Also, wenn du diesen Effekt auch desweilen bei der "Pause/Play"-Funktion hast, sind wir grundsätzlich wieder beim Thema "AVIA-Firmware".
Da ich nur "600er"-Sagem Kabel mit b22er-Ucode am Laufen habe und damit solche Probleme nicht auftreten, bin ich auch nicht in der Lage, einen "workaround" dafür zu finden, weil ich die Problematik nicht nachstellen kann ...
Evtl. ist "das Nachpuffern" bei dir aber sehr kurz, so daß der AVIA sich dadurch irgendwie "verhudelt" (das könnte man evtl. noch feintunen).
Außerdem verwende ich original Treibercode aus dem CVS und keine Patches (wie es z.B. welche für AVIA 500 gibt).
Das alles gilt jetzt aber nur für Streams mit MP2-Audio. Bei AC3 wird das "Nachpuffern" anders gehandelt und funktioniert bei mir auch nicht immer sauber, aber dazu hab ich noch keine Idee.

@kroki
@gmo18t

Habt ihr mal kurz miteinander gesprochen ob kroki die GUI etc. so ändern kann, das wir die Größe des Puffers selbst in der GUI einstellen können ?

Ich hatte zwar in diesem Thread schon einige Infos zu dieser Thematik geschrieben, aber fasse das hier nochmal zusammen:

Es gibt zwei Parameter, die den Füllstand des Puffers steueren (nSegsMax und nSegsOpt), wobei der Puffer immer nur bis zu "nSegsOpt" gefüllt wird !!! Voller kann er dann nur während des Abspielens werden, wenn die Bitrate < der max. Möglichen ist (je länger umso besser).

"nSegsOpt" ist im aktuellen Coding auch (noch) nicht konfigurierbar und wird normalerweise auf 3/4 von "nSegsMax" gesetzt wobei aber zusätzlich noch eine oberer Begrenzung von "N_SEGS_OPT_MAX" (=24) zieht, damit bei großen Werten für "nSegsOpt" das Pufferfüllen nicht zu lange dauert.

Mit dem modifizierte "genpsi" kann im Moment auch nur der Wert für "nSegsMax" beeinflußt werden. Insgesamt ist das Coding aber schon dafür ausgelegt, auch "nSegsOpt" einzustellen zu können.
Das Auswerten der "wabber"-Packets im MP sollte aber in keinem Fall entfernt werden, da es ja nur greift, wenn die entsprechenden Packets im Stream vorhanden sind.

Für einen per GUI konfigurierbarern Puffer wäre evtl. folgende Vorgehensweise mit wählbarer Stategie sinnvoll, z.B
"default mit festen Werten" (also so wie es jetzt ist),
"per stream" (die stream packets werden ausgewertet) und
"per configfile" (sowohl "nSegsMax" als auch "nSegsOpt" werden direkt eingestellt).
Das Ganze noch versehen mit einer Prioritätsfolge "per configfile -> per stream -> default" und - voila !

Im MP Coding müßte also grundsätzlich das Ermitteln des Wertes für "nSegsOpt" (in TPtrQueue::TPtrQueue) und das Setzen des Anfangswertes für "nSegsMax " (in mp_playFileMain()) überarbeitet werden. Hauptarbeit bleibt aber der GUI-Kram

Die Größe des Puffers ergibt sich grundsätzlich aus "nSegsOpt * SIZE_QUEUE_SEG" , wobei für jedes Segment ein Extra Speicherbereich allokiert wird. Dies hat einerseits den Vorteil, daß auch bei stark fragmentiertem Speicher das Anlegen eines recht großen Puffers möglich ist und andererseits bei Speichermangel auch durchaus ein Puffer mit weniger als "nSegsOpt"-Segmenten angelegt wird.
Deshalb muß unbedingt nach dem Anlegen des Puffers die wirkliche Anzahl benutzter Segmente auf "nSegsOpt" reflektiert werden, d.h. es könnte dann nochmel eine entspr. Anpassung von "nSegOpts" nötig sein! (siehe auch TPtrQueue::TPtrQueue).

- GMO -

Beitrag von **Torsten73** » Mittwoch 12. April 2006, 20:38

@gmo18t:
Audioslyer hat mal geschrieben, das man die Pausen & Sprungproblematik beim Avia 500er Patch dadurch beheben würde, dass man den Avia nach der Pause lediglich resetten bzw neu starten müßte. Ich denke auch das PetB hier das Problem hat (nutzt auch den Patch, wenn ich nicht irre)

Wäre das mal ein Test Wert?

Dann nochmal zum Fileende (ich weiß ich nerve...) Ich würde wirklich gerne wieder meine Files bis zum Ende schauen können... und da bin ich nicht der einzige?

@kroki:
wie schaut es mit der CVS Reife Deines Menüs aus? Irgendwelche Pläne?

Thx
Torsten

Beitrag von **petb** » Mittwoch 12. April 2006, 22:22

JA, ich habe den JTG Snap vom 31.03. aktiv.
Da denke ich ist der Avia Patch drinne.

Aufgefallen ist mir, das in einer der vorherigen Versionen wo der Patch auch drinne war, dieses Problem nicht aufgetaucht ist, aber das springen nicht so sauber ging.

Ich glaube auch danach einen beitrag von gmo18t gelesen zu haben wo er sich mit der sprungproblematik befasste und sagte er hätte da was mit reset, stop oder so ähnlich bzgl. des avia geändert ?

Ich weis es nicht 100%tig aber es könnte zeitlich zusammen passen.

Vieleicht ist das so eine Sache das wir mit einem der Probleme leben müssen.

Entweder funktioniert der MP sauber und es knistert oder knarzt oder wir nutzen den Patch und beim Springen geht es nicht so sauber....

Gestern hat Riker einen neuen Snap online gestellt.
Ich weis nur nicht was da jetzt drinnen ist oder nicht.

Aber vieleicht kriegt gmo18t das ja irgendwie in den Griff.

Bye
PetB

Beitrag von **gmo18t** » Donnerstag 13. April 2006, 10:58

Torsten73 hat geschrieben:@gmo18t:
Audioslyer hat mal geschrieben, das man die Pausen & Sprungproblematik beim Avia 500er Patch dadurch beheben würde, dass man den Avia nach der Pause lediglich resetten bzw neu starten müßte. Ich denke auch das PetB hier das Problem hat (nutzt auch den Patch, wenn ich nicht irre)

Wäre das mal ein Test Wert?

sowas kann ich nicht testen, da ich keine 500er Box habe ! Und in den anderen Fällen funktioniert das ja prima, so daß eine Änderung gleich wieder den Wunsch nach Konfigurierbarkeit und darüberhinaus auch das übliche "Gezeter" aufkeimen läßt.

Dann nochmal zum Fileende (ich weiß ich nerve...) Ich würde wirklich gerne wieder meine Files bis zum Ende schauen können... und da bin ich nicht der einzige?

das Verhältnis "Aufwand" zu "verfügbarer Zeit" passt für mich leider nicht. Aber ein einfacher workaround dafür wäre z.B.

Code: Alles auswählen

head -c1651392 movie.ts >> movie.ts

damit verlängerst du dein movie file (movie.ts) um Daten, die sowieso nie abgespielt werden, aber dadurch wird der Film wirklich bis zum Ende laufen

... ist halt leider der Preis dafür, daß man nicht selbst proggen kann/will.

- GMo -

gmo18t hat geschrieben:
Torsten73 hat geschrieben:@gmo18t:
Audioslyer hat mal geschrieben, das man die Pausen & Sprungproblematik beim Avia 500er Patch dadurch beheben würde, dass man den Avia nach der Pause lediglich resetten bzw neu starten müßte. Ich denke auch das PetB hier das Problem hat (nutzt auch den Patch, wenn ich nicht irre)

Wäre das mal ein Test Wert?
sowas kann ich nicht testen, da ich keine 500er Box habe ! Und in den anderen Fällen funktioniert das ja prima, so daß eine Änderung gleich wieder den Wunsch nach Konfigurierbarkeit und darüberhinaus auch das übliche "Gezeter" aufkeimen läßt.

Nun das verstehe ich, heißt aber nicht, dass es dafür keine Lösung gibt. Ich stelle mich gerne bereit vorhab für Dich zu testen. Zumindest habe ich Noka Avia500&600er.
Und was sinnvoll ist konfigurierbar zu machen und was nicht, da kann man zwar sich drüber unterhalten aber es liegt letztendlich an Dir was Du als Parameter zur Verfügung stellst.
Ich wage mal die These, dass es viel mehr Avia 500er User als andere gibt, wovon die meisten den Patch mittlerweile nutzen und mit diesen Problemen zu kämpfen haben.
Du hast im Code so vieles verbessert ohne es testen zu können (kann ich ja mit der fehlenden AVA500 Box bei Dir genauso sehen...), da sollte ein AviaRestart nach der Pause und springen nicht das Problem sein. Und wenns nicht hinzubekommen ist, das werden wir damit leben müssen. Es ist doch nur ein Versuch...

Ich wundere mich darüber, das Du in diesem Fall so einfach die Flinte ins Korn wirfst. So bist Du doch sonst nicht. Oder haben die Konfig-Schreier Dich schon unterwandert

Sollte sich das umsetzen als aufwändig darstellen, so habe ich nichts gesagt...

Der "Head" Tip funktioniert in der Konsole auch?

Cu
Torsten

Beitrag von **petb** » Freitag 14. April 2006, 00:25

Hallo,

Nokia 500:
Wie bereits von euch vermutet, bei mir ist das mit den Bildhängern beim puffern vorbei, wenn der avia Patch auf aus ist.
AUCH funktioniert der Puffer viel besser wenn der Patch aus ist.

Habe eben gleichzeitig, 5 x mit je einer rate knapp über 8000 aufgenommen und dabei noch einmal eine Aufnahme mit einer Rate knapp über 8000 angeschaut. (1 Nic, 1 Switch)
Das ging mit aktiviertem patch fast garnicht

So aber klappt es mit seltenem Puffern.
Das gleiche File mit -sm 100 gepatcht puffert etwas weniger.
Das File Zweimal abspielen geht auch mit ein klein wenig öfter puffern.
Aber auch da wirkt es nicht soooo störend.
Das gleiche File auf einer Box mit Image (JTG Okt 05) ruckelt ständig.

In dem Sinne, danke für den Einbau des Puffers.

By the Way, der neue Switch über den ich geschrieben habe er wäre klasse,....gilt leider nur wenn die Raten nicht so hoch sind, sonst geht er auch in die Knie.

Hoffe ich hab mich jetzt nicht wieder selbst reingelegt

Bye
PetB

Beitrag von **kroki** » Freitag 14. April 2006, 13:47

@all

So hab mich heute mal an die GUI-Rangesetzt:

Auswahl : 1:Default, 2:Config, 3:Stream->Default, 4:Stream->Config

Werte für Max-Segments und für Opt-Segments können gesetzt werden.

Ich halte mich jetzt noch an die Limits die von gmot vorgesehen wurden.

@gmot
Wie soll ich mit den OPT-Segments verfahren, diese rechnest du ja aus den Max-Segments aus (3/4 von Max) und max 24. Ich will die eigentlich in der der Config frei geben so dass man damit richtig experimentieren kann...

Diff kommt vielleicht heute noch ....

Kroki

Beitrag von **gmo18t** » Freitag 14. April 2006, 14:31

kroki hat geschrieben: @gmot
Wie soll ich mit den OPT-Segments verfahren, diese rechnest du ja aus den Max-Segments aus (3/4 von Max) und max 24. Ich will die eigentlich in der der Config frei geben so dass man damit richtig experimentieren kann...

würde da einfach in "TPtrQueue::TPtrQueue" zwei Fälle unterscheiden

1) "pCtx->nSegOpts == 0" => berechnen wie bisher
2) "pCtx->nSegsOpts > 0" => so nehmen wie er ist

... aber mach mal das Coding fertig, ich schau mir's dann mal an !

- GMo -

Beitrag von **kroki** » Freitag 14. April 2006, 17:52

@all

So, ich habe fertig ....

Einstellungen für die Player-Queue unter Einstellungen->Movieplayer,
Einstellung für den Wabber-Header beim Aufnehmen unter Einstellungen->Aufnahme->Directrecording.

Es wird vor der Aufnahme der Wabber-Header ins File geschrieben.

Beim Movieplayer kann man jetzt entscheiden von wo die Queue-Einstellungen genommen werden sollen.

Default: Die von gmot vorgegebenen Default-Werte 24/18

Config: Die in der Gui eingegebenen Werte, hier wird von gmot aber geprüft ob diese überhaupt gehen .......

Stream/Default : Erst die Werte aus dem Stream, wenn nicht vorhanden d ann Default

Stream/Config : Erst die Werte aus dem Stream, wenn nicht vorhanden d ann Die Gui-Werte

Hier das Diff:
http://s39.yousendit.com/d.aspx?id=1RFF ... TUY8HRQPAW

Gruß Kroki

Beitrag von **mb405** » Freitag 14. April 2006, 18:01

danke kroki

ist das die erweiterung des ersten patches von dir ?
den hab ich schon drin.

Beitrag von **kroki** » Freitag 14. April 2006, 18:32

Joop, da ist der erste Patch mit drinnen ...

Kroki

Beitrag von **mb405** » Freitag 14. April 2006, 19:11

ok danke
ich habs grad reingebastelt. mal sehn wies läuft.

Beitrag von **Tommy** » Samstag 15. April 2006, 07:25

nach dem patchen läuft newmake nicht mehr durch - bleibt bei genpsi hängen weil eine regel fehlt

Beitrag von **dietmarw** » Samstag 15. April 2006, 09:24

tja.. die nachteile mehrgleisiger entwicklung..

Beitrag von **mb405** » Samstag 15. April 2006, 09:38

ist klar, das es hängen bleibt, wenn genpsi.c durch genpsi.cpp ersetzt wird.

Beitrag von **Tommy** » Samstag 15. April 2006, 10:50

mb405 hat geschrieben:ist klar, das es hängen bleibt, wenn genpsi.c durch genpsi.cpp ersetzt wird.

mal dumm gefragt - in welchem makefile muß ichs dann ändern bzw. @Barf - kannst Du das anpassen?
Oder kann ich einfach genpsi.cpp wieder umbenennen in genpsi.c ohne das der kompiler durchdreht?

Beitrag von **Tommy** » Sonntag 16. April 2006, 08:03

kann ansonsten evtl. jm d ein binary zur verfügung stellen? Wenns keiner testen kann bringts uns ja auch nicht weiter

Beitrag von **mb405** » Sonntag 16. April 2006, 09:24

das ist kein binary, sondern wird eincompiliert in die sourcen. nix mit dbox2_genpsi, wie in den yadi images. hab ich auch "blöd" geschaut am anfang.

Beitrag von **Tommy** » Sonntag 16. April 2006, 10:52

mb405 hat geschrieben:das ist kein binary, sondern wird eincompiliert in die sourcen. nix mit dbox2_genpsi, wie in den yadi images. hab ich auch "blöd" geschaut am anfang.

...naja und resultat ist doch eine neutrino? Die kann man doch als binary alternativ starten oder bin ich da falsch?

Beitrag von **denis4er** » Montag 17. April 2006, 17:40

Super es geht weiter mit dem MP!

Gibt es eine Möglichkeit den aktuellen Stand zu testen?

Gruß

Beitrag von **Tommy** » Montag 17. April 2006, 19:35

denis4er hat geschrieben:Super es geht weiter mit dem MP!

Gibt es eine Möglichkeit den aktuellen Stand zu testen?

Gruß

ne es hängt - zumindest bei mir, bis es ins cvs eingecheckt wird. Der diff oben löppt nicht mit newmake - habe ihn bei mir wieder reverted. Ich weis nicht warum genpsi.c zu genpsi.cpp geworden ist

bzw warum es dann in den makefiles klemmt bzw wie ichs in newmake beheben kann. Hätte den aktuellen Stand sehr gerne über Ostern ausgiebig getestet

vermutl. hats die dunkle Seite schon im "Osterimage"

Hallo, wie sieht es denn mit Korki's Patch aus? Läuft der?
Wenn ja könnte man das ins CVS einchecken?

Gruß Michael