Größerer Buffer beim Movieplayer

[zexma]

Nurmal so interessehalber - wird beim "übertakten" _nur_ die CPU übertaktet oder arbeitet der "Demuxer" auch schneller?

http://forum.tuxbox-cvs.sourceforge.net ... t&start=60

In anderen Foren wurde berichtet das die anderen Chips u.U. beim übertakten auch "heißer" werden

Best. im einem der Hohlkopfboards.

[gmo18t]

@petgun:
mal nur so als Rückversicherung: wie hast du dieses "Testfile" produziert ?

Ist das eine Original-Aufnahme von neutrino "unangetastet" oder wurde da noch ein "remux" o.ä. (wenn ja, mit welchem Tool) gemacht ?

Es gibt nämlich durchaus ein paar unterschiedliche Möglichkeiten für die interne Struktur eines TS Files, wobei die meisten Player alles gleich gut abspielen können, die dbox aber nur eine ganz bestimmte Struktur mag ! Dabei kann es schonmal so tückisch sein, daß auch ein in diesem Sinne nicht geeignetes TS-File auf der Box über weite Strecken gut läuft und dann plötzlich ruckelt.

MPEG hat's eben in sich

- GMo -

[petgun]

mal nur so als Rückversicherung: wie hast du dieses "Testfile" produziert ?

..orginal *.ts nfs Direktaufnahme. Dann genpsi drauf angewendet und mit dem Womble MpegVideoWizard geschnitten. Der VideoWizard aendert imo zB. nix an der Fieldorder (damit haette der Movieplayer wirklich echte Probleme)...ob er, wenn kein rencodining stattfindet, on the fly demuxt und anschliessend wieder muxt weiss ich nicht. Ich habe eine Weile sehr gezweifel an dem Tool...im Moment nicht...mit transkodierter Audiospur (von 256kbps>192kbps) klappts ja dann auch fehlerfrei mit dem Movieplayer...ich denke bei der Audio Transkodierung werden Fehler der Audiospur (die im orginal enthalten sind) die dem Movieplayer nicht passen beseitigt.

Es gibt nämlich durchaus ein paar unterschiedliche Möglichkeiten für die interne Struktur eines TS Files, wobei die meisten Player alles gleich gut abspielen können, die dbox aber nur eine ganz bestimmte Struktur mag !

ja...was ist das fuer eine Struktur und welches Tool erzeugt Movieplayer genehme *.ts files?

[gmo18t]

ja...was ist das fuer eine Struktur und welches Tool erzeugt Movieplayer genehme *.ts files?

wie du dir denken kannst, hab ich ein eigenes Tool geproggt (im Paket levmpeg für linux zu finden), wobei meine damit selbst produzierten TS-Files auf der DBox vernünftig laufen, was aber nicht heißen soll, daß es wirklich in allen Fällen fehlerfrei funktioniert, weil ich darin eben nur meinen derzeitigen Wissenstand zur Struktur, die DBox-tauglich ist, umsetzten konnte. Und der muß nicht unbedingt vollständig sein.

Andere berichten ja, "Project-X" würde gute TS-Files liefern. Soweit ich damit gearbeitet habe, kann ich das auch bestätigen. Weitere Tools hab ich selbst noch nicht ausprobiert ...

Ich will jetzt erstmal nicht genauer auf die Strukurspezialitäten eingehen, da ich ja gar nicht weiß, ob dies bei deinem File eine Rolle spielt, vielmehr werd ich die Zeit dazu nutzen, das File mal unter die Lupe zu nehmen und wenn ich was Auffälliges entdecke, dann evtl. mehr dazu schreiben ...

- GMo -

[petgun]

Ich will jetzt erstmal nicht genauer auf die Strukurspezialitäten eingehen, da ich ja gar nicht weiß, ob dies bei deinem File eine Rolle spielt, vielmehr werd ich die Zeit dazu nutzen, das File mal unter die Lupe zu nehmen und wenn ich was Auffälliges entdecke, dann evtl. mehr dazu schreiben ...

danke! Ich hoffe das wird keine Jagd auf ein Phantom und ist nicht nur mein eigenes hausgemachtes Problem mit dem ich Euch hier verrueckt mache
BTW klappt das jetzt hervorragend mit dem integrierten genpsi...direkt Timeshift auf dem PC mit VLC...live waehrend der Aufnahme...astrein!

@Yjogol
..wenn Du nicht weisst was Du noch machen koenntest....ein Moviebrowser mit Anzeige ueber das Live-Plugin haette was...die neuen mit genpsi getunten *.ts files gehen jetzt ja auch mit VLC und Timeshift ebenso...das haette echt was!

[gmo18t]

...
danke! Ich hoffe das wird keine Jagd auf ein Phantom und ist nicht nur mein eigenes hausgemachtes Problem mit ich Euch hier verrueckt mache

... scheint aber leider doch so zu sein.

Hier also mal zu Analyse auszugsweise zwei TS Pakte aus deinem Test-File (nur Video, das reicht schon)

Code: Alles auswählen

PACKET #243, sync_byte = 47
  stream_id = E0  Video Stream 0, packet #213
    100 - picture_start_code
    109 - extension_start_code

PACKET #472, sync_byte = 47
  stream_id = E0  Video Stream 0, packet #430  PTS = 373.333333 ms

in #243 starten mittendrin die Daten für ein neues Bild (100 - picture_start_code), aber das Paket enthält keinen PES-Startcode und 'pusi' (wohlgemerkt nur mit einem 's') ist nicht gesetzt, wie hier bei genauerer Betrachtungs des Inhaltes sichtbar wird:

Code: Alles auswählen

PACKET #243, sync_byte = 47
  transport_error_indicator = 0
  payload_unit_start_indicator = 0    <----- das  ist pusi
  transport_priority = 0
  PID = 00E0
  transport_error_indicator = 0
  adaptation_field_control = 1
  continuity_counter = 13
  stream_id = E0  Video Stream 0, packet #213
  read 184 PES packet data bytes

in #472 finden wird ein PES-Header, eindeutig Indiz dafür ist "PTS = 373.333333", aber es gibt kein neues Bild (auch wenn's eins gäbe würde das nichts an "bad" Packet #243 ändern.
Schauen wir auch hier geneauer hin:

Code: Alles auswählen

PACKET #472, sync_byte = 47
  transport_error_indicator = 0
  payload_unit_start_indicator = 1                        <--- pusi
  transport_priority = 0
  PID = 00E0
  transport_error_indicator = 0
  adaptation_field_control = 1
  continuity_counter = 6
  stream_id = E0  Video Stream 0, packet #430
  packet_length = 7906                                         <--- !!!!
  10 = 2
  PES_scrambling_control = 0
  PES_priority = 0
  data_alignment_indicator = 0
  copyright = 0
  original_or_copy = 1
  PTS_DTS_flags = 2
  ESCR_flag = 0
  ES_rate_flag = 0
  DSM_trick_mode_flag = 0
  additional_copy_info_flag = 0
  PES_CRC_flag = 0
  PES_extension_flag = 0
  PES_header_data_length = 5
	PTS fields
    0010 = 2
    PTS[32..30] = 0
    marker_bit = 1
    PTS[29..15] = 1
    marker_bit = 1
    PTS[14..0] = 832
    marker_bit = 1
  read 170 PES packet data bytes

ja "pusi" könnte ok sein, wenn ein neues Bild (also ne neue payload starten würde).
Aber entscheidend problematisch ist 'packet_length = 7906' !


Bei der DBox und evtl. bei dem ein oder anderen Receiver können solche Paktete zu Rucklern führen, denn die TS-Stream sollten u.a. folgenden Regeln entsprechen.

Die Daten zu jedem einzelnen "picture" müssen in genau einem PES-Paket eingepackt sein. Das kann dazu führen, daß die 'PES packet_length' größer ist als mit den dafür vorgesehen 16Bit darzustellen. Deshalb sollte sie auf 0 gesetzt werden !

Wenn nun ein solches PES-Paket wiederum in 188 Byte große TS-Pakte verpackt wird, muß das 1. betreffende TS-Paket 'pusi' auf 1 setzen und sein 'payload' mit dem PES-Startcode beginnen. Alle weiteren TS-Pakete enthalten dann den Rest der Bilddaten (bzw. die des PES-Paketes).
Kann dann das letzte TS-paket nicht mehr vollständig mit Daten gefüllt werden, muß es mit 'stuffing' aufgefüllt werden.

Die Analyse ergibt nun aber, daß einfach die Daten aller Bilder (auch elementary stream ES geannt) insgesamt gesehen in PES-Pakete bestimmter Größe z.B. 'packet_length = 7906' verpackt wurden, so daß durchaus ein PES-Paket Daten von zwei Bildern enthält (wie bei #243, wo halt mittendrin, und ohne PES-startcode, ohne 'pusi', ...)
Oder ein neues PES-Paket beginnt, aber es enthält nicht unbeding gleich am Anfang ein picture-startcode ...

Ich glaub kaum, daß jetzt noch alle mitkommen und ich will mir auch nicht noch mehr einen abbrechen, es zu beschreiben. Deshalb hier nur nochmal ein Original Paket von der DBox zum Vergleich:

Code: Alles auswählen

PACKET #62, sync_byte = 47
  transport_error_indicator = 0
  payload_unit_start_indicator = 1                       <--- gut
  transport_priority = 0
  PID = 06FF
  transport_error_indicator = 0
  adaptation_field_control = 3
  continuity_counter = 8
  adaptation_field_length = 7
    discontinuity_indicator = 0
    random_access_indicator = 0
    elementary_stream_priority_indicator = 0
    PCR_flag = 1
    OPCR_flag = 0
    splicing_point_flag = 0
    transport_private_data_flag = 0
    adaptation_field_extension_flag = 0
    PCR fields:
      PCR[32..30] = 3
      PCR[29..15] = 11741
      PCR[14..0] = 24414
      0x3F = 3F
      PCR_extension = 264
  stream_id = E0  Video Stream 0, packet #53
  packet_length = 0                                               <--- prima
  10 = 2
  PES_scrambling_control = 0
  PES_priority = 0
  data_alignment_indicator = 1
  copyright = 0
  original_or_copy = 0
  PTS_DTS_flags = 2
  ESCR_flag = 0
  ES_rate_flag = 0
  DSM_trick_mode_flag = 0
  additional_copy_info_flag = 0
  PES_CRC_flag = 0
  PES_extension_flag = 0
  PES_header_data_length = 19
  PTS fields
    0010 = 2
    PTS[32..30] = 3
    marker_bit = 1
    PTS[29..15] = 11742
    marker_bit = 1
    PTS[14..0] = 16476
    marker_bit = 1
  read 14 stuffing bytes       (<--- das hat nix mit TS-stuffing zu tun)
  read 148 PES packet data bytes

Ich hoffe jetzt wird Einigen die Komplexität etwas klarer vor allem, daß nicht jeder Ruckler durch zu kleine Puffer o.ä. verursacht werden.

Und andere Player stören sich halt nicht an solchen "Lapalien" und spielen es klaglos ab. Deshalb muß ich immer , wenn es heißt:
"auf meinem PC wird der Film aber einwandfrei abgespielt" !

- GMo -

[petgun]

was ist denn 'pusi'?
...und was lernen wir jetzt daraus? Vordergruendig erst mal dass ein groesserer Buffer dagegen nicht hilft...und das so ein stream auch nicht auf dem neuen IDE-Interface laufen wird.

Was ich absolut nicht einordnen kann:

1: wieso die Takterhoehung der Dbox bei Zexma dazu fuehrt, dass das vermuellte orginal File bei ihm _ohne_ Fehler abgespielt wird.

2: wieso reicht das transkodieren der Audiospur bei mir fuer fehlerfreies abspielen.

kannst Du das erklaeren?

[gmo18t]

1: kann natürlich auch am Demuxer/Decoder u-code liegen !?
2: ich habe ja geschrieben, diese Struktur kann, muß aber nicht zu Rucklern führen !

In jedem Fall ist dein file nicht geeignet, um irgendein Verhalten des Movieplayers auszuloten. Da tut's nur eine unangetastete Original-Aufnahme !!!

- GMo -

[petgun]

... kann natürlich auch am Decoder u-code liegen !?

- GMo -

zexma hat auch eine Philips...ich nutze den orginal buildin 014 mit avia600 vb022

PS:ich wuerde eine moderate Takterhoehung gerne mal mit einer tagesaktuellen DietmarW-Yadd testen...reicht dafuer ein anderes u-boot? Wenn ja, kann das mal einer zur Verfuegung stellen/erzeugen?

<auch edit>

In jedem Fall ist dein file nicht geeignet, um irgendein Verhalten des Movieplayers auszuloten. Da tut's nur eine unangetastete Original-Aufnahme !!!

darueber koennte man sicher sehr gut streiten...bis auf den Schnitt ist mein Testfile orginal....ich kann hier wieder nur etwas lernen was ich kurzzeitig leider verdraengt hatte: never touch a dbox-direktstream.ts....movieplayer forever!!
Vielleicht sollte man die Boardregeln hier um einen Punkt erweitern...'..jegliche Kritik am Movieplayer ist untersagt...' ausserdem faende ich es angebracht dem 'Movieplayer' einen neuen Namen zu geben...'DBox-TS-Abspieler' oder so aehnlich.
</auch edit>

--
Fuer mehr Toleranz...auch beim 'Dbox-TS-Abspieler' aka 'Movieplayer'

[FaselMan]

-

[petgun]

petgun, ich möcht Dich ja nicht enttäuschen, aber der Womble haut da in die Streams..
..ich habe mit dem Womble noch kein spielfähiges ts-file für die Box bekommen.

..dann machst Du wahrscheinlich was falsch, oder benutzt nicht die Version die ich nutze. Ich nutze den Womble MpegVideoWizard (nicht mpeg2vcr) bisher ohne Probleme zB. zum schneiden der Neutrino *.ts files. Da wird absolut nix transkodiert wenn ich das nicht moechte _und_ bisher liefen die meisten files auch ruckelfrei auf dem Dbox-TS-Abspieler aka Movieplayer.
Es mag sein das mein Testfile fuer den Dbox-TS-Abspieler Muell/schwierig ist...der Rest der Player-Welt inkl. mplayer (unter Linux sicher auch) ist anderer Meinung...gmo18t kann ueber diese Argumentation lachen..ich nicht....ich versuche herauszufinden woran das liegt.
Wenn alle mit dem Verhalten des Neutrino-TS-Abspielers zufrieden sind, brauchen wir hier nicht weitermachen...ich kann mit dem imo suboptimalen Teil wunderbar leben und gelegentliche Aussetzer die es nur mit dem Neutrino-TS-Abspieler gibt, stoeren mich absolut null..und Netzwerkprobleme habe ich auch keine.

[FaselMan]

-

[petgun]

Aber ... wenn ich ein Test-0 öffne und als Test-1 exportiere, hat sich schon was getan :

27.875.328 Test-0.mpg
28.221.444 Test-1.mpg

Du meinst die Veraenderung der Groesse sei falsch?..kommt auf den Standpunkt an...BTW werden bei mir die orginal Neutrino *.ts Files nach einem Womble Durchlauf immer etwas kleiner und nicht groesser.. ..trotz Korrektur/Ergaenzung der fehlenden PMT/PAT...aber auch dazu hat man mir schon eine Erklaerung gegeben die auf die eigentliche Entstehung dieses Neutrino-TS Formats verwiesen hat. Angeblich ist das Format speziell optimiert auf das damals enstehende erste IDE-Interface...damit es weniger Overhead gibt, hat man die PMT/PAT einfach weggelassen...wuerde also von der Logik her zu Deinem Verhalten von Womble passen...bei mir passt es nicht

[chkbox]

2: wieso reicht das transkodieren der Audiospur bei mir fuer fehlerfreies abspielen.

Wahrscheinlich führt jedes bearbeiten zu konformen Streams.

[FaselMan]

-

[petgun]

Um das Netzwerk zu Testen musst Du sicherstellen, das der Movieplayer mit dem File klarkommt.

iss mir auch 100% klar...der Themenstarter berichtet von einem Premiere-Stream der laengere Zeit fehlerfrei abgespielt wird und dann einen Aussetzer hat...(solche/aehnliche Fehlerberichte gibt es viele hier im Forum)..und requestet zur Fehlerbehebung einen groesseren Buffer. Lag der Fehler jetzt am Netzwerk und/oder am Stream oder am Movieplayer?
Nichts genaues weiss man imo immer noch nicht.

Sorry an alle, dass mein Testfile uU. Streameigenarten hat, die durch den Schnitt mit Womble erzeugt worden sind mit denen der Movieplayer nicht klarkommt und zusaetzlich eine grenzwertige Datenrate hat auf die ich aber immer hingewiesen habe. Ein zu kleines Netzwerknadeloehr schliesse ich in dem Fall bei mir aber aus (zeigt auch das Diagramm)...bleibt eine evtl. durch Womble erzeugte nicht Movieplayerkompatible Streameigenart _und_ evtl. Streamfehler mit der jeder andere Player keine Probleme hat.

Warum das mit einer DBox-CPU-Taktfrequenz Erhoehung zu beseitigen ist kann ich mir beim besten Willen nicht erklaeren....genauso wenig wieso Womble nur in diesem Fall so einen, nur fuer den Movieplayer inkompatiblen Muell erzeugt haben soll...

Egal, ich bitte Dich recht herzlich Dein nur neu remuxtes Testfile mal hochzuladen..yousendit.com ist gut dafuer geeignet.

[rolano]

Egal, ich bitte Dich recht herzlich Dein nur neu remuxtes Testfile mal hochzuladen..yousendit.com ist gut dafuer geeignet.

... mich dieser Bitte anschliess....

[FaselMan]

-

[FaselMan]

-

[FaselMan]

-

[petgun]

hiho,

http://s37.yousendit.com/d.aspx?id=0SZ7 ... NV5J00KBBW

danke...wird fehlerlos mit dem Movieplayer abgespielt! Muss ich mir wohl mal den Elecard XMuxer besorgen..

@all
benutzt lieber das verlinkte File von FaselMan! Zum testen des Netzwerks und zum Nachweis der evtl. Wirksamkeit eines vergroesserten Buffers ist es imo Bestens geeignet...wenn es nicht ruckelfrei mit dem Movieplayer abgespielt wird.

Es sieht so aus, als ob das Womble Teil ausschliesslich beim erzeugen eines Movieplayer kompatiblen *.ts files dessen Tonspur eine Samplingrate >192kbps ist, 'leichte' Probleme hat und nochmal sorry!

Was mich immer noch brennend interessiert ist, wie es zu dieser fuer mich wunderbaren Selbstheilung eines solchen Streams kommen kann, wenn man die DBox-CPU-Frequenz auf 75MHz erhoeht.

cu,
peter

[DrStoned]

Hier mal mein Test:

das Originalfile test_org.ts ruckelt beim abspielen. Nachdem ich es allerdings mit ProjectX demuxxt habe, dann mit Muxxi wieder gemuxxt habe, und mit ProjextX wieder in ein TS gewandelt habe, lässt es sich völlig ruckelfrei abspielen.

Greetz von DrStoned

[Günther]

Ist Euch schonmal in den Sinn gekommen, daß ev. Ruckeln verschiedene Ursachen haben kann, die sich je nach Anwender-Umgebung verschieden auswirken können?

Ich glaube gmo18t ja sofort, daß es bei seinem Tests keine Verbesserungen bei der Erhöhung des Buffers gab, aber gilt das auch für alle Ruckler welche in freier Wildbahn gesichtet wurden?

OK, bei mir läuft zur Zeit alles Perfekt, nur bei AC3 habe ich hin und wieder (ca. alle 40 minuten) ein Geknirsche, welches sich mit '0' beheben läßt. Allerdings nehme ich auch z.Z nicht ZDF auf, sondern eher unproblematishe Sender. Ich kann mich aber z.B nur zu gut an ein verganges Ruckler-Problem erinnern, welches sich nur durch die Neuinstallation von Windows XP und SFU beheben lies (und bitte fragt mich nicht warum, ich weiss es leider auch nicht .Seitdem heisst bei mir die Devise: Never touch a running system.

Will sagen, wenn sich zwei oder mehr Probleme überlagern, ist die Analyse ob Methode x was bringt oder nicht, eventuell nicht eindeutig. Nicht zu letzt wurden viele Erfindungen gemacht, weil scheinbar bewiesene Fakten in Frage gestellt wurden.

Das wir uns mit dem 10 Bit Netzwerkanschluss an der Performence-Grenze bewegen ist uns denke ich allen klar. Gut möglich das sich die Ruckler nie beherschen lassen - aber vielleicht bringt die eine oder andere Idee dem einen oder anderen Linderung .....

Günther

[Spooky]

@petgun

Jetzt mal eine grundsätzliche Frage. Das Testfile ist ja nur ein Ausschnitt aus Deiner Aufnahme. Du hast die Sendung doch mit der dbox2 aufgenommen. Wie hatte sich denn das Original TS File verhalten, als Du es abspielen wolltest? Jagst Du jede Aufnahme erst durch ein Demuxxer/Muxxer/Transcoder o.ä. bevor Du versuchst es mit der dbox abzuspielen?

Mich interessiert es nämlich, wann der Fehler sich eingeschlichen haben soll: War es bei Deinen ungewollten Veränderungen des Streams oder ist es schon während der Aufnahme passiert?

Spooky

[petgun]

hi,
der 'Fehler' kommt eindeutig vom Muxer des Womble Mpeg Video Wizard.

Ich habe natuerlich weitere Experimente gemacht: Aufnahme vom ZDF mit 256Kbps Tonspur. Das nicht angetastete Orginal wir fehlerlos abgespielt aber wenn das File einmal durch Womble laeuft (zB. fuer einen Schnitt) gibt es sehr aehnlich wie bei meinem Testschnipsel nach ca 30 Sekunden Tonstoerungen mit anschliessendem Bildhaenger.

Womble kann kein Movieplayer kompatibles *.ts File erzeugen wenn die Samplingrate der Tonspur >192kbps ist...Schuld ist ganz klar der Muxer vom Mpeg Video Wizard. Das Teil ist echte Loehnware..aber ich bezweifle dass ich bei Womble Unterstuetzung fuer ein Neutrino-TS-Format bekomme.

Immer noch grueble ich ueber die angebliche Selbstheilung so eines durch Womble 'vermuellten' Streams nur durch eine Taktfrequenzerhoehung der DBox CPU....das muss ich selbst verifizieren (sorry Zexma)...ich kann das bei aller Phantasie nicht nachvollziehen.

@all
gibt's hier noch weitere Mitleser mit uebertakteter DBox CPU die diesen Effekt bestaetigen koennen?

cu,
peter

--
Ever try. Ever fail. No matter.
Try again. Fail again. Fail better.