16:9 Kennung in Bildsignal, Auto-Zoom Funktion

[jmittelst]

Dafür sind doch mittlererweile alle Menüs durchnummeriert.
Ob Du nun Blau-Zahl oder Blau-Zahl-Zahl (Flexmenü) oder Dbox-Zahl-Zahl tippst, ist doch Wurst.

cu
Jens

[Gorcon]

Im aktuellen yadi funktioniert das Plugin noch, nur nicht im JtG Image.

Dafür sind doch mittlererweile alle Menüs durchnummeriert.
Ob Du nun Blau-Zahl oder Blau-Zahl-Zahl (Flexmenü) oder Dbox-Zahl-Zahl tippst, ist doch Wurst.

finde ich nicht.

Gruß Gorcon

[elbarto]

Dafür sind doch mittlererweile alle Menüs durchnummeriert.
Ob Du nun Blau-Zahl oder Blau-Zahl-Zahl (Flexmenü) oder Dbox-Zahl-Zahl tippst, ist doch Wurst.

cu
Jens

Dbox-Zahl-Zahl funktioniert leider nicht, da die Skripte nicht nummeriert sind.

[jmittelst]

Dafür sind doch mittlererweile alle Menüs durchnummeriert.
Ob Du nun Blau-Zahl oder Blau-Zahl-Zahl (Flexmenü) oder Dbox-Zahl-Zahl tippst, ist doch Wurst.

cu
Jens

Dbox-Zahl-Zahl funktioniert leider nicht, da die Skripte nicht nummeriert sind.

Hmm - dachte, die wären es. Da merkt man dann, das ich das Flexmenü lieber mag

cu
Jens

[Gorcon]

Die Plugins sind aber durch nummeriert.

Gruß Gorcon

[DrStoned]

Die Plugins sind aber durchnummeriert.

Gruß Gorcon

Aber nur von 1-9, der Rest ist imho nur über die Cursortasten zu erreichen.
Ich habe ungefähr 25 Plugins und Scripts in meinem Flexmenü integriert, das wäre über das Features-Menü eine Katastrophe.

Greetz von DrStoned

[Nico 77]

Es wäre nett wenn wir zum Thema zurückkommen.

Hat jemand den Source zu dem Plugin oder eine aktuelle Version?

[DrStoned]

Es wäre nett wenn wir zum Thema zurückkommen.

Hat jemand den Source zu dem Plugin oder eine aktuelle Version?

Da kannst Du Dir hier einen Shellstarter runterladen und ihn nach der Anleitung umpatchen. Damit rufst Du dann das Script auf, das Du erstellst, wie Jens das beschrieben hat.

Und in der *.cfg Datei statt

Code: Alles auswählen

type=3

Code: Alles auswählen

type=2

eintragen.

Vorher im JtG-Forum registrieren und einloggen, sonst geht der Download nicht.

Greetz von DrStoned

[Flusskrebs]

Entschuldigt bitte, wenn ich hier mal das Thema aufgreife. Ich habe das Plugin in einer DB2 2xI mit einem NG-Neutrino-Image Sat genutzt. Hat SUPER funktioniert!!!!
Seit dem Update auf das neueste Image vom November funktionieren die Plugins nicht mehr. Habe Sie unter der blauen Taste im Menü, aber wenn ich Sie aufrufe spricht keine Taste der Fernbedienung mehr an und ich muss den Stecker ziehen. Hat jemand eine Lösung?

[DrStoned]

Das hängt mit diesem Problem zusammen. Da inzwischen leider die Bilder nicht verfügbar sind, lies zur näheren Erläuterung noch bitte diesen Beitrag.
Falls Du die beigefügten Beispiel-Shellstarter runterladen möchtest, musst Du dich vorher im JtG-Forum anmelden und einloggen.

By the way, Dein Image ist nicht legal und wird hier nicht supportet.

Greetz von DrStoned

[Flusskrebs]

Das hängt mit diesem Problem zusammen. Da inzwischen leider die Bilder nicht verfügbar sind, lies zur näheren Erläuterung noch bitte diesen Beitrag.
Falls Du die beigefügten Beispiel-Shellstarter runterladen möchtest, musst Du dich vorher im JtG-Forum anmelden und einloggen.

By the way, Dein Image ist nicht legal und wird hier nicht supportet.

Greetz von DrStoned

Vielen Dank, ich habe schon an meinem Verstand gezweifelt!!!!

[dwilx]

Ich möchte das Thema mit dem Autozoom wieder anstoßen, da ich mir da mal einige Gedanken dazu gemacht habe und ich denke, dass dies auch machbar sein sollte, wenn man das mal ganz von vorne angeht. Ich kann das aber nicht alleine, da sich meine Programmierkenntnisse im wesentlichen auf VB beschränken und in C++ nur sehr begrenzt sind. Die Frage geht also an, die die sich mit der Materie auskennen. Es wäre super, etwas testbares vorweisen zu können. Momentan bin ich gerade dabei die Zoom-Plugins neu zu schreiben. Es wird aber wohl dann nur noch eins sein, dass alles macht, was die bisherigen machen. Sollte das Autozoomen funktionieren, würde das Plugin als Ergänzung auch weiterhin arbeiten oder per Menü in GUI gehen. Das ist aber eine andere Geschichte.

Wie schon gesagt wurde, wäre es evtl. möglich die Sache mit dem Capture-Treiber zu lösen. Das dürfte der aber wohl nicht selbst machen, da der SAA7126 der dbox kein Black-Bar-Detection macht. Die Radikallösung wäre ein neuerer anderer Chip, der das kann. In so mancher Glotze ist Black-Bar-Detection ja Serienmäßig drin, aber solche Basteleien kann man wohl vergessen. Bleibt wohl nur eine Softwarelösung, die aber der Box nicht "weh" tut, Stichwort: CPU-Leistung.

Es müsste also ein Dämon her, der sich einen Schnappschuß holt und den auswertet.
Ich habe so einen mal in mein cdk-gepackt und auf den Namen wssd getauft, aber damit der auch was macht, suche ich erstmal eine saubere Lösung, um so einen brauchbaren Schnappschuß zu bekommen. Aber wie.

Es wurde schon mal gesagt, dass die /dev/dbox/capture0 eine Quelle dafür sein könnte. Das scheint auch funktioniert zu haben, aber scheiterte wohl an der genaueren Auswertung. Den passenden Algorithmus zu bauen dürfte knifflig sein. Wenn dies das Problem war, wäre es doch super, den Quellcode zur Verfügung zu stellen, um das gemeinsam zu lösen!

Eine andere Möglichkeit wäre evtl. die Nutzung diverser Erfahrungen mit der Mosaik-Geschichte.
http://forum.tuxbox-cvs.sourceforge.net ... ght=mosaik
http://forum.tuxbox-cvs.sourceforge.net ... ght=mosaik
Dort ging es um das Abbilden von kompletten Bildern, aber das wäre in unserem Fall ja nicht nötig, da es ja nur gewisse Bildbereiche (mitte-oben, mitte-unten) betrifft, die für die Auswertung in Frage kommen.
Wäre das ein Ansatz?

In der Hoffnung, dass wir weiterkommen, verbleibe ich erstmal...

[Gorcon]

Hört sich schon mal interessant an.

Gruß Gorcon

[dwilx]

Ich habe mich mal umgesehen. evtl. hilft uns das hier etwas mehr:

http://www.koders.com/cpp/fidC97E14149D ... BB306.aspx

In dem Code gibts eine BBD-Funktion. Wäre das für uns von Nutzen?

Hier mal ein Code-Schnipsel, mehr steht auf dem Link:

Code: Alles auswählen

//----------------------------------------------------------------------------
// Scan the top or bottom of a letterboxed image to find out where the picture
// starts.
//
// The basic idea is that we find a bounding rectangle for the image (which
// is assumed to be centered in the overlay buffer, an assumption the aspect
// ratio code makes in general) by searching from the top down to find the first
// scanline that isn't all black.  "All black" means that there aren't many
// pixels with luminance above a certain threshold.
//
// To support letterboxed movies shown on TV channels that put little channel
// logos in the corner, we allow the user to configure a percentage of the
// image that will be ignored on either side.  We only look at pixels in the
// middle of the image, so channel logos will be ignored.  The default is 15%.
// This is in addition to any pixels we ignore due to the m_Overscan setting.
//
// For speed's sake, the code is a little sloppy at the moment; it always
// looks at a multiple of 4 pixels.  It never looks at *more* pixels than are
// requested, though.
static inline int GetNonBlackCount(BYTE* Line, int StartX, int EndX)
{
    int qwordCount = (EndX - StartX) / 4;
    int threshold;
    int counts;
    __int64 luminances;
    __int64 chromaMins;
    __int64 chromaMaxes;
	__int64 totals;
    const __int64 YMask = 0x00FF00FF00FF00FF;
    const __int64 OneMask = 0x0001000100010001;
    int chromaMin, chromaMax;

    if (qwordCount <= 0)
    {
        return 0;
    }

    // Black pixels are U=128 and V=128.  If U or V is significantly
    // different from 128, it's a different color, e.g. green if
    // they're both 0.  We compare each U and V Value to the chroma
    // min and max computed here: if ((chroma - chromaMin) > chromaMax)...
    chromaMax = AspectSettings.ChromaRange;
    if (chromaMax > 255)
        chromaMax = 255;
    chromaMin = 128 - (chromaMax / 2);

    threshold = AspectSettings.LuminanceThreshold;
    if (threshold > 255)
    {
        threshold = 255;
    }

    luminances = threshold;
    luminances |= (luminances << 48) | (luminances << 32) | (luminances << 16);
    chromaMins = chromaMin;
    chromaMins |= (chromaMins << 48) | (chromaMins << 32) | (chromaMins << 16);
    chromaMaxes = chromaMax;
    chromaMaxes |= (chromaMaxes << 48) | (chromaMaxes << 32) | (chromaMaxes << 16);

    // Start on a 16-byte boundary even if it means ignoring some extra
    // pixels?  Try not doing it for now, but it could make memory access
    // more efficient.

    Line += StartX * 2;

    _asm {
        mov     ecx, qwordCount
        mov     eax, dword ptr[Line]
        movq    mm1, YMask
        movq    mm2, luminances
        movq    mm3, OneMask
        pxor    mm4, mm4            // mm4 = pixel counts, one Count in each word
        movq    mm6, chromaMins
        movq    mm7, chromaMaxes

BlackLoop:
        movq    mm0, qword ptr[eax] // mm0 = next 4 pixels
        movq    mm5, mm0
        psrlw   mm5, 8              // mm5 = chroma values in lower 8 bits of each word
        pand    mm0, mm1            // mm0 = luminance values in lower 8 bits of each word
        pcmpgtw mm0, mm2            // mm0 = 0xFFFF where luminance > threshold
        psubw   mm5, mm6            // mm5 = chroma - chromaMin
        pand    mm5, mm1            // mm5 = lower 8 bits of (chroma - chromaMin); <0 becomes positive
        pcmpgtw mm5, mm7            // mm5 = 0xFFFF where chroma < chromaMin or chroma > chromaMax
        por     mm0, mm5            // mm0 = 0xFFFF where U, V, or Y is past threshold
        pand    mm0, mm3            // Translate that into 1 for exceed, 0 for not, in each word
        paddw   mm4, mm0            // And add up the ones, maintaining four separate counts
        add     eax, 8              // Next qword
        loop    BlackLoop

		movq	totals, mm4			// Save totals so C code can deal with them
        emms
    }

	// Add up the four totals (each in one word of the "totals" qword) to
	// get the total overall count.
	counts = (int)(totals & 0xffff) +
			 (int)((totals >> 16) & 0xffff) +
			 (int)((totals >> 32) & 0xffff) +
			 (int)((totals >> 48) & 0xffff);

    //
    // Log the offending pixels
    if (counts > 0) 
    {
        LOG(3, "Count %d min %d max %d lumthresh %d", counts, chromaMin, chromaMax, threshold);
    }
    

    return counts;
}

Wenn man ein entsprechendes Bild so vorliegen hätte, so wie man es für diese Funktion braucht, müsste es doch möglich sein, dies einzubauen!

[Carjay]

Na, dann braucht ihr der guten alten dbox2 ja nur noch die MMX-Einheit nachzurüsten, damit der Code spielt. Ich würde dann allerdings direkt SSE2 empfehlen.

Aber Spaß beiseite, das Problem ist die Analyse. Mangels dedizierter Hardware müßte sich die CPU um das Auslesen und Filtern des Bildinhalts kümmern. Die Rechenzeit würde anderen Prozessen fehlen.

Der GTX/eNX wurde nicht als Framegrabber konzipiert, sondern eigentlich ist das Capturen für (internes) PIP gedacht gewesen. Dabei erfolgt das Auslesen und Zurückschreiben in die YCbCr-Plane per DMA ins bzw. vom Demux-RAM, belastet also die CPU nicht.

Ihr könntet natürlich eine verkleinerte Variante des Bildes capturen (dann wäre die Last nicht ganz so groß) bzw. die volle SD-Auflösung paßt sowieso nicht in das für's Capturen reservierte Demux-RAM.

Wie zuverlässig/effektiv das Ganze funktionieren würde kann man nur durch Ausprobieren herausfinden.

Fragt sich nur, wer das umsetzen mag?

[Tommy]

eigentlich muß es doch nur beim EPG Sendungswechsel bzw senderwechsel gemacht werden? Ist gelb im normalbetrieb nicht noch frei? Dann evtl. zusätzlich händisch bei gelb eine erkennung durchlaufen und fedsch.

[dwilx]

Ihr könntet natürlich eine verkleinerte Variante des Bildes capturen (dann wäre die Last nicht ganz so groß) bzw. die volle SD-Auflösung paßt sowieso nicht in das für's Capturen reservierte Demux-RAM.

... mehr wäre auch nicht nötig. So ähnlich stehts ja in dem Code-Schnipsel drin. Der Code ist da schon mal eine Anregung, auch wenn er zu einem anderen Projekt gehört...

Code: Alles auswählen

// To support letterboxed movies shown on TV channels that put little channel
// logos in the corner, we allow the user to configure a percentage of the
// image that will be ignored on either side.  We only look at pixels in the
// middle of the image, so channel logos will be ignored.  The default is 15%.
// This is in addition to any pixels we ignore due to the m_Overscan setting.

Das wird ja Im konkreten Fall auch so gemacht, quasi nur ein kleinerer Bereich in der Mitte des Bildes wird untersucht, eben 15% als Standard. In dem Fall sogar prozentual einstellbar, damit man auch sicher sein kann, nicht irgendwelche Senderlogos drinne zu haben. Und so wie ich das bisher mitbekommen habe, hatte wojo seinerzeit nach den schwarzen Balken gesucht, hier wird aber das Bild gesucht, um die Grenze Bild/Blackbar im Bereich bestimmter Zeilennummern zu finden. Die Nummer wird dann zurückgegeben.

Na, dann braucht ihr der guten alten dbox2 ja nur noch die MMX-Einheit nachzurüsten,...

Wie ich bereits sagte:

... solche Basteleien kann man wohl vergessen. Bleibt wohl nur eine Softwarelösung, die aber der Box nicht "weh" tut, Stichwort: CPU-Leistung.

Könnte man zum Capturen nicht den Code von vgrab etwas anpassen und hierfür verwenden?

Wie zuverlässig/effektiv das Ganze funktionieren würde kann man nur durch Ausprobieren herausfinden.

Fragt sich nur, wer das umsetzen mag?

Schon wärs natürlich, wenn sich ein Entwickler der Sache annimmt und einen Code bereitstellt, an dem man basteln könnte. Man könnte gemeinschaftlich auch einiges an Codeschnipseln hier zusammentragen.
Images erstellen und zum testen hier anzubieten, wäre das geringste. Dafür wird sich sicher Webspace finden. Das könnte ich schon übernehmen.

eigentlich muß es doch nur beim EPG Sendungswechsel bzw senderwechsel gemacht werden? Ist gelb im normalbetrieb nicht noch frei? Dann evtl. zusätzlich händisch bei gelb eine erkennung durchlaufen und fedsch.

Gelb ist nicht so ganz frei, da ja die Bildoptionen für die Anwahl der Unterkanäle drauf liegen. Das müsste man dann irgendwie regeln.

[MajorK]

Freut mich, dass das Thema wieder aufgegriffen wird.

Code: Alles auswählen

// (...) we allow the user to configure a percentage of the
// image that will be ignored on either side.  (...)
// (...) The default is 15%.

(...)nur ein kleinerer Bereich in der Mitte des Bildes wird untersucht, eben 15% als Standard.

Fuer mich hoert sich das eher an, als sei der Standard hier 70%, aber egal.
Die Auto-Zoom-Funktion wuerde mir auch gefallen, anamorph scheint bei "den Privaten" ein Fremdword zu sein...

Major K.

[dwilx]

Fuer mich hoert sich das eher an, als sei der Standard hier 70%, aber egal.

Sorry hab ich verdreht! Tatsache ist aber, dass man das variieren kann/muss!

[rasc]

Aber Spaß beiseite, das Problem ist die Analyse. Mangels dedizierter Hardware müßte sich die CPU um das Auslesen und Filtern des Bildinhalts kümmern. Die Rechenzeit würde anderen Prozessen fehlen.

Der GTX/eNX wurde nicht als Framegrabber konzipiert, sondern eigentlich ist das Capturen für (internes) PIP gedacht gewesen. Dabei erfolgt das Auslesen und Zurückschreiben in die YCbCr-Plane per DMA ins bzw. vom Demux-RAM, belastet also die CPU nicht.

Ihr könntet natürlich eine verkleinerte Variante des Bildes capturen (dann wäre die Last nicht ganz so groß) bzw. die volle SD-Auflösung paßt sowieso nicht in das für's Capturen reservierte Demux-RAM.

Wie zuverlässig/effektiv das Ganze funktionieren würde kann man nur durch Ausprobieren herausfinden.

Fragt sich nur, wer das umsetzen mag?

Mhh, eigentlich muesste das machbar sein - auch ohne PIG.
Nur irgendwie ist das Capture-Device doch nicht sauber implementiert (oder inzwischen doch?)

Ansatz: man muss nur ein paar Bildpunkte untersuchen und auf echte Schwarzwerte testen, dann waere eine Entscheidung schon möglich.

Nachteile:

Ein guter TV und die dbox2 könnten in einen Zooming-Krieg ausbrechen (TV zoomt, dbox2 2 Sekunden spaeter auch, TV schaltet wieder zurueck, bla ;-) )

Und bei Nachtaufnahmen wird es schwierig, wenn man nur ein paar Bildpunkte testet... Das kann dann auch schonmal heftig ins Auge gehen.

Es passt nicht sauber in das Daemonen-Konzept von Neutrino... 8(

[dwilx]

@rasc

Nachteile:

Ein guter TV und die dbox2 könnten in einen Zooming-Krieg ausbrechen (TV zoomt, dbox2 2 Sekunden spaeter auch, TV schaltet wieder zurueck, bla )

Das dürfte nicht passieren, da die Box das WSS-Signal ja zum TV schickt und das hat mehr Gewicht, wenn das Signal entsprechend anliegt, als das was der TV will. Bei den Plugins hat man das ja auch gesehen. Mein TV, macht nur das was die Box will und ist den WSS-Kommandos ausgeliefert. Ausserdem ließe sich das ja auch abschalten!
Man müsste das mal zumindest testen können, bevor man das genau sagen kann!

[Gorcon]

Ich glaube auch das man erstmal die Auswertung des Bildes vornehmen sollte und dann kann man immernoch an der "logik" basteln.

Wenn man zB. das Bild auswertet und der Mittelpunkt (wo also immer etwas sein sollte) schwarz ist, dann sollte die Auswertung wiederholt werden bis dort ein Bild kommt und sich gegebenfalls von Balken absetzt.

Gruß Gorcon

[Carjay]

Mhh, eigentlich muesste das machbar sein - auch ohne PIG.
Nur irgendwie ist das Capture-Device doch nicht sauber implementiert (oder inzwischen doch?)

PIG ist die - von C-Cube geschützte - Abkürzung für "Picture-In-Graphics". Im Grafik-Jargon nennt man es manchmal einfach "YUV-Plane".

Die digitalen SD-Videodaten werden vom MPEG2-Dekoder durch den Demux geschliffen (damit dieser dann eben die YUV und RGB-Ebenen einschleifen kann), dabei können die Daten auch abgegriffen werden. Per DMA versteht sich.

Eigentlich nicht das große Problem.

Könnte man zum Capturen nicht den Code von vgrab etwas anpassen und hierfür verwenden?

Ah, mein gutes vgrab.

Das hab ich für Tests im Zusammenhang mit den Treibern des 2.6er Kernel geschrieben, ich weiß gar nicht mehr, ob das mit den aktuellen 2.4er Treibern überhaupt korrekt spielt, die V4L2-API ist da nicht ganz korrekt implementiert.

Aber das Outdoor-Plugin macht auch nichts anderes. Und das läuft auf beiden Kerneln. Das Dekodierungsverfahren der komprimierten (gesquashten, hat aber nichts mit dem SquashFS zu tun) Daten kann man aus dem "unsquasher.c"-Code entnehmen.

So kompliziert ist das nicht, die Umsetzung kostet nur ein bißchen Zeit.

[rasc]

Mhh, eigentlich muesste das machbar sein - auch ohne PIG.
Nur irgendwie ist das Capture-Device doch nicht sauber implementiert (oder inzwischen doch?)

PIG ist die - von C-Cube geschützte - Abkürzung für "Picture-In-Graphics". Im Grafik-Jargon nennt man es manchmal einfach "YUV-Plane".

So kompliziert ist das nicht, die Umsetzung kostet nur ein bißchen Zeit.

... es hat Gründe, warum das "channel Mosaic" nie realisiert wurde. Wenn es kein Problem ist, dann einfach capture.cpp in Neutrino komplettieren.... 8/

(dann kommt auch das channel-Mosaic, das nie fertiggestellt werden konnte ;-) )

[mb405]

jo hab das schon mal vor langer zeit eincompiliert.
es zappt durch die kanäle, jeweils einen kanal in einen neuen fenster.
man kann den code als lernobjekt verstehen