Eingeblendete Zeit läuft während Pause im Movieplayer weiter

[hotlineshocker]

Hallo dBoxer,

sofern ich bei der Wiedergabe mit dem Movieplayer mittels der d-box Taste die Abspieldauer einblende und dann
per gelbe Taste die Wiedergabe pausieren lasse, schreitet die eingeblendete Abspieldauer leider weiter voran.

Lasse ich nun die Wiedergabe per erneuter gelber Taste fortsetzen, erfolgt auch nicht wenigstens jetzt eine
Korrektur der eingeblendeten Abspieldauer. Die eingeblendete Abspieldauer schreitet nun auch wieder
unverändert um die zwischenzeitlich hinzugezählte Zeit der Pause voran.

Wenn ich die Abspieldauer erst während der Pause einblenden lasse, verhält es sich ebenfalls wie bereits
beschrieben.

Bei der Wiedergabe mit dem Movieplayer hat die einblendbare Zeit also lediglich bis zur ersten Inanspruchnahme
einer Pause einen totalen Bezug zu der wiedergegebenen Konserve.

Wie sich die eingeblendete und wohlmöglich durch Pausen ergänzte Zeit bei der Anlage von Markierungen bzw.
Bookmarks niederschlägt, habe ich erst gar nicht mehr näher untersucht.

Zusätzlich führt während der Wiedergabe das Anzeigen der Infobar z.B. mittels ?-Taste bereits zum einfrieren
der eingeblendeten Wiedergabezeit, um dann aber natürlich anschließend nach dem Erlöschen der Ifobar
sprungartig korrigiert fortgesetzt zu werden. Aber auch hier führt das Pausieren während der Anzeige der Infobar
zur anschließenden Anzeige einer um die Pausenzeit ergänzten Wiedergabedauer.

Was nun?

GoIP

dodi

[seife]

schicke einen Patch der das fixt.

[hotlineshocker]

Hallo seife,

in jedem Fall schon einmal vielen Dank für deinen prompten Feedback.

Sorry, aber wie habe ich deinen Post nun genau zu interpretieren?

Meintest du: "(Ich) schicke einen Patch, der das fixt."
Oder meintest du: "schicke (du) einen Patch, der das fixt."

GoIP

dodi

[seife]

Ich meinte, dass du einen Patch schicken sollst, der das fixt. Ich schau mir den movieplayer-Code freiwillig nicht mehr an ;-)

[hotlineshocker]

Hallo seife,

wenn ich mich zur Entwicklung eines Patch bei Einsatz von verhältnismäßig
angemessenem Zeitaufwand in der Lage sehen würde, hätte ich diesen
natürlich bereits meinem ersten Posting angefügt.

Weist du nicht jemanden, der sich evt. um einen Fix
für dieses Problem kümmern könnte?

GoIP

dodi

[wolgade]

Weist du nicht jemanden, der sich evt. um einen Fix
für dieses Problem kümmern könnte?

Wenn er das wüßte, dann hätte er das vermutlich geschrieben. Der Letzte, der am Movieplayer gearbeitet hat, war so weit ich mich erinnere Günter. Den habe ich in diesem Forum ewig nicht mehr gesehen.

[hotlineshocker]

Hallo wolgade,

danke für deinen prompten Hinweis.

Du meinst sicher Günther. Oder?

GoIP

dodi

[wolgade]

Günther.

Ja, genau den meinte ich. Tschuldigung Günther, wollte dir kein "h" klauen.

[Gorcon]

Ausserdem stimmt die Anzeige der Wiedergabezeit bei vielen aufgenommenen Sendungen überhaupt nicht. 50% Abweichung sind keine Seltenheit.

[hotlineshocker]

@Gorcon

Das ist mir noch gar nicht aufgefallen, werde es auch bei mir einmal beobachten...

@ALL

habe einmal wolgades Hinweis folgend an Günther eine Einladung in diesen Thread hier per PN gesendet.

GoIP

dodi

[Gorcon]

@Gorcon

Das ist mir noch gar nicht aufgefallen, werde es auch bei mir einmal beobachten...

Nimm mal von ZDF 2h auf, dann wirsd Du sehen wie stark die Abweichungen sind.
Den Bug mit der Pausenfunktion ist mir daher noch garnicht aufgefallen weil die Zeiteinblendung für mich nichts taugt.
Mir kommt es so vor als würde die hohe Prozessorlast beim abspielen von der HDD die U(h)rsache sein.

[wolgade]

Nimm mal von ZDF 2h auf, dann wirsd Du sehen wie stark die Abweichungen sind.

Wenn ich mich recht erinnere, dann wird die Wiedergabezeit aus der Dateiposition bzw. der verstrichenen Datenmenge abgeleitet. Bei bekannten und konstanten Datenraten klappt das prima. Dummerweise sind bei DVB die Datenraten nicht konstant. Auch ein Mittelwert hilft hier nicht weiter, da sich auch die mittleren Datenraten von Sender zu Sender unterscheiden.

Enthält eine TS-Datei eigentlich Timestamps? Damit ginge es genauer.

[seife]

Ja. Im mpeg ist für jedes frame ein PTS (presentation timestamp), wenn ich mich recht erinnere, für audio und video. Damit wird das synchronisiert. Die aktuellen PTS sind z.B. in /proc/bus/bitstream verfügbar. Ich wollte das auch mal im movieplayer einbauen, aber dann war der Ekel doch stärker ;-)

Was man damit machen kann sieht man in tools/misc/showptsdiff.c

[Gorcon]

Genau aus selbigen Grund sind die Spultasten sehr ungenau (da ist es aber nicht ganz so tragisch).

[Gaucho316]

Günther hat mal vorgehabt, die Zeitanzeige in den Movieviewer einzubauen. Dabei hat er auch einige Anpassungen bei der Zeitberechnung vorgenommen. Leider ist das wohl im Sande verlaufen. Ein diff ist aber in folgendem Posting verlinkt. Hilft das vielleicht weiter?
http://tuxbox-forum.dreambox-fan.de/for ... 07#p353907

[dwilx]

Hier mal so zum Spaß eine Testversion, welche die Zeit im MV (movieviewer) anzeigt. Geht z.Z nur über den MB (moviebrowser). Bei neueren Aufnahmen (ab cvs vom 7.9.2007) sind Zeit und Sprünge auch relativ genau .

mv_exact_time.diff

Hat das denn schon jemand damit probiert? PTS-Infos werden damit aber wohl nicht genutzt...

[hotlineshocker]

Ja. Im mpeg ist für jedes frame ein PTS (presentation timestamp), wenn ich mich recht erinnere, für audio und video. Damit wird das synchronisiert. Die aktuellen PTS sind z.B. in /proc/bus/bitstream verfügbar. Ich wollte das auch mal im movieplayer einbauen, aber dann war der Ekel doch stärker ;-)

Was man damit machen kann sieht man in tools/misc/showptsdiff.c

Sehr interessantes Beispiel. Habe mir tools/misc/showptsdiff.c einmal im CVS angesehen.

Aber grundsätzlich, denke ich, kann man die existierende Problematik jetzt schon erst einmal in 2 Bereiche gliedern:

1. Anzeige (z.B. läuft weiter während Pause ect.)
2. Genauigkeit (wird derzeit nur näherungsweise ermittelt)

Hinsichtlich der Probleme mit der Anzeige an sich, so vermute ich, ließen sich evt. schon mit wenigen Zeilen erhebliche Erfolgserlebnisse herbeiführen.

Wohingegen die Genauigkeitsproblematik in der Tat sicher einen wesentlich größeren, schwer überschaubaren Komplex darstellt, dessen zufriedenstellende Lösung einen erheblichen Einsatz an sicher nicht mit dem, dem Problem zugrunde liegenden derzeitigen Algorithmus, zu messender Zeit fordern würde.

GoIP

dodi

[Gorcon]

Würde man aber das Problem mit der Genauigkeit (durch Auswertung der Timestamps) eleminieren hätte man damit auch keinen Bug mehr dem Weiterlauf der Zeit bei der Pausentaste.

[Günther]

Die Zeit ist glaube ich (ohne die letzen Monate in den Kot , ähh Code geschaut zu haben) wird nur ein Sekundenzähler. Nach einem Sprung sollte sie eigentlich neu 'berechnet' werden und da weiterlaufen. Die alte Berechnung war nur ein hardcodierter MB/Sekunde Wert, welcher natürlich nur bei einer bestimmten Bitrate stimmte (ganz grob geschätzt 1,5 MBit/sec ) . Bei meinem damaligen workaround wird die Bitrate von der Aufnahme (gespeichert im xml-File) verwendet, welche aber auch nur ein Mittelwert über die jeweilige Aufnahmezeit ist. Wird soweit ich mich noch erinnern kann aber noch nicht vom Movieplayer genutzt (nicht im cvs?) . Das mit dem PTS wäre natürlich am besten ...

[tcf4004]

Mir ist auch noch was aufgefallen bei Movieplayer und VLC-Wiedergabe.

Und zwar ist es hier nun so dass Springen vorwärts (1, 5, 10 min) einwandfrei
klappt, ein Druck danach auf die Home-Taste zeigt die richtige Zeit an.
Springt man jedoch zurück, zB 1 min, so wird der Sprung zwar ausgeführt,
die Zeit bleibt jedoch stehen, und das solange bis der ursprüngliche Punkt
(von dem aus gesprungen wurde) erreicht ist, erst dann läuft sie weiter.
Das tritt bei allen "Zurückspringern" auf, also bei 1, 5 und 10 Minuten.

Beispiel:
- Film spielt gerade ab, ist aktuell bspw. bei 20:40
- Nun wird die 1 auf der FB gerückt -> Film springt zurück, aber es steht immer noch 20:40 da
- Erneuter Druck auf <Home> zeigt solange 20:40 an, bis der Film wieder "drüber" ist,
d.h. da wir eine Minute zurückgesrpungen sind, müssen wir nun auch ca. 1 Minute warten
bis die Zeit wieder weiterläuft.

Das Phänomen tritt nicht mit allen Filmen auf, ich muss noch genauer rausfinden,
wann und womit es auftritt.
Jedoch hatte ich solche Probleme mit dem VLC 0.7.2 und einem alten Image definitiv nicht,
da wurde die Zeit immer (bei allen Filmen) korrekt angezeigt.

Da ich relativ häufig mit VLC/MP schaue, ist das schon störend.
Ich habe das mit MP 1.162 getestet (cvs vom 23.06.08).

Habt Ihr das Problem auch?

Werde sobald ich etwas Zeit finde, das mal noch etwas genauer genauer untersuchen.

Gruss
tcf4004

[tcf4004]

Hi,

ich habe einiges mit VLC/MP getestet und folgendes herausgefunden:

- Sprünge vorwärts ok (manchmal etwas Abweichung), Zeitanzeige ok
- Sprünge rückwärts ok (manchmal etwas Abweichung), Zeitanzeige wird aber nicht upgedatet und
verbleibt auf dem gleichen Stand bis der Film wieder über die Stelle "drübergeht"
- div. Formate getestet, AVIs gehen, viele MPEG2 sind jedoch betroffen (aber nicht alle, kein Muster erkennbar)
- WabberQueue ein/aus, Transcode ein/aus, ProjectX M2P remux, andere MP-Version -> nützt alles nix

Nun habe ich im Browser mal manuell ein paar seekval-URLs eingetragen und gesehen dass VLC selber dass
dann schon falsch anzeigt, d.h. der Sprung im Film wird (mehr oder weniger) richtig ausgeführt, die Zeit
wird jedoch u.U. falsch berechnet. Das bedeutet schonmal dass Neutrino oder der Movieplayer mit diesem Fehler
nichts zu tun haben sollten

Dann habe ich noch einige VLC Versionen 0.8.5 bis 0.8.6i durchgetestet und festgestellt, dass 0.8.5
die letzte ist, wo http seeking noch einwandfrei funktioniert.

Eben noch ins VLC Forum geschaut, da gibts auch schon mehrere Threads dazu (nach "http seek" suchen), zB den hier:
http://forum.videolan.org/viewtopic.php?f=14&t=47886

Vielleicht sollte ich dort auch meine Erkenntnisse posten...
EDIT: gerade gemacht

PS: die VLC 0.9.0-test nightly builds laufen bei mir nicht, Fehlermeldung bei Start und beim Streamen kommen keine Daten

[tcf4004]

So, nach wiederum einigem Basteln & Testen kann ich folgendes sagen:
Es gibt nen relativ einfachen Workaround mit dem das Seeken wieder so funktioniert wie früher
VLC einfach mit folgenden Optionen starten:

Code: Alles auswählen

vlc.exe --extraintf=http --no-ps-trust-timestamps

Hintergrund:
Da ich meist MPEG2-PS via VLC wiedergebe, habe ich (nach einigem erfolglosen Suchen) dann mal nach Unterschieden
im PS-Demuxer modules/demux/ps.c gesucht, zwischen 0.8.5 und 0.8.6, denn in 0.8.5 ging das Seeken ja noch.
In der ps.c von 0.8.6 fiel mir auf, dass dort nach Abhängigkeit der Variablen ps-trust-timestamps, zwischen
zwei Möglichkeiten der Zeitberechnung unterschieden wird (Aufruf DEMUX_GET_TIME), während es in 0.8.5
nur eine gibt. Dann erst habe ich mal im VLC-Wiki nachgelesen und gesehen dass diese beiden Möglichkeiten ja
bereits via Option schaltbar sind, naja jeder geht anders an die Sache ran

Code: Alles auswählen

VLC command-line help
MPEG-PS demuxer
--ps-trust-timestamps, --no-ps-trust-timestamps
Trust MPEG timestamps (default enabled)
Normally we use the timestamps of the MPEG files to calculate
position and duration. However sometimes this might not be usable.
Disable this option to calculate from the bitrate instead. (default
enabled)

Das Problem liegt einfach im Kern entweder VLC-seitig an der (schwierigen) Zeitberechnung aufgrund variabler
Bitraten und/oder an kaputten bzw. nicht spec-konformen Timestamps im Stream.
Mit der Option --no-ps-trust-timestamps verhält sich VLC 0.8.6i jedenfalls wie "früher", d.h. zu Zeiten 0.8.5
(und auch 0.7.2). Das bedeutet Seeken, Bookmarken, Re-Entry etc. klappen damit wieder zuverlässig.
Allerdings hat man damit auch wieder den Effekt, dass ein 90min Film zB als 30min angezeigt wird, sozusagen
"time compressed", 1 sec entspricht bspw. 3 sec. Aber imho lieber das in Kauf nehmen, dafür geht der Rest
wieder gut

Gruss
tcf4004