Verlustarme Kompression für HDTV?

ich rippe öfters Aufnahmen und packe das ganze in einen MKV Container, dazu verwende ich Handbrake. Finde die Qualität eigentlich auch noch nach dem rippen super!

mfg
aelo

ich vermute mal, wenn Du die Null-Byte Auffüllung des Streams mal abstreifst, dann sollte das File schon recht schlank werden auch ohne Kompression.

Gruß Fr@nk

Zitat

Original von SvenGWK
Was ist mit Null-Byte Auffüllung gemeint?

Ich unterstelle mal, das Du Filme mit CBR dabei hast.

Schaue auch mal hier --> http://forum.digitalfernsehen.…der-hohen-hd-bitrate.html

Gruß Fr@nk

Zitat

Original von lola
ich vermute mal, wenn Du die Null-Byte Auffüllung des Streams mal abstreifst,

Wäre diese Funktion nicht ein idealer Bestandteil der integrierten Schnittfunktion des vdr?

> Wäre diese Funktion nicht ein idealer Bestandteil der integrierten Schnittfunktion des
> vdr?

für sowas hat kls eigentlich die möglichkeit für plugins geschaffen
vdr will ja vom ansatz her nicht alle probleme der welt lösen sonder nur das zeug vom tuner auf die platte klatschen (und noch das eine oder andere)

Es soll beim schneiden nicht in ein anderes Format gewandelt werden, sondern nur die unnützen Informationen weggelassen werden. Das macht die Schnittfunktion so auch mit den Werbepausen. Eine neue Indexdatei muss beim Schnitt sowieso erstellt werden.

das bewegt sich imho aber auf einer ganz anderen schicht, das schneiden verwirft nur ein paar packete, für das andere muss man vermutlich wesentlich tiefer in h.264 rein

kann man nicht ein programm/plugin/patch bauen, das den Eingangsstream filtert und die nullen entfernt? ist doch kein recoden somit doch nur ein cleanup?

Zitat

Original von IG88
> Wäre diese Funktion nicht ein idealer Bestandteil der integrierten Schnittfunktion des
> vdr?

für sowas hat kls eigentlich die möglichkeit für plugins geschaffen
vdr will ja vom ansatz her nicht alle probleme der welt lösen sonder nur das zeug vom tuner oaf die platte klatschen (und noch das eine oder andere)

ging es Klaus nicht eher darum dass der VDR nur die Funktionen enthält die auch wirklich alle benötigen und die speziellen Funktionen die nicht jeder benötigt durch Plugins nachgerüstet werden?
99,9% würden sich wahrscheinlich über dieses Feature freuen, denn Speicherplatz ist zwar billig aber noch nicht geschenkt

gibt es irgendwo vielliecht eine Doku wie das etwa funktionieren würde? (Also ein Algorithmus oder so etwas?)

mfg
aelo

worauf ich hinaus will ist das falls jemand anfängt das zu coden sollte er entweder mit kls vorher über einen patch reden (wie der aussehen sollte damit er eine chance hat in vdr einzufließen) oder es gleich als plugin konzipieren

ps: den überflüssigen mist gleich vor der aufzeichnung auf die platte zu verwerfen ist eine gute idee

Zitat

Original von IG88
ps: den überflüssigen mist gleich vor der aufzeichnung auf die platte zu verwerfen ist eine gute idee

Prinzipiell ja, aber das widerspricht der Philosophie dass der vdr bei den Grundfunktionen (Live-TV, aufnehmen oder eigene Aufnahmen wiedergeben) so wenig Ressourcen wie möglich verbraucht um auch reichlich alte Systeme nicht zu überfordern. Deshalb wird auch der TS (bisher leicht abgewandelt als PES) fast direkt auf die Platte geschrieben. Bei heutigen Systemen wäre eine weitergehende Konvertierung während der Aufnahme kein technisches Problem.

Die zusätzlichen Bits sind wohl der Übertragung geschuldet: H.264/AVC besitzt zwei Layer so wie ich mir das angelesen habe: den Video Coding Layer (VCL) und den Network Abstraction Layer (NAL). NAL packt die VCL-Pakete ein, um eine Übertragung über Netzwerke wie z.B. DVB-S2 zu ermöglichen. Wenn nicht genug VCL-Pakete da sind, dann kann der Satellit ja nicht einfach aufhören zu senden, sondern dann werden eben NAL-Pakete vom Typ 12 (=Filler Data) gesendet.
Das "Problem" des VDR ist nun, dass er ja unabhängig von der Codierung (MPEG2/H.264) sein soll und deshalb im TS-Format aufzeichnet. Wären die Füllbytes in einer eigenen TS-PID verpackt, dann könnte man die ganz einfach ignorieren so wie man z.B. AC-3-Tonspuren ignorieren konnte. Da sie aber offenbar im H.264 Datenstrom enthalten sind müsste man doch wieder den Stream analysieren und die NAL-12 Pakete verwerfen.

FireFly
halbfertiger

ist genau das was ich weiter oben schon geschrieben habe, ursprünglicher ansatz ist daten nehmen und auf die platte klatschen und die filler bewegen sich auf einer anderen (tieferen) schicht innerhalb von h.264 und vdr betrachtet den inhalt der packet so wenig wie möglich

aber man kann das noch eins drauf setzen, als patch und dazu noch eine setup option, diese beiden dinge waren bei kls immer sehr beliebt ("könnte man das nicht konfigurierbar machen ...")

also am besten einen schritt zurücktreten und ansehen wo die idee am besten unterzubringen ist und mal auf der vdr ML diskutieren
ein offline kommandozeilen tool das eine ts aufnahme "wandelt" gibts vieleicht schon und falls es nachher probleme mit dem index gibt könnte man den einfach löschen und vdr erzeugt beim nächsten replay einen neuen - das könnte man evtl. alles testen ohne eine zeile code zu schreiben

z.b. hat das markad plugin auch so seine probleme mit dem echtzeit werbung erkennen so das für die entwicklung erst mal auf offline gewechselt wurde (da ist mein stand aber schon ein paar wochen alt) - die idee bei mardad ist gut, man vermeidet es die daten mehrfach anzufassen (nachträglicher lauf über die aufnahme)

Moin,

zum Thema Null Bytes entfernen hatte die c't neulich was gebracht. Da ging es um Windows Tools wie tsMuxeR und TS-Doctor. Leider laufen beide nicht mit Wine unter Linux.

Gruß, ollo

Zitat

Original von ollo
Moin,

zum Thema Null Bytes entfernen hatte die c't neulich was gebracht. Da ging es um Windows Tools wie tsMuxeR und TS-Doctor. Leider laufen beide nicht mit Wine unter Linux.

Gruß, ollo

Stimmt nicht ganz , tsMuxeR läuft ( als vorkompiliertes bin ) auch nativ unter Linux, siehe hier :

http://www.smlabs.net/tsmuxer_en.html

und

http://www.vdrportal.de/board/…?postid=879128#post879128

Grüße vom Alex

Die Diskussion zum Nullbyte-Entfernen (CBR nach VBR) gabs auch schon hier im Forum im Zusammenhang mit Metropolis. Interessant ist, daß Tools zum Einsatz kommen (TsMuxeR, MKVToolnix), die beide unter Linux laufen sollen. Durch das Rausschmeissen der Nullbytes lässt sich so ca. 50% an Platz sparen, also die Dateigröße auf ca. die Hälfte ohne Kompressionsverluste reduzieren.

Hier der Link: [T] metropolis auf arte, 12.02.2010

BJ1

Zitat

Original von BJ1
Hier der Link: [T] metropolis auf arte, 12.02.2010

Unter diesem Titel hätte ich bestimmt nicht danachgesucht

Wer sich mal an die Programmierung wagen möchte: im femon-Plugin wird der H.264-Stream schon analysiert (u.a. um die Bitrate zu bestimmen), da kann man sich wertvolle Tips holen, evtl. sogar schon inkl. Einbindung in den VDR.

Die Chancen für die Integrierung eines Null-Byte Filters direkt in VDR schätze ich eher gering ein. Dass der PES-Repacker in VDR bis 1.6 zunehmend komplexer und ressourcenfressender geworden ist, war immerhin die Hauptmotivation, warum der PES-Repacker in 1.7 wieder raus flog, und statt dessen TS-Aufzeichnungen eingeführt wurden. Da wird Klaus bestimmt nicht wieder einen tiefen Stream-Repacker einführen wollen - es sei denn, er ist wirklich extrem einfach zu realisieren.

Gruß,

Udo