Radioaufnahmen abspielen

  • Hallo *,


    viele Threads beschäftigen sich mit dem digitalen Radioempfang. Nur stelle ich leider fest, dass ich bei der Wiedergabe einer aufgenommenen Radiosendung nicht die wirkliche Spieldauer der Aufnahme angezeigt bekomme, sondern irgend etwas, das im Durchschnitt nur die Hälfte ist. Die Wiedergabe funktioniert soweit auch sehr gut, nur das Spulen nicht, das ist mehr als schnell. Gehe ich dazu noch auf Pause, startet sich der VDR innerhalb kurzer Zeit ohne Angabe von Gründen neu.


    Ist einem Das auch schon aufgefallen? Ich habe bisher damit "gelebt" und es schon mit mehreren Versionen beobachtet. Nur jetzt dachte ich, ich/man könnte etwas dagegen tun und die Frage: Wurde/wird das schon in irgend welchen Threads beackert?

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Hallo,


    das mit der Zeit und dem Spulen hängt damit zusammen, dass der VDR die Zeit aus der Dateigroesse berechnet (wenn ich mich nicht irre kam mal sowas in der Mailinglist), und mit der Groesse von Radioaufnahmen dementsprechend nicht umgehen kann.


    Die anderen Beobachtungen kann ich mit Dir teilen, ohne leider eine Loesung zu haben...


    der Leidensgenosse,


    Hannes


    robbitobbi://Scenic xB @ 866MHz/~Nexus2.1 - Budget TT 1.0 (Empfangs-VDR)
    fliewatueuet://ScenicxB @ 800MHz/~i810fb-xinelibout (Client)

  • Ich nehme weniger die Dateigröße an, sondern die I-Frames (index.vdr). ;)
    Aber ehe ich da wirklich ansetze, wollte ich halt Material sammeln, nicht das da schon jemand etwas gemacht hat, und ich nur zu dumm bin, es zu finden.

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Hat schon jemand vielleicht eine Lösung gefunden? Ich habe jetzt den vdr-1.3.37 und den dvb-Treiber 1.1.1 mit der FW-2622.


    Aber immer noch keine Besserung. Mir sagte jemand, dass es ab Version vdr-1.3.24 geht, aber offensichtlich doch noch nicht.

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Hi,


    Das hat nicht mit dem Treiber oder der Firmware zu tun, das ist ein reines Feature des VDR.


    Das Problem ist einfach das die Bitrate des Audiostream im allgemeinen nicht konstant sind, sondern sie sind meist variabel. (VBR), Ausnahmen bestätigen die Regel. ;)


    Deshalb, um auf die korrekte Abspiellänge kommen müsste der komplette Audiostream demuxt werden und aus allen MPEG-Paketen des Stream der Header extrahiert werden, aus denen das Bitrate ermittelt werden, diese einzelne Bitrate mit der Paketlänge multipliziert und für alle MPEG-Pakete aufsummiert ergibt die Abspiellänge. (Ich gehe mal vereinfacht davon aus das keine Aufnahmefehler vorliegen)


    Die Schwierigkeit dabei ist das diese Analyse, wie das Schneiden ein längerer Vorgang ist.
    Sollte dies beim Starten der Wiedergabe passieren, kommt es zu merklichen Verzögerungen, und wer will das schon.


    Und ob es schon während der Aufnahme möglich kann ich nicht beurteilen, zumindest dürfte zu einer zusätzlichen CPU-Belastung während der Aufnahme führen denn kompletten Stream zu analysieren.


    Es wird erstmal keine Lösungen des Problems geben, es sei jemand macht es .... ;D



    Nur meine Gedanken dazu,
    Andreas

  • Zitat

    Original von Hulk
    Es wird erstmal keine Lösungen des Problems geben, es sei jemand macht es .... ;D


    Habe es verstanden ;) Vielleicht beschäftige ich mich Weihnachten mal damit.

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Zitat

    Original von Hulk


    Das Problem ist einfach das die Bitrate des Audiostream im allgemeinen nicht konstant sind, sondern sie sind meist variabel. (VBR), Ausnahmen bestätigen die Regel. ;)


    Sorry, aber genau das glaube ich nicht, eher das Gegenteil ist doch der Fall. Also zumindest habe ich bislang noch keinen einzigen Radiosender gehört, der VBR nutzt. Die öffentlich-rechtlichen hatten bislang alle konstant 192kbit/s, seit der neue ARD-Hörfunktransponder aktiv ist, haben sie fast alle konstant 320 kbit/s. Die Premiere Pay-Radio Sender sind auch alle CBR. Welcher Sender soll denn zum Beispiel VBR sein, würde das gerne mal mit FEMON ausprobieren.


    Zusätzliche Verständnisfrage: Warum klappt es eigentlich bei normalen VDR Aufnahmen, also die *mit* Video, ohne Probleme, denn das normale Videosignal ist ja sehr wohl VBR?


    Kann es sein, dass das VBR-"Argument" nur eine Ausrede ist, das Thema nicht anzupacken?

  • Zitat

    Original von Demnos
    Kann es sein, dass das VBR-"Argument" nur eine Ausrede ist, das Thema nicht anzupacken?


    Für mich nicht. Ich habe nur derzeit ein sehr schlimmes Zeitproblem. Und noch ein bevorstehenden Serverwechsel, auf dem alles bei mir läuft. Von der Entwicklung über den VDR bis hin zum Surfen.


    Aber ich glaube auch nicht so recht, dass es an VBR liegt. Hatte ich ja schon weiter oben gesagt. Aber wenn du femon aufrufst, siehst du, dass die Bitrate beistens nicht bei 192, sondern bei 220 oder so etwas schwankend liegt. Ob das wirklich so ist ...?

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1

  • Zitat

    Original von tom66
    Ich habe nur derzeit ein sehr schlimmes Zeitproblem.


    Ich hatte mich auch nicht auf Dich bezogen, das "Argument" mit "Schwierig weil VBR", kam ja wiederholt von anderen Leiten, angeblich sogar mal von Klaus selber.


    Zitat


    Aber ich glaube auch nicht so recht, dass es an VBR liegt. Hatte ich ja schon weiter oben gesagt. Aber wenn du femon aufrufst, siehst du, dass die Bitrate beistens nicht bei 192, sondern bei 220 oder so etwas schwankend liegt. Ob das wirklich so ist ...?


    Ja, aber komischerweise sind alle meine Audio-Aufnahmen spätestens nach einem VDRSYNC-Lauf 100% CBR. Die Schwankungen müssen sich auf etwas anderes beziehen, die reinen Nutzdaten sind auf jeden Fall CBR, die Bitrate müsste daher auch ohne demultiplexen leicht rauszubekommen sein.

  • Zitat

    Original von Demnos
    Ja, aber komischerweise sind alle meine Audio-Aufnahmen spätestens nach einem VDRSYNC-Lauf 100% CBR. Die Schwankungen müssen sich auf etwas anderes beziehen, die reinen Nutzdaten sind auf jeden Fall CBR, die Bitrate müsste daher auch ohne demultiplexen leicht rauszubekommen sein.


    Und VDRSYNC ist kein Demuxer ? 8o


    Selbst bei CBR muss die Bitrate erstmal aus dem demuxten MP2 Stream extrahiert werden,
    das die Aufnahme kein blanker MP2 Stream ist, sondern ein PES-STREAM der noch zusätzlichen Payload enthält bzw. enthalten kann.
    Um an die Audiospur zu kommen muss aus dem PES STREAM erstmal der ES-Stream extrahiert werden. Siehe auch hier


    Und nur das erste Packet zu berücksichtigen ist auch keine saubere Lösung, den trotzdem könnte bei CBR z.B. die Bitrate beim Sendungswechsel geändert werden, und sowas muss preventiv auch berücksichtigt werden...
    Von zweisprachrigen Radiosendern (sofern es sie gibt) will ich gar nicht erst anfangen :)


    Außerdem nutzt keine Lösung die nur bei einzelen Sendern funktioniert, eine generelle Lösung des Problem ist bei weitem sinnvoller... (auch wenn eine simple Lösung erstmal ein ausbaufähiger Anfang wäre) ;)

  • Könnte mir bitte jemand mal erklären, warum es bei Videoaufnahmen, wo wirklich VBR vorkommt (nicht nur als PES, sondern auch bei den darin enthaltenen ES Nutzdaten) wunderbar funktioniert, ohne das man voher demuxen muss, und bei reinen Audio-Sendern nicht?


    Schreibt der VDR nicht genau zu diesem Zweck eine index.vdr Datei mit? Falls ja, warum kann diese dann nicht auch bei reinen Audiosendern gleich beim Aufzeichenn korrekt gefüllt werden?


    Ok, ich antworte mir mal selber: Ich vermute, es hängt damit zusammen, dass bei Videostreams vom VDR die I-Frames mitgeschrieben werden, und die gibt es bei Audio nicht. Liegt es daran? Kann man nicht bei Radiosendungen statt der I-Frames etwas anderes gleich bei der Aufzeichnung mit in die index.vdr schreiben, was den i-Frames entspricht?


    Im übrigen Zeigt FEMON mir bei *allen* Radiosendern die ich gestern mal durchgezappt habe zwar eine VBR bei PES, aber auf der zweiten Seite von Femon wird bei ES immer eine CBR angegeben. Ich behaupte also mal ganz frech, dass es überhauot keine VBR Radiosender gibt! Ich habe nicht mal einen Fernsehsender mit Audio-VBR gefunden...

  • VDR speichert doch Anfangs- und Endzeit der Aufnahme. Daraus könnte man doch leicht die Dauer berechnen. Wie man das proggen könnte weiß ich aber nicht :(



    EDIT: Ich habe jetzt gerade mal ne VDR-Radio-Aufnahme auf den Win-Rechner gezogen und dort mit Media Player Classic abgespielt und siehe da: die korrekte Länge wird angezeigt!

    MLD 5.5 mit VDR 2.6.4 & Kodi 19.4 - Gigabyte GA-F2A88XM-HD3 - AMD A8-7600 - 4 Gb RAM - Ausgabe via MSI N220GT-MD1GZ mit softhddevice & vdpau - 19.2E & 28.2E Empfang via Linux4Media L4M-Twin S2 ver 6.5 - Terratec Aureon 5.1 Fun TTP8 - Crucial m4 CT064M4SSD2 - Seagate Exos 7E8 in Scythe Quiet Drive SQD-1000 - Medion X10 RF Remote Control 20016398

    Einmal editiert, zuletzt von villeneuve ()

  • Zitat

    Original von Demnos
    Ok, ich antworte mir mal selber: Ich vermute, es hängt damit zusammen, dass bei Videostreams vom VDR die I-Frames mitgeschrieben werden, und die gibt es bei Audio nicht. Liegt es daran? Kann man nicht bei Radiosendungen statt der I-Frames etwas anderes gleich bei der Aufzeichnung mit in die index.vdr schreiben, was den i-Frames entspricht?


    Genau so ist es, ohne I-Frame/index.vdr kann der VDR keine Abspiellänge ermitteln.


    Der VDR rechnet Abspiellänge wie folgt :


    Speicherposition in index.vdr / 8 bytes / 25frames => Länge in Sekunden


    Beim Spulen wird einfach das Speicherpostion um 60 Sekunden * 25 * 8 Bytes erweitert und aus index.vdr ausgelesen und darum funktioniert bei Radioaufnahmen auch der Schnelle Vor-und Rücklauf nur suboptimal...


    BTW : Was hindert Dich eine CBR Lösung für den Anfang zu implementieren :D
    (Spass muss sein, immer locker bleiben)


    Zitat

    Original von villeneuve
    VDR speichert doch Anfangs- und Endzeit der Aufnahme. Daraus könnte man doch leicht die Dauer berechnen.


    Der VDR speichert nur die Anfangszeit als Verzeichnisname der Aufnahme und spätestens nach dem ersten Schnitt ist sie nicht mehr korrekte, wenn am Anfang Szenen gelöscht werden.


    Andreas

  • Zitat

    Original von villeneuve
    VDR speichert doch Anfangs- und Endzeit der Aufnahme. Daraus könnte man doch leicht die Dauer berechnen.


    Der VDR speichert nur die Anfangszeit als Verzeichnisname der Aufnahme und spätestens nach dem ersten Schnitt ist sie nicht mehr korrekte, wenn am Anfang Szenen gelöscht werden.


    Andreas[/quote]


    Ach stimmt.
    Aber wie läßt es sich erklären, daß Media Player Classic die richtige Länge anzeigt?

    MLD 5.5 mit VDR 2.6.4 & Kodi 19.4 - Gigabyte GA-F2A88XM-HD3 - AMD A8-7600 - 4 Gb RAM - Ausgabe via MSI N220GT-MD1GZ mit softhddevice & vdpau - 19.2E & 28.2E Empfang via Linux4Media L4M-Twin S2 ver 6.5 - Terratec Aureon 5.1 Fun TTP8 - Crucial m4 CT064M4SSD2 - Seagate Exos 7E8 in Scythe Quiet Drive SQD-1000 - Medion X10 RF Remote Control 20016398

  • Hi,


    Um die Bitrate zu berechnen, würde ich einfach bei ein paar Pakete (zufällig über die gesamte Aufnahme verteilt) die Bitrate auslesen. Wenn diese immer gleich ist dies als CBR werten. Bei VBR einfach mehr Datenpakete kontrollieren, bis die gewünschte Genauigkeit erreicht ist.



    Müsste dann halt im VDR noch implementiert werden, dass er die Radioaufnahme anders berechnen muss.


    Beim Spulen weiss ich nicht wie das der VDR handhabt.



    MfG
    Karsten

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!