Jump to content
Sign in to follow this  
Lupissimo

HDTV ts lässt sich nicht encoden

Recommended Posts

Lupissimo

Mit dem Recording Service nehme ich die HDTV TS von ARD/ZDF/Arte auf. Wenn ich diese direkt in meine Encoder GUI ( Staxrip) eingebe, um sie mit x264 als mkv-datei zu encoden, stürzt der Encode-Prozess x264.exe nach einer Weile ab, wobei sich der Speicherbedarf des x264 Prozesses kontinuierlich bis über 2GB erhöht (Memory Leak). Wenn ich den gleichen File vorher durch tsMuxeR laufen lasse (ts=>ts), lässt er sich einwandfrei encoden und der RAM Bedarf bleibt stabil bei 600MB. Beim tsMuxeR kommt eine Meldung: "H.264 stream does not contain fps field. Muxing fps=50". Da ich nicht weiß, was bei dem von DVBViewer aufgenommenen ts-file bei der Konversion durch tsMuxeR verändert wird, hoffe ich hier auf Tips. Könnte es sein, dass beim Schreiben durch den Recording Service bei HDTV Signalen das file Format nicht der Norm entspricht?? Alle SD ts-files lasssen sich einwandfrei verarbeiten.

 

Lupissimo

Share this post


Link to post
Mandrax

Die Nachricht ""H.264 stream does not contain fps field. Muxing fps=50"", kommt bei mir immer (ARD-ZDF-arte) auch bei Aufnahmen die lt. DVDViewer log, tsplayer, TSDoctor und tspacket-editor fehlerfrei sind.

Staxrip kenne ich nicht, mir ist nicht klar was Du mit "encoden" meinst, glaube dass Du nur das Containerformat wechseln willst ts --> mkv?

Hierzu wird ffmpeg häufig benutzt, hat aber den Nachteil, dass man die "Nalu Filler" mitschleppt. Versuche mit tsMuxeR zu demuxen und mit mkvmerge in mkv umzuwandeln (hier muss man fps=50 wieder eingeben). Bei diesem Schritt wirst Du die "Nalu Filler" los und kannst bei Bedarf Kapitelmarken setzen. Alternative wäre TSDoctor zur Entfernung der Filler und anschließende Umwandlung in mkv (hat bei mir manchmal Asynchronitäten mit AC3 erzeugt)

Edited by Mandrax

Share this post


Link to post
Lupissimo

Danke für die Hinweise. Mit "Encoden" meine ich nicht nur den Container wechseln, sondern auch mit x264.exe und entsprechenden Profilen das Video neu komprimieren, bringt praktisch ohne Qualitätsverlust den Faktor 3...4 an Datenreduzierung, da man ja auf jegliche Redundanz wegen des Übertragungswegs verzichten kann. Also 12GB auf ca 3.5GB.

Staxrip ist eine GUI, die zahlreiche freie Programme benutzt um sehr flexibel neu zu encoden ( xvid,x264, etc.)und container Formate (mkv,avi, etc)zu erzeugen und den output für verschiedene Zielgeräte ( Ipod,Iphone,PS3,XBox, etc) anzupassen. Da ich nicht sicher bin, ob ich links hier posten darf: Nach Staxrip googlen.

Share this post


Link to post
Derrick
bringt praktisch ohne Qualitätsverlust den Faktor 3...4

..ich würde auf SD umsteigen :lol:

Share this post


Link to post
Lupissimo

@Derrick: Es hat den Anschein, dass Dir die Zusammenhänge bei verlustbehafteten Übertragungswegen nicht ganz klar sind.

Share this post


Link to post
Derrick

..also wenn der übertragungsweg verlustbehaftet ist (das ist er laut informationstheorie immer), muss redundanz hinzugefügt werden, um am ende die gewünschte information fehlerfrei empfangen zu können. Ich glaube kaum, dass du das meintest ;)

 

Hier geht es um eine verlustbehaftete HD-kodierung, die mit dem H.264-algorithmus besonders effektiv ist. Wer das bis zur unkenntlichkeit weiter eindampft und meint keinen qualitätsverlust erkennen zu können, hat anscheinend tomaten auf den augen B)

 

Wem das aber trotzdem reicht, kann imho gleich in SD aufnehmen und viel zeit und energie sparen :bye:

 

ps.

aufpolsterung mit redundanten fülldaten wurde zwar schon vorher erwähnt, aber um missverständnisse auszuschliessen hier nochmal ;)

Share this post


Link to post
Lupissimo

Volltreffer: Natürlich ist eine drahtlose Satellitenübertragung verlustbehafteter als ein Draht von der Festplatte und darum führt ein Neu-Encoden, das nicht auf die Redundanz Rücksicht nehmen muss, zu weniger Daten.

 

Anstelle eines überheblichen Kommentars vom Moderator hätte ich lieber Hinweise zur Problemlösung.

Anscheinend muss ich meine Frage in einem anderen Forumteil posten, das sich mit der Datenstruktur der vom Recording-Service gespeicherten ts auskennt.

Share this post


Link to post
Tjod

Also die Redundanten Daten liegen wenn in höheren schichten. Wenn es im ts Datenstrom Fehler gibt kannst du die im DVBSource Filtere sehen und auch als Störung im Bild. Von den Video Daten darf für eine störungsfreie Übertragung nichts verloren gehen.

 

Und die Null Pakete die zum auffüllen der Transponder genutzt werden landen sicher nicht in der Aufnahme.

 

Das einzige was man da Verlustarm bei Dateien anders machen könnte ist die die Anzahl der Keyframe teile herunter setzen. Was nur das Spulen etwas verlangsamt. Aber all zu viel Datenreduktion wird man da auch nicht raus holen.

 

Nur bei aufnahmen von Live Übertragungen gibt es noch wirkliche Reduktion Potential.

 

Was da in den TS Dateien geändert wird weiß ich nicht. Das kann höchstens jemand wie Derrick beantworten der so was auch hin und wieder mit den Hexeditor auseinander pflückt.

Share this post


Link to post
Lupissimo

@Tjod: Danke für die sachliche Antwort. Es geht bei meiner Frage NICHT um Datenredundanz, - und ich möchte hier auch gar keine Diskussion über den Sinn oder Unsinn von Neuencoden anzetteln -. Mein Problem ist, dass das nachverarbeitende Programm beim Encoden des original vom Recording Service gelieferten ts-files abstürzt. Wenn ich das File vorher durch tsMuxeR laufen lasse (ts=>ts) wird anscheinend die Datenstruktur so geändert, dass kein Absturz später passiert und ich versuche herauszufinden, was da geändert wird. Und da wären Hinweise auf die vom DVBViewer gelieferte Datenstruktur bei HD hilfreich. Mit einem Hexeditor zu vergleichen ist sicher ein Schritt, aber ohne die Struktur zu kennen mühsam.

Share this post


Link to post
Mandrax

Und die Null Pakete die zum auffüllen der Transponder genutzt werden landen sicher nicht in der Aufnahme.

Genau dies tun sie, ansonsten würde z.B. TSDoctor keine Funktion zu deren Entfernung haben

Share this post


Link to post
Tjod

Du könntest dir die Dateien mal mit dem TransEdit Analyzer ansehen. Eventuell findest du da einen unterschied.

http://www.DVBViewer.com/griga/TransEdit%20D/MainWindow.html#Scan

http://www.DVBViewer.com/griga/TransEdit%20D/AnalyzerWindow.html#Title

 

du könntest auch gucken on eine TS > TS Konvertierung mit dem TSPlayer den gleichen Effekt hat:

http://www.DVBViewer.com/griga/TSPlayer_Manual_D/Conversion.html#MPG

Share this post


Link to post
Tjod
Genau dies tun sie, ansonsten würde z.B. TSDoctor keine Funktion zu deren Entfernung haben
Bei Aufnehmen vom DVBViewer oder Recording Service sind Null Pakete enthalten?

Welche Einstellungen verwendest du für die Aufnahme?

Share this post


Link to post
Lupissimo

Prima, Danke für die Tips!

Share this post


Link to post
Mandrax

Bei Aufnehmen vom DVBViewer oder Recording Service sind Null Pakete enthalten?

Welche Einstellungen verwendest du für die Aufnahme?

Aufnahme mit DVBViewer, Format ts, ohne Teletext.

Kürzliche Datenreduktion lt. TSDoctor 21,7 % bzw. 31,4% filler, einhergehend mit entsprechender Absenkung der Bitraten

Edited by Mandrax

Share this post


Link to post
Derrick

Volltreffer: Natürlich ist eine drahtlose Satellitenübertragung verlustbehafteter als ein Draht von der Festplatte und darum führt ein Neu-Encoden, das nicht auf die Redundanz Rücksicht nehmen muss, zu weniger Daten.

Blödsinn! Kanalkodierung für die übertragung und komprimierung des inhalts (hier verlustbehaftet) sind 2 verschiedene paar schuhe.

 

 

Also die Redundanten Daten liegen wenn in höheren schichten. Wenn es im ts Datenstrom Fehler gibt kannst du die im DVBSource Filtere sehen und auch als Störung im Bild. Von den Video Daten darf für eine störungsfreie Übertragung nichts verloren gehen.

..erfordert zumindest eine korrektur ;) Notwendige redundanz zur fehlerfreien übertragung findet man im untersten layer (physical) vom OSI modell.

 

 

Genau dies tun sie, ansonsten würde z.B. TSDoctor keine Funktion zu deren Entfernung haben

..auch falsch. Nullpakete sind nicht im videostream sondern werden mit einem eigenen pid übertragen, um die muxrate konstat zu halten. Sie werden vom DVBViewer zumindest nicht mit aufgenommen. Der tsdoctor entfernt fülldaten (NALUs), die im stream übertragen werden. Auch sie dienen letztendlich wie die nullpakete für eine konstante rate aber des videostroms und nicht des gesamten muxes.

 

 

Nochmals, videoenkodierung und übertragungsverfahren sind verschiedene dinge. Und für probleme beim reenkodieren gibt es viele spezialforen, wenn es hier keine befriedigende antwort gibt :bye:

Share this post


Link to post
Mandrax

..auch falsch. Nullpakete sind nicht im videostream sondern werden mit einem eigenen pid übertragen, um die muxrate konstat zu halten. Sie werden vom DVBViewer zumindest nicht mit aufgenommen. Der tsdoctor entfernt fülldaten (NALUs), die im stream übertragen werden. Auch sie dienen letztendlich wie die nullpakete für eine konstante rate aber des videostroms und nicht des gesamten muxes.

Danke, endlich hat es mir mal jemand nachvollziehbar erklärt

Share this post


Link to post
Lupissimo

@derrick: Vielleicht solltest du deine oberlehrerhafte Atitüde als Moderator ( kommt aus dem Lateinischen und bedeutet Besänftiger) mal überdenken.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...