[vdr] [ANNOUNCE] VDR developer version 1.7.8

  • Frisch von der VDR ML


  • leider kommt jetzt beim kompilieren von xineliboutput:


    In file included from xineliboutput.c:35:
    device.h:116: error: âeVideoAspectâ has not been declared
    ../../../include/vdr/device.h:380: warning: âvirtual void cDevice::GetVideoSize(int&, int&, double&)â was hidden
    device.h:116: warning: by âvirtual void cXinelibDevice::GetVideoSize(int&, int&, int&)â
    make: *** [xineliboutput.o] Error 1


    Idee wie man das lösen kann?

  • -gelöscht-

  • Frage an den Meister (in der Hoffnung dass er hier mitliest):


    wozu wird cTsToPes genutzt? Kann dies von einem Ausgabeplugin verwandt werden, wenn das Ausgabedevice kein TS wiedergeben kann, sondern nur PES? Welche Funktionen braucht das Ausgabeplugin in diesem Fall? Ich habe hier inzwischen völlig den Überblick verloren, zumal in device.h viel mehr Funktionen stehen, als in der PLUGINS.html erwähnt werden:


    PlayVideo
    PlayAudio
    PlayPesPacket
    PlayTsVideo
    PlayTsAudio
    PlayTsSubtitle
    PlayPes
    PlayTS


    Zu PlayTSVideo und PlayTSAudio habe ich dies hier gefunden:
    http://www.linuxtv.org/piperma…/2009-January/019398.html
    Udo schrieb "These two functions are only used by devices that do not implement their
    own PlayTsXXX functions. The FF DVB devices don't use them any more,
    since TS is passed to (patched) DVB drivers. Other devices will soon
    play TS directly too." Der letzte Satz erscheint mir doch sehr optimistisch :)
    Werden diese Funktionen in vdr bleiben, oder ist damit zu rechnen, dass sie rausfliegen?


    Ich würde es jedenfalls sehr begrüßen, wenn nicht jedes Ausgabeplugin das Rad neu erfinden müsste, um den TS in PES zu verwandeln.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.


  • Da sich im VDR die Funktion geändert hat muss das natürlich auch in den entsprechenden Plugins nachgezogen werden.



    Quote

    Original von Dr. Seltsam
    Frage an den Meister (in der Hoffnung dass er hier mitliest):

    Da fühle ich mich zwar nicht angesprochen ;D


    Quote

    Original von Dr. Seltsam
    wozu wird cTsToPes genutzt? Kann dies von einem Ausgabeplugin verwandt werden, wenn das Ausgabedevice kein TS wiedergeben kann, sondern nur PES?

    Hier aber schon :)
    Die Klasse kann benutzt werden, man muss halt darauf achten, dass für jeden Stream (z.B. 1x Video, 2x Audio) eine eigene Instanz kreiert wird und genau so benutzt wird wie es im Headerfile beschrieben ist.

  • Hallo



    Schau dir einfach mal device.c genauer an...



    Hier wird nun automatisch Ts nach Pes umgewandelt und dann mittels PlayVideo dem Plugin übergeben. Somit muss bei einem Pes only Ausgabedevice nichts geändert werden um Ts
    abspielen zu können.


    Quote

    Original von Dr. Seltsam
    Ich würde es jedenfalls sehr begrüßen, wenn nicht jedes Ausgabeplugin das Rad neu erfinden müsste, um den TS in PES zu verwandeln.


    Das hat sich erübrigt, da dies - siehe oben - der VDR macht.


    lg,
    Christian


  • Manchmal ist das Timing doch wirklich seltsam... (in diesem Fall im doppelten Sinne! ;) )


    Vor 5 Minuten habe ich eine Mail an Klaus geschrieben, weil das obige Problem - immerhin von Januar - immer noch besteht. Gedacht ist es jedenfalls so, dass die PlayTs-Funktionen per Default alles nach PES konvertieren. Ausgabedevices können TS aber auch selbst handlen, und offensichtlich tun das wohl die meisten Ausgabedevices auch.


    Jedenfalls verliert seit damals PlayTsVideo und PlayTsAudio immer dann ein PES-Paket, wenn PlayVideo/PlayAudio gemäß all-or-nothing ein PES-Paket komplett ablehnt. Der oben verlinkte Patch funktioniert übrigens auch immer noch.


    Gruß,


    Udo

  • Quote

    Original von Urig
    Gedacht ist es jedenfalls so, dass die PlayTs-Funktionen per Default alles nach PES konvertieren.


    sind das inzwischen bessere PES-Pakete (einheitlich 2 k groß mit belegetm PES Length Field) als bei vdr 1.7.1? Dessen PES lief auf der PVR350 nämlich nicht richtig.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Die PES-Pakete können jetzt bis MAXPESLENGTH=0xFFF0 groß werden, also knapp 64k. Sobald ein PES-Paket fertig ist, muss es abgeholt werden, da das nächste TS-Paket mit StartBit (TsPayloadStart) den Puffer verwirft. Demnach bestehen Audiopakete immer aus einem Frame (ca 1,5k glaube ich), aber Videopakete können bis zu 64k groß werden (und sind auch dann u.U noch nicht vollständig). Das Length Field wird in GetPes() auf die richtige Länge gesetzt.

  • Quote

    Originally posted by Dr. Seltsam


    sind das inzwischen bessere PES-Pakete (einheitlich 2 k groß mit belegetm PES Length Field) als bei vdr 1.7.1? Dessen PES lief auf der PVR350 nämlich nicht richtig.


    Es sind IMHO schlicht die PES-Pakete, die die in dem TS-Datenstrom eingebettet sind, und damit sind sie so groß, wie sie der Fernsehsender gemacht hat.


    Der gesamte Repacker-Kram, der noch in VDR-1.6 mitläuft, ist ja mit dem Wechsel auf TS-Recording weitgehend wieder verschwunden.


    Gruß,


    Udo

  • Quote

    Original von Austrian Coder
    Somit muss bei einem Pes only Ausgabedevice nichts geändert werden um Ts
    abspielen zu können.


    ganz so einfach scheint es doch nicht zu sein.


    Das Bild ist zumindest i.O., auf einigen DVB-Sendern wie ZDF und auf sämtlichen pvrinput-Kanälen bleibt es jedoch schwarz.


    Ich habe keinen Ton: wie schon bei vdr 1.7.1 bemängelt mein pvr350-Plugin, dass in PlayAudio die Id mit 0x00 übergeben wird.
    Die Diskussion hatten wir schon mal hier:
    [ANNOUNCE] VDR developer version 1.7.1 uff,


    die device.h sagt inzwischen


    virtual int PlayAudio(const uchar *Data, int Length, uchar Id);
    ///< Plays the given data block as audio.
    ///< Data points to exactly one complete PES packet of the given Length.
    ///< Id indicates the type of audio data this packet holds.
    ///< Note that as of version 1.7.1 Id is obsolete and may be 0 (in case of
    ///< TS replay). Plugins that need to know this Id shall read it from the
    ///< actual PES data (it's the 4th byte).


    kann mir jemand helfen, wie ich das mache?

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Quote

    Original von Austrian Coder
    In der Methode bool cDxr3PesFrame::parse(const uint8_t *pes, uint32_t length).


    Das wäre dann ja einfach ein pes[3].


    Aber mal ne andere Frage: Wie unterscheidet man die Audio-Streams bei Arte? Project X sagt dazu:

    Code
    1. ok> PID 0x0191 has PES-ID 0xE0 (MPEG Video) (1316 #8)
    2. ok> PID 0x0193 has PES-ID 0xC0 (MPEG Audio) (3760 #21)
    3. ok> PID 0x0192 has PES-ID 0xC0 (MPEG Audio) (4136 #23)

    Ja, richtig: zwei Audio-Streams mit unterschiedlicher (TS-)PID, aber gleicher PES-ID!


    Ist das überhaupt standardkonform (ich fürchte ja...)?
    Muss man dann die PES-IDs selbst verwalten und jedes PES-Paket entsprechend patchen???

  • Quote

    Original von Austrian Coder
    Ich hoffe das hilft dir weiter.


    Vielen Dank, habe den Wald vor lauter Bäumen nicht gesehen. In PlayAudio ist es dann Data[3]. Habe das wie folgt eingebaut:

    Code
    1. #if VDRVERSNUM < 10701
    2. switch (Id) {
    3. #else
    4. switch (Data[3]) {
    5. #endif
    6. case 0x80 ... 0x87 : // AC3

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • hm... wieso klappt AC3 nicht? Der Code im pvr350-Plugin führt bei Stream-Id 0x80 bis 0x87 eine interne Conversion in mpeg-Audio durch. Aber wenn ich mittels Menü-Grün einen Dolby Digital-Tonkanal anwähle, kriege ich jetzt immer nur 0x00 als Data[3] in PlayAudio ausgewiesen.
    Die Auswahl der übrigen Tonkanäle klappt einwandfrei.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    The post was edited 2 times, last by Dr. Seltsam ().

  • Quote

    Original von Dr. Seltsam
    hm... wieso klappt AC3 nicht? Der Code im pvr350-Plugin führt bei Stream-Id 0x80 bis 0x87 eine interne Conversion in mpeg-Audio durch. Aber wenn ich mittels Menü-Grün einen Dolby Digital-Tonkanal anwähle, kriege ich jetzt immer nur 0x00 als Data[3] in PlayAudio ausgewiesen.
    Die Auswahl der übrigen Tonkanäle klappt einwandfrei.


    Weil die Stream-ID (PES-ID) bei AC3 0xBD, nicht 0x80..0x87 ist?
    (Habe mir den Code des PVR350-Plugin allerdings nicht angesehen.)


    CU
    Oliver

  • Hi


    ich bekomme den VDR 1.7.7 und auch den neuen 1.7.8 nicht zum laufen!
    Habe jetzt schon einige DVB treiber ausprobiert aber ich bekomme immer wieder die Meldung


    Code
    1. In file included from dvbdevice.h:14,
    2. from vdr.c:45: /usr/local/src/DVB/linux/include/linux/dvb/frontend.h:92: error: '__u8' does not name a type
    3. /usr/local/src/DVB/linux/include/linux/dvb/frontend.h:93: error: '__u8' does not name a type /usr/local
    4. /src/DVB/linux/include/linux/dvb/frontend.h:98: error: '__u8' does not name a type /usr/local/src/DVB/linux
    5. /include/linux/dvb/frontend.h:99: error: '__u8' does not name a type /usr/local/src/DVB/linux/include/linux
    6. /dvb/frontend.h:361: error: '__u8' does not name a type make: *** [vdr.o] Fehler 1


    Habe Debian lenny auf squeeze per dist-upgrade erneuert und auch schon xine ffmpeg x264 usw. fertig.
    Mein Kernel ist der 2.6.26-2-486!
    Und ich habe eine Technotrend DVB-C 1501 (baugleich mit der DVB-S2 TT 3200}


    Kann mir jemand weiter helfen?

    1. Asus AT3N7A-I (ION) mit yavdr 0.3a und 500Gb Festplatte
    2. Asus AT5ion-t (ION2) mit yavdr 0.3a 16gb SSD Systemplatte und 2TB für Aufnahmen
    3. Gigabyte GA-K8NXP-SLI yavdr 0.3a alter VDR wird als Server dienen (im Aufbau)

    The post was edited 2 times, last by sviper ().

  • Quote

    Original von UFO


    Weil die PES-Id bei AC3 0xBD, nicht 0x80..0x87 ist?
    (Habe mir den Code des PVR350-Plugin allerdings nicht angesehen.)


    bisher hat vdr in PlayAudio dies aber als id für ac3 übergeben. Das ist aber nicht das Kernproblem:
    Data[3] ist 0x00, wenn ich im Menü einen AC3-Tonkanal auswähle.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • HI


    hat leider nichts gebracht!
    Gleicher Fehler wie oben!


    Welche treiber muss ich den eigentlich nehmen! Vieleicht geht es ja mit anderen Treibern!
    Oder sollte ich auf den unstable Kernel 2.6.29 gehen?
    Und was ist eigentlich eine Mailinglist?


    MFG

    1. Asus AT3N7A-I (ION) mit yavdr 0.3a und 500Gb Festplatte
    2. Asus AT5ion-t (ION2) mit yavdr 0.3a 16gb SSD Systemplatte und 2TB für Aufnahmen
    3. Gigabyte GA-K8NXP-SLI yavdr 0.3a alter VDR wird als Server dienen (im Aufbau)