just a guess ...

mit gcc-4.8 kann man nicht ohne weitere patches gcc-4.6.3 compilieren ( wie es im oe drin ist .. )
installiere dir gcc-4.7

*g* und ich hab e2 auf hardware laufen, die bis zu 20x leistungsfähiger sind,als aktuelle vunderboxen,
ihr werdet es nicht glauben, aber ich kann 20mal schneller fernseh gucken

you or any other have to write a plugin ( either overwrite the zapping routine oder use a hook ( eventlistener ) ) ..
the second part should also be done with a plugin.

this is only ONE small recipe ( not a cake ) to accomplish the tasks.

1 gst-ffmpeg
2 http://pastebin.com/bpc4Krf6
3 eServiceReference(0x1001, 0, "http://localhost:8001/sref")

http://pl.vc/2s20c / http://pl.vc/4k26f

Zitat von Polymorph

@komisch
Was ist den an dem E2 von Vu und Co nicht rechtmäßig? Die benutzen doch eine E2 Version vor der closed source, oder bin ich da jetzt auf dem Holzweg? Die haben doch auch schon seid langen den 3.1 Kernel cec hdmi und teilweise sogar hbbtv.

mit der ersten einführung der schmarotzer-boxen, hätten sie einen gpl-fork erstellen müssen.
dann wäre zumindestens rechtlich alles in ordnung. ausgenommen von den den closed source plugins.
solche darf es auf den schmarotzer-boxen nicht geben.
bei dmm-boxen sieht es anders aus, da darf man fast alles machen, in der neuen lizenz sogar mehr.

aber sie haben e2 gemirrored, also seit dem ersten checkout alle commits von dmm übernommen.

wenn man die alte lizenz jedoch ganz genau nimmt, bezieht sich der initiale checkout auf einen fork,
auch wenn das wort "fork" nicht gefallen, sondern nur umschrieben wurde.
aber das wäre nur ne definitions-frage und streitpunkt, der von jmd. "überprüft" werden darf,
den die vergangenheit noch interessiert.

Zitat von Dr. Chaos

Werde ich, wenn ich gleich zu Hause bin, ausprobieren.

Imageanbieter: DMM.

das natürlich doof dmm kann aller vorraussicht nach, das paket nicht selbst anbieten, zumindestens nicht im vollem umfang.
auch wenn die sourcen unter einer gpl-compatiblem lizenz daherkommen,
könnte es probleme mit den eigentlichen rechte/patent/lizenz-inhabern etc. der formate selbst geben.
aber das müsste dmm im detail dann selbst klären.
was man privat macht, ist eine sache, aber als größere angreifbare instanz, ist das schon etwas anderes.

anyway, frag in einem der größeren boards einfach mal rum oder kompilier dir das teil selbst.

frag deinen image-anbieter, ob er das gst-ffmpeg plugin zur verfügung stellen kann,
dort ist der alac und weitere codecs enthalten ...

the best option u have is to setup your own build-environment ...
the next best is to wait for dmm, because newer gstreamer builds require the new glib 2.24
the worst one, is to wait for someone

btw. exchange "base" libaries, like glib is almost a bad idea, cause it is used in many other apps.
different minor build versions shouldn't be a (api-)problem ( like 2.22 -> 2.24 ), but i wouldn't recommenced without rebuild all others.
and it isn't allways a good idea, to exchange debian packages ( mostly libs ) with the oe build system from dmm.
applications maybe no problem or not widely used libaries ...
but only 1 changed api-call can result in an unusable box ( without reflashing ) ...

first the two missing libs,

2nd, i'm using the latest git-builds of gstreamer, which can cause incompatibilities.

but give it a try .. else u must wait for one, who is using the "main-stream"-build ...

//edit

btw. g_malloc_n was introduced in glib 2.24 ... afaik ist dmm still using 2.22 ...

try this one, maybe --nodeps required during install ...

Zitat von dreamblaster

Twisted Matrix Labs, GStreamer, QT und wie sie alle heissen einen dicken fetten Kuss geben und beten das die nie die Lizenzbedingungen ändern. Ein hoch auf Linux und frei verfügbare Software.
Apropos die haben teilweise auch einen Donate Button wenn wir schon bei Entwicklungskosten und Lizenzen sind. Ein Danke wäre angebracht. Just my 2 cents.

schönes modifziertes zitat aus dem clarke-tech forum
du weisst, oder der jenige der das geschrieben hatte, nicht, das dmm alle ihre patches offen legen und ihr diese auch nutzt.
einige der modifikationen fliessen auch zurück in die ursprungs-projekte.
das letzte was mir dazu einfällt sind bspw. änderungen an der linux-dvb api

kurz zusammengefasst: dmm arbeitet also auch mit "herstellern" von opensource zusammen
und geben was zurück, genau dem sinn entsprechend, wie es eigentlich mal gedacht war.
d.h. auch in zukunft wird sourcecode von dmm genutzt, die der opensource-community zur verfügung gestellt wurde,
ob gewollt oder nicht.

manchmal weiss man nicht ob man heulen, lachen oder mitleid zeigen soll, bei dem ganzen sch**ss der überall erzählt
und dann als rechtfertigung ( aufgrund von fehlinformationen ) genutzt wird.

die art der streamkomprimierung (mpegX) hat nichts mit dem transport-weg (dvb-tX) zu tun ...
d.h. in den hd boxen, kann mpeg4 auch mit dvb-t(1) empfangen werden ...

wenn der transportweg natürlich dvb-t2 ist, wird auch ein entsprechender tuner benötigt.

Homey, der hbbtv-browser der bei ct zum einsatz kommt, wurde nicht selbst entwickelt,
sondern nur eingekauft. ich geh mal davon aus, das die lizenz von opera verbietet,
das als opensource rauszugeben
( abgesehen davon haste recht ... das bringt nichts für die so oft zitierte "e2-community" <- alibi-argument, *lach*).

viel schlimmer finde ich das verhalten von vu, mit ihrem webbrowser.
der ist eigentlich opensource und unter der gpl, es gibt jedoch keine sourcen dazu
und es wird aktiv verhindert, das er auf anderen boxen läuft.

aber dieses verhalten ist bei allen e2-clone herstellern so: alles nehmen aber nichts zurückgeben.
deswegen werden diese auch so gerne als schmarotzer oder parasiten bezeichnet.

und sollte sich das bild vervollständigen, das es den e2-core nur noch als binary gibt,
sind alle anderen sowieso von der weiterentwicklung (größtenteils) ausgeschlossen.
mich pi*st es zwar auch an, wenn ich fürs experementieren an e2 nichts mehr oder so leicht ändern kann,
( das ist/war eines der hauptargumente für mich, eine dreambox zu holen, das ich, wenn ich will, auch selbst was ändern kann )
kann da aber dream voll verstehen. es gibt nunmal bei opensource keine andere möglichkeit,
dieses schmarotzertum ( teilweise ) zu unterbinden. die lizenz interessiert solchen leuten einfach nicht.

bereits jetzt hält sich keiner der hersteller an die alte lizenz.
irgendwo hier hatte bereits jmd. die lizenz gepostet. da ist ein satz drin, soetwas wie "derive a version ...".
das ist eine von programmierern anerkannte umschreibung für einen fork.
jedoch hat bis jetzt noch keiner der hersteller einen gpl fork erstellt.
es wird immer nur fleissig kopiert und alle änderungen, seitens dmm, werden übernommen.

to capitalize or take advantage of someone's work has nothing to do with competition ...

there is nothing to respect ...

kurzantwort: ja

mittlere version:
eigentlich ist udf 2.5/2.6 erst mit den 2.6.3xer kernel offiziell verfügbar.

jedoch war entweder dmm oder broadcom so freundlich
und hat die diffs backportet und lässt die in den kernel build mit einfliessen.

also ja, br können genauso gelesen/geschrieben werden,
wie jede normale cd/dvd, da das ansprechen der laufwerke,
aus sicht des os, genauso funktioniert.
ausgenommen nat. welche mit aacs und co. , wo es noch ein wenig bastelarbeit benötigt.
aber dir gehts ja ums schreiben ....

die consolen tools sind udf 2.6 fähig.
ob die guis angepasst werden müssen, ggf. auch nur wegen der größeren kapazitäten,
muss mal jmd. anderes beantworten, der das getestet hat oder die "dvd-burner" sourcen auswendig kennt.

greetz

btw. auf ne lange und ausführliche version verzichte ich mal.

habe den bd-brenner bei mir im einsatz.

aber erst mit oe 1.6 mach das ganze sinn, wenn auch bds genutzt werden sollen,
da dort udf 2.6 in den kernel reingepatcht wird.

inwiefern die ganzen "enigma2-plugins" auch bds erkennen
kann ich nicht genau sagen, da ich alles per console bediene.

auch die bd-tools, die irgendwo rumschwirren, und den richtigen keksen,
kann man einiges machen ( ist aber kein thema für dieses board ).

eine fertige gui für das abspielen ist jedoch nicht public.

greetz