neutrino-mp auf dem PC

[seife]

Der "Fix" von martii ist leider nicht korrekt.
Es ist komplizierter: das sample format des dekoders muss mittels libswresample in das sample format der Ausgabe konvertiert werden. Das fällt sofort auf, wenn man versucht, eine AC3 Tonspur abzuspielen...

[martii]

Ich hatte geraten, dass das Resampling die libao übernehmen würde (oder ggf. alsa oder was auch immer heute bei Linux als bevorzugtes Sound-Backend des Tages genutzt wird) und die avcodec_decode_audio4-Ausgabe kompatibel zu AO_FMT_NATIVE ist. Mit AC3 kann ich bei DVB-T nicht dienen.

Resampling (mit avresample) habe ich in libeplayer3/container/container_ffmpeg.c drin, falls Du ein Beispiel brauchst.

Edit: Nachdem ich mir die API nochmal angeschaut habe: Der "Fix" ist in der Tat Quatsch und tut eher zufällig bei 2 Kanälen.

Edit 2: In https://gitorious.org/~martii/neutrino- ... /audio.cpp habe ich eben das Resampling eingebaut. Einen Patch füge ich hier nicht an, da ffmpeg mit libavresample gebaut werden muss und dazu noch eine Handvoll Makefiles angepasst werden müsste. Die Änderungen sind aber problemlos in meinem Clone zu finden.

[seife]

Ich habe es auch implementiert, sieht auch ähnlich aus, aber ich habe libswresample anstelle der unsupporteten libavresample genommen. Es dauert aber noch, das mit allen ffmpeg-versionen zu testen und auf allen plattformen.

Cherry-picken geht ja eh nicht, weil deine Sachen ohne #define MARTII ja nicht gebaut werden

[martii]

Ohne die #ifdef MARTII verliere ich halt den Überblick, wenn ich Deine Änderungen merge ;-)

libavresample ist unsupported? Mist ... schien mir von der API etwas hübscher, da ab und an nicht nur Buffer übergeben werden, sondern auch deren Größe. Scheint aber ohnehin ziemlich einfach zu sein, von der einen zur anderen API umzustellen. Mal schauen.

[seife]

libavresample ist die NIH-Syndrom-reimplementierung von libswresample aus dem libav-fork. Ich persönlich nehme lieber ffmpeg als libav, aber das ist natürlich Geschmackssache.

Wegen #ifdef MARTII: dafür gibts ja "git blame" und "git diff". So ist es halt unmöglich, direkt von dir was zu mergen oder zu picken.

[flk]

Ich habe ein PKGBUILD für libdvbsi gebastelt, damit man das in Archlinux anständig über pacman installieren kann. Wenn ich das geregelt kriege, kommt noch irgendwann eins für Neutrino. Ich weiß allerdings noch nicht so ganz genau, wie das laufen soll. Libstb-hal als eigenes Paket zu bauen macht wohl keinen Sinn, weil der Source ja beim kompilieren von Neutrino benötigt wird. Mal schauen ...

PKGBUILD.tar.gz

[svenhoefer]

Irgendetwas stimmt mit dem Paket-Check in configure.ac nicht so recht. Zumindest habe ich den Eindruck, denn hier unter Debian Jessie immer mal so, dass entweder der libbluray-Check oder der id3tag-Check versagt. Es ist nie ein anderer Check. Meist hilft ein 'make clean' und ein erneutes 'make neutrino', um Abhilfe zu schaffen. Mitunter muss ich das aber auch ein paar mal neu versuchen.
Und, wie gesagt ... Es betrifft ausschließlich die beiden genannten Libs.
Ich baue das ganze mit einer angepassten Version dieses Makefiles -> https://github.com/seife/historic-build ... ile.native

Code: Alles auswählen

checking for package libavformat... yes
checking for package libavcodec... yes
checking for package libavutil... yes
checking for package libbluray... no
configure: error: could not find package libbluray
Makefile:424: recipe for target 'config.status' failed
make[1]: *** [config.status] Error 1
make[1]: Leaving directory '/home/vanhofen/ni/buildsystem/build_generic-pc/obj/ni-neutrino-hd'
Makefile:121: recipe for target 'neutrino' failed
make: *** [neutrino] Error 2

[seife]

ich benutze genau das Makefile: https://gist.github.com/seife/8a5fbc9ab ... e378ef909b
(nicht schön, aber genau damit geht es bei mir).

Wenn du nicht --boxtype=coolstream angegeben hast, dann wird aber auch nie nach libbluray gesucht (braucht das coolstream-zeug die eigentlich noch?)

Achtung bei shared-source und verschiedenen architekturen für die gebaut wird: das libtool etc. verewigt sich im ./configure, also öfters mal autoreconf wird nicht viel schaden Ich glaskugele mal, daß es daran liegt.

[svenhoefer]

Ich hatte vorher für Coolstream gebaut. Deswegen hatte sich libbluray wahrscheinlich - wie du sagst - im ./configure verewigt. An autoreconf hatte ich gar nicht gedacht.

braucht das coolstream-zeug die eigentlich noch?

Ja, unbedingt.

[flk]

Ich versuche gerade, das Neutrino-MP auf einem NUC passabel zum Laufen zu bewegen. Grundsätzlich ist das alles sehr vielversprechend. Der NUC ist ein performates Gerät, dass sich bestens als Media Center einsetzen lässt. Ich habe allerdings mit einigen Problemen zu kämpfen

1. Ich bekomme Neutrino nicht um Viel in den Fullscreen Mode. Startet immer mit Decoration

2. Seit den Veränderungen am rc Code lässt sich Neutrino bei mir nicht mehr über die Tastatur steuern. Der Effekt ist, dass zwar ab und zu die richtige Taste gesendet wird, jedoch zusätzlich auch immer auch eine größere Anzahl an "3". Dabei ist es egal, welche Taste ich drücke, 3er kommen immer mit. Das führt dann dazu, dass ich im Startassistenten anfangs nur eine Verzögerung in der Steuerung feststelle, aber dann bei den osd Einstellungen in einer Schleife lande, weil dort die "3" belegt ist und ich nur noch zwischen "Infobar" und "zurück" hin und her springen kann. Über Timote lässt sich Neutrino perfekt bedienen. Außerdem ist mir aufgefallen, dass Neutrino immer auf die Tastatur reagiert, ganz egal, ob das Programm focus hat oder nicht. Während ich auf der Konsole tippe wechselt Neutrino ständig zwischen Programm 3 bis 3333 hin und her

3. Fernsehbild ist gut, allerdings ist auf einem FullHD Sender die CPU des kabylake i3u bei 80%. Deshalb habe ich ffmpeg mit --enable-vaapi gebaut und kann jetzt mit mpv auch 4K Videos ohne Einzelbilder abspielen. Nur Neutrino mag das nicht verwenden. Wäre es viel Aufwand, die libva api zu aktivieren ?

4. Ich kann den Ton in Neutrino nicht regeln, von außerhalb über pavucontrol ja, aber Neutrino reagiert weder auf mute, noch kann ich lauter oder leiser stellen.

Weil ich mir nicht sicher bin, bei welchen dieser Fehler das Problem vor dem Moniotor sitzt, wäre ich über ein bisschen Aufklärung dankbar

[seife]

1. Würde ich dem Windowmanager anlasten.
Einfach keinen benutzen
Ansonsten: clutter oder plain OpenGL?
Beide benutzen explizite Methoden um fullscreen zu setzen (also machen nicht nur das Fenster maximalgroß) und mit xfwm4 funktioniert auch beides.

2. der User der neutrino startet sollte einfach keinen Zugriff auf /dev/input/ haben Damit funktioniert es bei mir wunderbar. Alternativ kannst du entweder das handling im GL/clutterfb oder im neutrino rauspatchen. Ich würde das eventhandling im neutrino rauspatchen, weil du sonst noch keytable-Translation machen musst, damit die Beschriftung auf deinen Tasten zu dem passt, was die Software sieht.

2, 3, 4 sind alles eigentlich keine Bugs, das ist alles "by Design".
Der PC port war nie dafür gedacht, damit Fersehen zu schauen, sondern um die memleaks in verschiedenen Codeteilen zu debuggen. Hätte nicht carjay damals mal den dekoder implementiert, könnte man bis heute gar nicht gucken, aber da er schon da war, habe ich den halt mit eingebaut.

Wie man 4 fixen könnte? Keine ahnung, man könnte bestimmt per ALSA oder pulseaudio die Lautstärke regeln, oder halt per softwareregelung im dekoder (finde ich aber hässlich), am einfachsten (allerdings ohne mute funktion) wäre es, das per VOLUME_SCRIPT zu machen.

zu 3: wie man vaapi macht? ebenfalls keine Ahnung.
Eine Lösung wäre vermutlich, statt dem selbstgebackenen decoder / player einen gstreamer-basierten, der direkt in die clutter-surface rendert zu implementieren, das würde auch gleich das CPlayback-Problem fixen. Und das würde auch gleich den Raspi-Port wesentlich weiterbringen. Müsste halt jemand machen.

[flk]

Kein wm ist irgendwie keine Option ... das ist zu unflexibel und ich will ja auch, dass man mit dem Image alle Möglichkeiten nutzen kann. Weil ich am Fernseher keinen floating wm brauchen kann, fiel der xfce gleich aus. Ich habe mit awesome experimentiert, und obwohl das wirklich cool ist, macht es doch einen verbastelten Eindruck auf mich und die lua Konfiguration ist auch nicht wirklich zugänglich. Imonad fiel wegen der fehlenden Zugänglichkeit auch aus ... wer kennt sich mit haskell aus Letztendlich verwende ich jetzt den i3wm und der ist richtig klasse.
Damit kann ich z.B. mit so einem Eintrag in der config einstellen, dass mpv immer im Fullscreen Modus angezeigt wird:

for_window [class="mpv"] fullscreen enable

Das klappt bei allen Programmen, die ich getestet habe, aber im Neutrino fehlt da wohl noch was

Ich verwende clutter und habe auch schon mit clutter_stage_set_fullscreen () experimentiert. Aber von c++ habe ich halt gar keine Ahnung ... hatte da bestimmt was vergessen oder an falscher Stelle eingetragen

weil ich grad auch noch dran denke, es gibt auch noch ein kleineres Problem, weil sich neutrino nur sehr dürftig im xserver registriert, nämlich nur mit einem Window Title. Deshalb funktioniert das obige Beispiel mit neutrino nicht, ich muss auf title ausweichen:

for_window [title="^neutrino$"] focus
for_window [title="^neutrino$"] fullscreen enable
assign [title="^neutrino$"] 10:video
workspace "10:video" output DP1

Mit dieser Einstellung landet Neutrino im Fullscreen Mode (wenn es denn mal funktioniert) auf Workspace 10 und der wird am Fernseher dargestellt. Genauer kann ich das dann aber nicht eingrenzen und so kommt es dazu, dass ein im Filemanager geöffneter Ordner mit dem Namen "neutrino" auch am Fernseher dargestellt wird. Eine Window Class würde da abhelfen.

Problem 2 saß vor dem Bildschirm Mich aus der Gruppe input entfernt und schon geht es ... und hat seltsamerweise Problem 4 gleich mitgenommen Vielen Dank für den Hinweis .... mann mann

Würde sich Problem 3 und (4) nicht einfacher damit lösen lassen ? Irgendwie bin ich von gstreamer nicht begeistert. Gut, die Portabilität ist wahrscheinlich etwas höher, aber dafür soll sich mal die Industrie interessieren MPV nutzt ffmpeg, bringt wenig zusätzliche Abhängigkeiten mit, kann halt alles und ist aktiv betreut.

https://github.com/mpv-player/mpv-examp ... ter/libmpv

Und klar, das sind eher Feature Requests als Bug Reports und wenn Du sagst, dass du by design keinen x86 bzw. xorg Support möchtest, ist das ja auch in Ordnung. Aber man kann ja mal fragen
Außerdem ist jetzt das lästigste Problem schon mal ganz einfach vom Tisch

[seife]

Also Problem 4 und mit der Input-Gruppe... das kann ich nicht nachvollziehen, weil:

Code: Alles auswählen

int cAudio::mute(void)
{
        return SetMute(true);
}

int cAudio::unmute(void)
{
        return SetMute(false);
}

int cAudio::SetMute(bool enable)
{
        lt_debug("%s(%d)\n", __func__, enable);
        return 0;
}

int cAudio::setVolume(unsigned int left, unsigned int right)
{
        lt_debug("%s(%d, %d)\n", __func__, left, right);
        return 0;
}

Also da kann nix laut und leise machen

Wenn libmpv auch auf dem raspberrypi und auf enigma2 boxen abspielt, dann wäre das eine alternative, die aber immer noch jemand implementieren müsste.

Der Vorteil von gstreamer ist, daß über ein output sink, den es für sehr viele Plattformen gibt, der ziemlich identische code auf PC (softdecoding und evtl. auch libva oder was auch immer), Raspberry Pi, dreambox als auch die neumodischen Dinger (vu+?) funktionieren sollte.

Für die enigma2 boxen gibt es jedenfalls gstreamer-sinks, denn die machen ihren mediaplayer darüber.

Wenn es das für libmpv auch gibt, und das weniger unhandlich ist als gstreamer, dann wäre das natürlich eine gute alternative. Ich werde aber in meine Codebasis möglichst nichts mehr einbauen, was unnötig Hardwarespezifisch ist.
Ok, wenn du jetzt kommen würdest mit einer Implementation die per libmpv sowohl live als auch playback mit wesentlich weniger code macht als der jetzige, von carjay's POC abgeleitete raw-ffmpeg code, dann könnte das schon noch rein, aber angenehmer fände ich es schon, wenn es was gäbe, was generell nützlich wäre.

Das Problem was ich mit gstreamer bisher nicht lösen konnte (ich habe es aber auch nicht exzessiv probiert) war, das dynamische zusammenbauen von Streams. Was einfach geht (mittels playbin) ist "Spiel mir diese URL/File ab". Was nicht so einfach zu sein scheint ist: "Hier ist ein file/buffer/device, aus dem kommt ein audio stream", "so, und hier noch ein device, da kommt ein Video stream raus", "und jetzt spiel das mal alles ab". Da ist mann dann ganz unten im low-level gstreamer pod-connect code und das macht gar keinen spaß.
Mit libmpv erwarte ich übrigens da ähnliche Probleme: im gegensatz zum alten MPlayer ist mpv nämlich auch viel empfindlicher, was das Fileformat (und speziell den Container) angeht. Alte VDR-Aufnahmen (ein ganz seltsamer, MPEG ähnlicher multi-PES container) kann mpv nicht abspielen, weil es eben kein MPEG Container ist. MPlayer spielte die einfach ab und mein primitiv-MPEG-Parser in libtriple/playback_td.cpp ebenso.

Wegen dem Window-Title: send patch, für mich geht das "gut genug"