Beiträge von HelgeBS

    Besten Dank!
    Dazu habe ich eine Verständnisfrage. Warum werden .ts Dateien so anders behandelt, als andere Medenformate? Reicht es nicht aus, den Video-, den Audio- und den Text-Stream heuristisch zu erkennen und einfach abzuspielen? In der Aufnahmen muss man ja nicht das Kanal-Bouquet auseinandernehmen, da ist ja nur noch der eine Sender drin.
    Ich hatte bspw. mal eine defekte Aufnahme (Fehlermeldung: Kein PAT in PMT oder so, ich bringe diese TLAs immer durcheinander), die hatte ich dann mit ProjectX repariert (PID Filter). Ich konnte die dann aber immer noch nicht abspielen, bis ich die Senderkennung (1:0:1:202:202:2114:EEEE0000:0:0:0: oder so ähnlich) in der .meta Datei durch 0-en ersetzt habe...

    Das ist mir heute schon das 2. mal passiert (das letzte mal so vor 2 Wochen):
    Wenn ich eine Aufnahme anschaue und währenddessen eine Timeraufnahme startet, die denselben Sender aufnehmen soll, von dem die gerade angesehene Aufnahme stammt, dann wird nicht das aktuelle Programm aufgenommen, sondern die abgespielte Aufnahme (es wird also eine Kopie erstellt komplett inkl. Videotext, nur die Sendungsbeschreibung ist neu).
    Beende ich das Abspielen, zeigt das aktuelle Programm von dem Sender nur ein schwarzes Bild, solange wie die Aufnahme dauert.
    Das Problem tritt nicht auf, wenn die Wiedergabe nach Aufnahmebeginn gestartet wird oder es sich um unterschiedliche Sender handelt.
    Sehr kurios!

    Das Problem mit der fehlerhaften Interlace-Erkennung wurde vor etwa einer Woche behoben (besten Dank) und das Ganze sieht nun schon viel besser aus. Der Scaler arbeitet nun auf dem kompletten Frame und hinten kommt Progressive raus und Autores schaltet richtig um.
    Aber irgendwie stimmt immer noch was nicht richtig. Scheinbar wird das progressive Quellmaterial in zwei Durchgängen in den Scaler geschickt, so dass sich ein starkes Interlace-Kantenflackern ergibt (das wird dann als progressive zum TV geschickt, so das dann dessen De-Interlacer deaktiviert bleibt).
    Der Ablauf sollte doch folgender sein:

    • Quellmaterial in Auflösung xy (bsp. 512x288p@25Hz)
    • Autores schaltet auf passende Ausgabe XY (bsp. 720x576p@25Hz oder 720x576p@50Hz)
    • bei Progressive:
      Scaler skaliert frameweise in Rate des Quellmaterials (25Hz), Ausgabe dann ggf. in doppelter Rate (50Hz)
    • bei Interlace:
      Scaler skaliert fieldweise in Rate des Quellmaterials, Ausgabe muss dann dieselbe Rate haben

    Z.Zt. scheint es so zu sein:

    • bei Progressive:
      Scaler teilt Frame (25Hz) in zwei Fields (50Hz) und skaliert dann hoch.

    Also für alle, die das Problem nicht haben, ich habe mal mit AviDemux rumgespielt und einen Filter zusammengestellt, der das bei mir vorhandene Probem visualisiert:

    Das sieht dann beispielsweise so aus:


    Ich habe auch noch ein wenig mit Mediainfo nachgeforscht. Die von mir verlinkte Datei hat definitiv Progressive-Content:


    Ich bin dann mein Archiv mal durch und es wurden alle H264-codierte Dateien immer als interlaced von der DM800 ausgegeben, auch wenn sie von MediaInfo als progressive angezeigt wurden, auch so bekannte Stücke wie:


    Oder:


    Oder HQ-Dateien vom OnlineTVRecorder, die ich mit dem TSMuxer umgepackt habe:


    Nur bei MPEG-Dateien funktioniert es problemlos, diese Datei wird als progressive erkannt und mit 720p ausgegeben (wie in AutoRes vorgegeben):

    Hat das wirklich noch kein anderer beobachtet?
    Nun konnte ich mir das Problem auch mal auf einem Full-HD Bildschirm ansehen. Es scheint sich aus der Beobachtung auf folgendes Problem zu reduzieren:


    Alle Videos werden bei mir als interlaced erkannt (lt. Autores-Infoscreen), also bspw. auch Youtube-HD-Videos als 720i. Das hat zur Folge, dass beim Scaling die Frames in zwei Fields aufgeteilt werden, und diese einzeln hochskaliert werden. Natürlich wählt dann Autores auch die "passende" Interlaced-Auflösung aus, nicht aber Progressive. Das scheint unabhängig vom Format (MPEG2/H264, TS,MKV,MP4) zu sein.
    Das von mir verlinkte Beispiel (512x288p@25Hz) wurde dann getrennt 2 mal von 512x144 auf 720x288 hochskaliert und auf meinem TV mit 720x576i angezeigt. Jede horizontale Kante wurde dann mit Kammeffekt verdoppelt, das muss ja auf einer Std.-Röhre stark flimmern.


    Also die Progressive-Erkennung hatte ja schonmal funktioniert. Es wäre schön, wenn sich ein Entwickler, der sich damit auskennt, das mal anschaut.

    Ich habe bei mir das LastFM-Plugin installiert. Der Scrobbler is wohl nicht mehr kompatibel mit den letzten Änderungen an Enigma2. Beim Abspielen von Mediendateien (mkv, mp4, mp3) gibs nach ein paar Sekunden Spinner und Crash (ist schon seit einigen Updates bei mir so).


    Wenn ich den dort aufgefundenen Code auskommentiere, kann ich den Crash vermeiden. Da ich mich aber weder mit iServiceInformation noch mit sArtist auskenne (geschweige denn wüsste, wo ich danach suchen sollte), habe ich mir das nicht weiter angesehen.


    Devicename: dm800
    Enigma Version: HEAD-Jun 1 2009
    Image Version: dev-2009-06-01
    Frontprozessor Version: VNone
    Webinterface Version: 1.5rc1

    Im aktuellen CVS-build habe ich Probleme, Aufnahmen von Platte zu gucken, während eine Timeraufnahme erfolgt. Es wird auf den Sender geschaltet, von dem die Aufnahme stammt (wenn auf dem gleichen Transponder, wie die aktuelle Timeraufnahme) oder die Meldung kein freier Tuner (wenn auf anderem Transponder) ausgegeben nicht aber die Aufnahme abgespielt. Kann jemand mein Problem nachvollziehen/bestätigen?
    Ich hatte gestern den Update (OoZooN-Feed) gemacht, da zuvor in derselben Situation Enigma mit Green-Screen crashte:


    Devicename: dm800
    Enigma Version: HEAD-May 31 2009
    Image Version: dev-2009-05-31
    Frontprozessor Version: VNone
    Webinterface Version: 1.5rc1

    Zitat

    Original von anybody Heftig! Das muss ich echt mal ausprobieren. Hätte ja nie gedacht das TV's so ein Signal überhaupt annehmen könnten :smiling_face:


    Kein ungewöhnliches Signal, dafür wurden die TVs gebaut (1080i@25Hz besteht ja aus 2 Halbbildern zu je 540 Zeilen bei doppelter Frequenz).

    Zitat

    Original von anybodyOder versteh ich hier irgendwas komplett falsch ?!?


    Die beiden Halbbilder zu je 720x288@50Hz werden unabhängig voneinander auf 1920x540@50Hz skaliert und der TV deinterlaced dann im besten Fall auf 1920x1080@100Hz. Statt der Kammartefakte kommt dann von der DreamBox eine leichte vertikale Unschäfe.

    Zitat

    Original von rmie
    Ja, das gibt es dort, leider aber nur S/C/T bzw. alle Permutation davon von, Unterscheidung zwischen S2 und S ist nicht möglich

    Upps ja stimmt, ich war irgendwie gedanklich bei S2 (intern) und T (USB) aber der USB-Tuner von Homey ist ja auch S.


    Zitat

    Das DVB-USB Interface hat sich von 2.6.12 (Dreambox) bis 2.6.27 dramatisch geändert, der Backport ist sicher nicht trivial.

    Hmm, im 2.6.12.6 er Archiv von kernel.org konnte ich den Cinergy-Treiber zuindest an derselben Stelle wiederfinden. Aber möglicherweise hat das mit Openembedded auch nichts zu tun...

    Zitat

    Original von Homey Scheint so als ob es da so ne art prioritätsliste gibt, und bei SD Sendern erstmal ein DVB-S Tuner benutzt wird und wenn der nicht da ist, dann erst der DVB-S2 Tuner.


    Also ich habe in Einstellungen->System->Anpassen(Experte)->ganz unten mal sowas gesehen.


    Ich habe auch noch so einen Terratec Cinergy T2 Tuner rumliegen, der sicherlich gerne wieder zum Einsatz käme. Den Treiber dafür gibt's bei Kernel.org somit sollte man den mit Openembedded sicherlich irgendwie eingebunden kriegen. Ich selbst habe mich allerdings noch nicht mit dem Image-Build für die DM 800 auseinandergesetzt...


    Helge