web (HbbTV, VDR*ELEC), Milestone 1 erreicht

Ich hoffe, die Werte im BT kann man auf signed/unsigned und die Ausgabe zurückführen. Die sind z.T. etwas gruselig.

Zitat von rell

Ich bin mir nicht sicher, obs wirklich an der Nutzung von sws_scale liegt, werfe aber mal die Frage in den Raum, ob fürs Skalieren und Umwandeln nicht ImageMagick/GraphicsMagick auch geeignet wäre.

Wie das Bild skaliert wird ist völlig egal. Es gibt nur folgende Voraussetzungen:

- sollte relativ schnell sein

- die Pixelformate RGBA und BGRA sollten unterstützt werden

- ich finde eine API oder ein Beispiel dazu

Ich habe nur sws_scale genommen, weil das ich in der alten Version auch schon verwendet hatte und mein Herz hängt nicht wirklich daran.

Zitat von Zabrimus

Das ResetVideo kommt nur genau dann, wenn ein Video endet und direkt danach ein neues Video starten soll.

Ich habe das Problem nachstellen können und es ist gefixed. Wenn der Transcoder nicht läuft, kann es passieren, daß der Browser ein ResetVideo sendet, ohne vorher tatsächlich den Player initialisiert zu haben. Folge: segfault.

Zitat von Zabrimus

Wie das Bild skaliert wird ist völlig egal. Es gibt nur folgende Voraussetzungen:

- sollte relativ schnell sein

Ich habe eine Version gebaut, die mittels LANCIR das Bild skaliert. Verwendet werden soll (lokal) sse2. Das Ergebnis ist sehr ernüchternd. Mal abgesehen vom Pixelformat (das sich lösen lässt), habe ich folgende Zeiten nur für das Skalieren der Images:

sws_scale: 1 ms

Lancir: > 50 ms

Der Unterschied ist signifikant und merklich spürbar.

jojo61 Na dran

Sowohl das OSD, als auch das Video (bzw. die eingehenden TS Pakete) werden nur über das Ausgabedevice ausgegeben. Dazu gibt im Plugin das cOsdObject und den cPlayer/cControl.

Der Browser rendert das OSD, welches über das Ausgabedevice als echtes OSD ausgegeben wird. Der Browser "sammelt" aber auch die Video-URL ein, sendet diese an einen Transcoder, der das ganze in einen TS-Stream transcodiert, welches dann über den cPlayer/cControl ausgegeben wird (PlayTS war es, glaube ich).

Das Video selbst wird über das Ausgabeplugin skaliert und damit gibt es kein Problem. Die Schwierigkeit entsteht durch das OSD. Vom Browser kommt akuell immer ein Image in der Größe 1280 x 720. Können die Ausgabedevices das OSD selbst skalieren? Beispielsweise kommt 1280x720 rein und das soll auf 1920x1080 ausgegeben werden?

Ich habe schon darüber nachgedacht, ob man die Bildgröße nicht direkt im Browser skalieren kann. Dann werden die Images größer und ich bin mir nicht sicher, ob es dann noch ausreichend schnell funktioniert. Das andere Problem sind die unhandlichen Zoom-Level von CEF.

Zitat von rell

Hm, das geht dann so nicht. Mal abgesehen, dass sws_scale ja eigentlich funktionieren müsste und ich immer noch nicht weiß, woran das liegt, kann ich ImageMagick mal ausprobieren.

Ich habe jetzt mal FFmpeg 6.0 auf meinem System und ich kann das Problem immer noch nicht nachstellen. Mir fehlt immer noch der Ansatz an dem ich etwas versuchen kann oder mit dem ich spielen kann.

Für das Plugin gibt es den Branch lancir, mit dem ich Lancir getestet habe. Vielleicht ist der resampling Algorithmus (Lanczos) nicht der schnellste.

Ihr bringt mich auf sehr gute Ideen.

Ich habe mir die API von CEF

  ///
  /// Called when an element should be painted. Pixel values passed to this
  /// method are scaled relative to view coordinates based on the value of
  /// CefScreenInfo.device_scale_factor returned from GetScreenInfo. |type|
  /// indicates whether the element is the view or the popup widget. |buffer|
  /// contains the pixel data for the whole image. |dirtyRects| contains the set
  /// of rectangles in pixel coordinates that need to be repainted. |buffer|
  /// will be |width|*|height|*4 bytes in size and represents a BGRA image with
  /// an upper-left origin. This method is only called when
  /// CefWindowInfo::shared_texture_enabled is set to false.
  ///
  /*--cef()--*/
  virtual void OnPaint(CefRefPtr<CefBrowser> browser,
                       PaintElementType type,
                       const RectList& dirtyRects,
                       const void* buffer,
                       int width,
                       int height) = 0;

genauer durchgelesen, ein wenig getestet und enormes Optimierungspotential entdeckt. In meiner alten Version habe ich noch das ganze Bild genommen und versucht das mittels FFmpeg in ein Video zu verwandlen um es im VDR abspielen zu lassen. Ich meine auch damals hätte ich immer dirtyRects.size == 1 und immer das Vollbild in dirtyRects bekommen.

Das muss sich geändert haben, auch wenn dirtyRects.size == 1 ist, besteht die RectList jetzt aus viel kleineren Bereichen (wenn nicht gerade alles neu gezeichnet wird). Und damit muss ich nur Teile des OSD übertragen und skalieren.

Zitat von jojo61

DrawImage(const cPoint &Point, const cImage &Image, double scaleX = 1.0, double scaleY = 1.0)

Diese Erweiterung wäre am Besten. Nur müssten Klaus und alle Ausgabedevice-Entwickler mitziehen. Das scaleX, scaleY kann man ja berechnen. Ich könnte mir vorstellen, daß dies auch für Skins oder ähnliches sinnvoll sein könnte. Skalieren ist ein häufiges Problem.

Zitat von jojo61

Noch etwas zur Umwandlung in ein TS Stream. Das ist eigentlich nicht nötig. Das plugin spiel nur PES Pakete ab.

Nur der VDR braucht die TS Pakete und macht daraus dann PES Pakete. Evtl. kann man das auch umgehen.

Hoffentlich lehne ich mich hier nicht zu weit aus dem Fenster

Das hat auch historische und praktische Gründe. Aktuell ist mir noch kein anderes Videoformat als h264 untergekommen, Audio ac3, aac und Konsorten. Damals gab es auch andere Codecs, die nicht für TS vorgesehen sind und auch tatsächlich transkodiert werden mussten, damit Bild und Ton funktionierten. Wobei Transcoding im Moment nur die Umwandlung von mp4 -> TS bedeutet (copy audio/video). Das ist extrem schnell. Aber ich denke, daß später auch andere Videoformate auftauchen können werden. Ich muss mal schauen, ob ich alte Filme in einer Mediathek finde, weil ich glaube, das diese das Hauptproblem waren.

Das andere Problem entstand aus der Video-Codierung des Browser (OSD und Video) und den Transport nach VDR. Auf der Entwicklungsumgebung war das Encode viel zu schnell und VDR hat das Video dann auch in einem enormen Tempo abgespielt. Absolut unbrauchbar. Eine saubere Bremse habe ich nicht hinbekommen.

Jetzt nutze ich im Transcoder den FFmepg mit -re und damit bekomme ich die Daten nicht schneller, als sie abgespielt werden sollen und ich muss mich um nix mehr kümmern.

Als erstes werde ich mich um dirtyRecs kümmern und schauen, wie sich das auswirkt. Wenn die API nicht geändert werden kann, kommen dann vielleicht auch andere Libs wieder in Betracht: GraphicsMagick, ImageMagick, Lancir oder andere.