Videospur nur bei DVBC zu langsam: Sundtek MediaTV Digital Home

[kalexm]

Moin,

ich habe seit 2 Wochen den Sundtek MediaTV Digital Home Stick. Der hängt an einem ALIX Board und soll nur als Viderekorder genutzt werden. Die Installation war schnell und einfach gemacht. Meine bisherigen Tests mit DVB-T haben auch einwandfrei funktioniert. Bei DVB-C habe ich aber ein merkwürdiges Phänomen: Das Videobild läuft mehrfach langsamer als die Audiospur. Mein Aufbau:

USB-Stick am ALIX Board, als VideoArchiv eine externe USB Festplatte.
Voyage Linux (ein Debian Derivat).

Für DVB-C und DVB-T:
1. Scan mit w_scan für Initial Tuning Date
2. Dann scan
3. tzap bzw. czap mit der entstandenen Scan-Datei
4. cat dvr0 > /meinOrdner/meineAufnahme.ts
5. Betrachten mit mplayer oder vlc

Bei DVB-T ist alles einwandfrei. Auch wenn ich dvbstream benutze um den Programstream zu extrahieren klappt alles. Bei DVB-C weigert sich dvbstream. Der Transportstream wird mit der extrem langsamen Videospur angelegt, wird aber Wiedergegeben. Der Effekt ist, dass es aussieht wie Zeitlupe, die Tonspur wird normal wiedergegeben, endet aber nach ca. 1/3 - Das Video läuft entsprechend nach.

Was kann das sein?

[Sundtek]

Handelt es sich um HDTV Aufzeichnungen?

Wenn ja dann wird hierfür unbedingt eine NVidia Graphikkarte mit Vdpau benötigt. Der Stick macht bei Audio/Videospuren keinen Unterschied, die Daten werden komprimiert an den PC geschickt.

[kalexm]

Ja, ist eine HDTV Aufnahme.

Leider verstehe ich die Antwort nicht... Ich möchte auf dem Rechner, an dem die Sundtek DVB-C Karte hängt eine Video-Datei erzeugen, die ich auf einem anderen Rechner/Mobiltelefon/PS3/DLNA-Client wiedergeben möchte. Ich hatte die Doku so verstanden, das der Stream, der aus dem Device Strömt ein Transport-Stream ist und z.B. mit dem mplayer wiedergegeben werden kann (oder mit ffmpeg oder HandbrakeCLI konvertiert werden kann für die Nutzung auf anderen Geräten ohne weitere Anforderungen an die Hardware ausser genug Dampf um H264 zu dekodieren).

[Sundtek]

Genau so wie Sie es verstanden haben funktioniert es auch! Es liegt also ein Codecproblem vor.

HDTV (meißt h264 Ströme) sind unkomprimiert sehr große Datenmengen.
Bei der Wiedergabe bitte auf die CPU Auslastung achten (sofern diese höher als 50% ist gibt es bei h264 HDTV sehr warscheinlich bereits Probleme, die Videodatei sollte in dem Fall mittels VDPAU über die Graphikkarte dekodiert werden um eine flüssige Wiedergabe zu garantieren). Die Graphikkarte kann dabei auch noch recht einfach gutes Deinterlacing in Hardware erledigen was in Software aufgrund der limitierten CPU Resourcen dann schon schwieriger wird. 

Extrem langsames Video => das Video kann ggf. nicht schnell genug vom CPU dekodiert werden.

Sollte es dann dennoch Probleme mit einem asynchronen Video geben dann liegt eindeutig ein Bug im jeweiligen Player vor. Welche Linux Distribution liegt den vor und welche Version?

[kalexm]

OK: Mein Notebook war zu schwach auf der Brust! Interessanterweise schafft es aber mein Dual Core Android Handy!!!

Jetzt habe ich aber doch noch eine Frage:

Nehme ich einen HD Transport Stream auf (durch cat auf das dvr device nach tuning mit czap) (in diesem Fall arte 720p) und ich analysier diesen mit der Option tsscan, sind darin drei Ströme enthalten: arte HD, ARD HD und ZDF HD. Insgesamt ca. 12MBit. Da ich aber z.B. nur die arte Aufnahme archivieren möchte (auch aus Platzgründen), brauche ich einen program stream. dvbstream weigert sich bei HD aber entsprechend zu filtern. Mit welchen Tools kann ich schlank (immer noch ein kleiner 500MHZ geode und am besten in Echtzeit) demuxen und wieder muxen, alternativ zu dvbstream?

Danke

[Sundtek]

Einige Systeme können 720p/h264 mittels Hardware dekodieren (z.B NVidia mit VDPAU, oder auch einige Systeme welche die VAAPI unterstützen). VDPAU ist zur Zeit jedoch am gängigsten.

dvbstream -o pid1 pid2 > /tmp/test.ts

sollte nur die jeweiligen PIDs aufnehmen.