34 replies to this topic

[rantanplan]

Dann war es wohl eine falsche Interpretation meinerseits, sorry.

 

Allerdings weiß ich jetzt auch nicht wo da setht das es am ffmpeg liegt, aber auch da gerne ein sorry von mir.

Könnte man auch was probieren, aber ist wohl verboten sich dazu Gedanken zu machen.

Wollte nicht stören.

[betacentauri]

Bitte nicht eingeschnappt sein! Aber das passte echt nicht.

[rantanplan]

Verstanden hab ich es so...

Mediafile abspielen ging irgendwann mal und geht jetzt aktuell nicht mehr, weiß jetzt immer noch nicht ob diese Annahme richtig ist.

Du hast auf eventuelle Hardware/Treiber hingewiesen.

Daher war für mich Austausch Treiber eine Möglichkeit des Test immer wert.

 

Ob das jetzt meinerseits zu viel gedacht war?

Keine Ahnung.

An einem Test finde ich nix verwerfliches.

Du hast jetzt ...liegt an ffmpeg...erwähnt.

Hatte ich bisher so auch nicht verstanden.

ffmpeg kann man anpassen und basteln. Aus meiner Sicht einfacher als gst. Wobei gst ja auch via lib immer indirekt auch ffmpeg mit nutzt.

 

Eingeschnappt, hmm...

kann sein das es so rüber kommt.

Hätte ich einen Grund dazu?

 

Also ...

Habe die Box nicht und mir ist jede Box vom Namen her völlig schnuppe.

Mir geht es ja nur um irgendwie das Beste aus jeder Mühle rauszuholen.

Da ist keine Idee schlecht, wenn man was testen kann.

 

Grüße

[betacentauri]

Könnte man auch was probieren, aber ist wohl verboten sich dazu Gedanken zu machen.

Wollte nicht stören.

 

Das hörte sich ein wenig eingeschnappt ein.
Und es ging um die Boxtreiber und die können wir nicht ändern. Kann nur der Boxhersteller bzw. seine Entwickler können das.

 

Aber ich will nicht lange drauf rumreiten hier.
Ideen finde ich eigentlich immer gut. Weil ich auch nicht immer auf alles komme

[rantanplan]

Dann wäre doch ein "rollback" Test Treiber für den User eine Idee wert.

Mir ist schon klar das im pli das vom Hersteller so kommt und auch bleibt.

Wobei Dream und pli wohl auch eher eine geschiedene Liebe ist.

 

Wie gesagt hab die Kiste nicht.

 

Bin ja bekanntlich froh über sh4, da lernt man und kann seine Treiber immer noch selber anpassen.

 

Grüße

[DoctorUltra]

Hat schon jemand eine Idee bzgl. des ffmeg Problems?

weil dauernd zu encodieren ist auch nicht so der Hit und ein v:copy bringt leider auch nichts, da man es mit dem vorherigen x264 encoder recodieren muss.

Und außerdem verliert man auch so immer an qualität.

[rantanplan]

In meinen Augen ist dies kein Problem des ffmpeg.

Allerdings könnte man versuchen dieses Phänomen damit zu lösen.

Genauso wie mit gst und den neu compilierten Sourcen.

 

Gut möglich neu compilerte Sourcen dann wieder die Sachen abspielt.

Generell werden aber ja mkv Dateien dargestellt.

Aktualisierungen im pli bzgl Mediaframwork finden allerdings eher sehr (sagen wir mal) zurückhaltend statt.

Das hat aber auch Vorteile bzgl Stabilität.

 

Ein neues Rendern mit Vorversion des x264 sollte keine Qualtitätsverluste haben.

 

Grüße

[DoctorUltra]

welche Einstellungen soll ich da bei ffmpeg vornehmen, damit es keine Qualitätsverluste hat?

[rantanplan]

Die Frage wäre jetzt ...

Wo und wie hast du es bisher gemacht?

 

Viele Wege führen nach Rom.

PC?

Handbrake

XmediaRecode

 

Oder eben auch direkt via LosslessCut probieren.

Dort wir prinzipiell geschnitten, aber du nutzt es quasi als simples Umwegtool um verlustfrei neu zu speichern.

 

Zum Encoden/Recoden kann man sich aber unendlich lange auslassen.

Umgekehrter Weg wäre für mich auch attraktiver.

 

Ich kann das nur vermuten, aber im x264 git wurde ja auch aktualisiert.

Diese Aktualisierung jetzt hier ins Pli git rüber gezogen  und gst und ffmpeg würden auch darauf basierend neu gebaut.

Im gleichen Atemzug könnte man auch die gst Basis erneuern und den ffmpeg auch auf 4.1.3 ziehen.

 

Vielleicht stimmt betacentauri mir da vom Gedankengang her ein wenig zu.

 

Grüße

[betacentauri]

Ich kann da wenig bis gar nichts zu sagen.

Das Problem kann an mehreren Stellen liegen. Die neueste ffmpeg hat nen Bug. Oder sie verwendet intern andere Einstellungen, die zum Gstreamer und oder den Boxtreibern inkompatibel sind. Jetzt müßte man "nur" jemanden finden, der sich mit ffmpeg so gut auskennt, dass er sagen kann was geändert wurde und zusätzlich jemanden der sagen kann ob das dann beim Gstreamer oder bei den Boxtreibern Probleme bereitet. Solche Leute findet man nicht. Besonders für die Sache mit den Boxtreibern.

Gstreamer kann man ausschliessen, wenn man die ServiceApp installiert. Wenn es damit auch nicht geht, liegt es am schon mal nicht am Gstreamer.

 

Wie gesagt, können wir die Boxtreiber nicht ändern und haben auch keine Infos darüber was die Hardware genau unterstützt und was nicht.

[rantanplan]

Wie gesagt, ich glaube die Akttualität und der Bau des x264 git ist auschlaggebend.

 

hier wird aus dem pyro-Branch openembedded-core gebaut

https://github.com/o...264/x264_git.bb

 

Ich würde das aus dem aktuelllen Branch ins pli git übernehmen.

https://github.com/o...264/x264_git.bb

Dann werden von da auch die beiden mediaframwork entsprechend anders gebaut.

 

Grüße

Edited by rantanplan, 19 May 2019 - 21:46.

[betacentauri]

Glaube ich eher nicht. Die Datei wird nur gedemuxed (in Video und Audio Daten separiert) und dann an die Box Treiber übergeben. Die Audiodaten werden ggf noch dekodiert. Die Videodaten werden aber nicht dekodiert. Das übernimmt die Hardware.

[rantanplan]

Da kommen ja noch ein paar Sachen im Hintergrund dazu.

 

Compiliert wird aktuell mit nasm, statt zuvor yasm.

Das könnte durchaus Auswirkungen haben.

 

Aber gut, sind auch alles nur unwissende Ideen.

Für mich ist es ja immer nur try&Error.

 

Grüße

[DoctorUltra]

Hat jemand vielleicht eine Idee wie ich mit ffmpeg das Video recodieren kann ohne Qualitätsverluste zu bekommen?

[rantanplan]

??

Das hab ich doch oben beschrieben, jedenfalls einige eventuelle Wege.