Daten demuxed kleiner als TS-Datei

Wenn du einen "echten" Transport Stream aufgenommen hast, müsste da der gesamte Transponder - also mehrere Sender auf einmal - drin sein. Wobei dann der Unterschied allerdings theoretisch noch größer ausfallen müsste.
Welchen Sender auf welchem Transponder / Satelliten hast du denn gestreamt?

Zitat von Exy

Kleine Nebenfrage, gibts ne Möglichkeit um rauszufinden ob die Qualität nach dem demuxen gelitten hat oder kann das nich sein das es da nen Verlust gibt?

Die Qualität an sich (Bildgröße, Kompression etc.) ändert sich beim Demuxen nicht, da quasi einfach Teile eines Gesamt-Streams "herauskopiert" werden. Es kann allerdings passieren, dass während der Übertragung (z.B. durch schlechtes Wetter und/oder schlecht ausgerichtete Schüssel) Fehler im Stream entstanden sind, die sich durch Audio-/Video-Aussetzer, bunte Klötzchen, Verlust der Audio-/Video-Synchronisation etc. bemerkbar machen - die tauchen allerdings auch schon vorm Demuxen auf. Solche Stellen werden z.B. beim Demuxen mit ProjectX entfernt und der Rest des Streams wieder angeglichen - fehlerhafte Stellen landen dann im Log.

kurz:

Zitat

Was könnte da den noch mitaufgenommen werden das dann so viel ausmacht?

Nichts. Der Overhead von .m2ts/.ts Streams ist bei kleinen (< 4GB) Filegrößen !richtig! mies, d.h. 400% ist durchaus möglich.

lang:
Hier mal ein paar Dinge dazu die mir aufgefallen sind, als ich eine Formale für sx264 erstellt habe um den Overhead des .m2ts Containers abzuschätzen:
1. der Overhead kann bei kleinen Dateien durchaus bis zum 4fachen des Inhalts sein. Ja, d.h. wenn man z.B. 10MB multiplexen will kann es ein, dass man mit 50MB Dateiinhalt am Ende konfrontiert wird.
2. der Overhead ist erst so ab 4+ GB erträglich.
3. der Overhead hängt ab von der Art, Länge und der Datenratenschwankung der Streams
4. ich kriege es nicht hin den Overhead richtig abzuschätzen
hier mal die die Formel die ich in sx264 verwende:

//es wird davon ausgegangen, dass :// - die Audio- und Videolänge gleich ist// - nur ein Audio- und ein Videostream verwendet wird// - es wird eher aufgerundet damit die Zielgröße die der User angibt nie überschritten wird//Länge des Videostreamsdouble length = numberOfFrames/framerate; //Initialisierungqint64 audiosize = 0 , audioOverhead = 0;int audiobitrate = 0;// Falls ein Audiostream verwendet wird -> Audiooverheadberechnungif(audioHandling){    //ermittelt das Audioformat des Inputstreams    QString audioformat = this->getAudioInputFormat();    //Initialisierung; die mittlere Blockgröße des Audiostreams    int blocksize = 0;    //falls der Stream nicht reencoded wird    passThroughAudio = passThroughAudio || !this->findChild<nvalue *="">("audioTemp")->value().isEmpty();    if(passThroughAudio){         //Größe des Audiostreams        audiosize = this->audioSizeByte();        //erwartete durchschnittliche Zieldatenrate        audiobitrate = this->calc->byteSizeTokBitRate(audiosize, numberOfFrames/framerate);    }     /falls der Stream reencoded wird    else {        //ermittelt das Format des Outputaudiostreams        audioformat = this->getAudioOutputFormat();        //ermittelt die durchschnittliche Datenrate des Audiostreams        audiobitrate = this->findChild<nrangevalue *="">("audio_target_bitrate")->intValue();        //ermittelt die erwartete Zielgröße des Audiostreams        audiosize = this->calc->kBitRateToByteSize(audiobitrate, length);    }    // setzt je nach Format eine andere durchschnittliche Blockgröße    if(audioformat == "ac3" || audioformat == "dts" || audioformat == "pcm"){        blocksize = 907;    } else {        blocksize = 80;    }    //Berechnung des Audiooverheads    audioOverhead = qint64((blocksize+17)/180.0 * 8.0  + 17.0 +0.5)* qint64((audiosize*1.0)/(blocksize*1.0)+0.5);}//Berechnung der erwarteten RaWgröße des Videostreamsqint64 rawvideosize = this->calc->kBitRateToByteSize(videoBitrate, length);//Berechnung des Videooverheadsqint64 videoOverhead = (rawvideosize/183 + 1)*9;//Berechnung eines allgemeinen Overheadsqint64 generalOverhead = numberOfFrames*(262+(audiobitrate/184+1)) + 9412;//Berechnung der Zielgröße des multiplexten OutputsbyteSize = audiosize + audioOverhead + rawvideosize+ videoOverhead + generalOverhead;

(Falls jemand Verbesserungen für die Formel hat, immer her damit.:))

Schlußfolgerung:

Zitat

Was könnte da den noch mitaufgenommen werden das dann so viel ausmacht?

Nichts. Der Overhead von .m2ts/.ts Streams ist bei kleinen (< 4GB) Filegrößen !richtig! mies, d.h. 400% ist durchaus möglich.

Cu Selur

Ps.: Hier mal die Ergebnisse einiger Multiplex versuche:

m2ts - videoOnly


FrameCount: 429
178.176 Bytes inside container
  60.355 Bytes raw
117.821 Bytes overhead
(raw/184) * 8  (aufrunden) = 2625
+ (framecount*262) = 112398
+ 9412 (Startoverhead)
124.435 Bytes calculated
117.821 overhead










Framecount: 109645
109645/23,976 = 4573,1147814481147814481147814481


quant 51
37.502.976 Bytes inside container
  8.472.672 Bytes raw
29.030.304 Bytes overhead
(raw/184) * 8  (aufrunden) = 368378
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
29.104.780 Bytes calculated
29.030.304 Bytes overhead


200
143.388.672 Bytes    inside container
111.974.627 Bytes raw
  31.414.045 Bytes overhead
(raw/184) * 8  (aufrunden) = 4868463
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
33.604.865 Bytes calculated
31.414.045 Bytes overhead






300
200.534.016 Bytes    inside container
166.799.049 Bytes raw
  33.734.967 Bytes overhead
(raw/184) * 8  (aufrunden) = 7252133
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
35.988.535 Bytes calculated
33.734.967 Bytes overhead




400
257.857.536 Bytes    inside container
221.618.987 Bytes raw
  36.238.549 Bytes overhead
(raw/184) * 8  (aufrunden) = 9635609
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
38.372.011 Bytes calculated
36.238.549 Bytes overhead




500
315.033.600 Bytes    inside container
276.435.819 Bytes raw
  38.597.781 Bytes overhead
(raw/184) * 8  (aufrunden) = 12018949
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
40.755.351 Bytes calculated
38.597.781 Bytes overhead


1000
601.055.232 Bytes    inside container
550.501.276 Bytes raw
  50.553.956 Bytes overhead
(raw/184) * 8  (aufrunden) = 23934839
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
52.671.241 Bytes calculated
50.553.956 Bytes overhead


2000
1.173.006.336 Bytes inside container
1.098.623.746 Bytes raw
    74.382.590 Bytes overhead
(raw/184) * 8  (aufrunden) = 47766250
+ (framecount*262) = 28726990
+ 9412 (Startoverhead)
76.502.652 calculated
74.382.590 Bytes overhead

</nrangevalue></nvalue>

Wow - so mächtig viel Overhead hätte ich jetzt nicht erwartet :eek:

Zitat von Exy

Was unterscheidet einen "echten" Transportstream von einem 'unechten'?

"Echt" und "unecht" im Sinne von: "Kompletter Transponder (n Audio- und Videostreams / Sender)" und "ein Sender (ein oder zwei Audiostreams und ein Videostream)".
Deshalb auch "echt" in Anführungszeichen

Zitat von Exy

Wenn man Daten die man demuxed hat mit einem Muxer wieder zu einer MPG Datei zusammenfügt, kann dabei ein Verlust von Qulität auftreten oder geht das auch Verlustfrei?

Wie schon gesagt - Multiplexing und Demultiplexing ist prinzipiell nur "zusammen- bzw. auseinanderkopieren" bestimmter Teilinhalte - am eigentlichen Inhalt bzw. dessen Qualität ändert sich nix.

Zitat

Das heißt also ich muss mir nich gelich gedanken machen das was falsch gelaufen is wenn die Daten nich ungefähr gleichgroß sind?

Ja, die Dateigröße des demuxten Materials sagt, bei Transportstreams, leider nicht wirklich etwas aus.

Wie illCP schon schrieb: Umpacken von Streams von einem in einen anderen Container sollte keine Qualitätsverluste mit sich führen, fallls nicht irgendetwas schief läuft.

Cu Selur

Zitat von Exy

Verändert das die Qulität bzw die Bitrate wenn man keinen Encoder benutzt oder bleibt die Qulität nach dem schneiden gleich wie im Original?

Wenn du keinen Encoder benutzt, bleibt die Qualität gleich - du kannst dann allerdings nur an I-Frames (bei DVB-Streams normalerweise ungefähr jede halbe bis ganze Sekunde, hängt vom Stream ab) und nicht framegenau (also auf eine fünfunzwanzigstel Sekunde genau auch auf P- oder B-Frames) schneiden.

Übrigens ändert der Einsatz eines Encoders in Cuttermaran nur die Stellen ungefähr eine halbe Sekunde (je nach Schnittpunkt und Stream) vor und nach dem Schnitt - bei vernünftiger Einstellung des Encoders fällt das kaum bis überhaupt nicht auf.

Noch etwas anderes ist der "Erzeuge DVD konformes Ergebnis"-Modus - hier werden z.B. alle GOPs mit mehr als 15 Frames neu encodiert. Habe ich persönlich noch nie ausprobiert (da mittlerweile eigentlich fast alle Standalone-Player auch nicht ganz 100% konformes Material problemlos anzeigen), hier kann es allerdings potenziell zu größeren bzw. auffälligeren Qualitätsverlusten kommen - je nach Einstellungen des Encoders und Quellmaterial.

Eventuell hilft dir diese Seite weiter http://www.highpaqnet.de/DVDGuide/HTML/…tml?vorwort.php

Ein Overhead von 400% hmm...

Zitat

Ein Overhead von 400% hmm...

Gehe sogar, dass man ihn noch größer bekommt, wenn Länge und Größe des Clips nur weit genug auseinander klaffen, d.h. kleiner aber langer Clip -> großer Overhead.

Vielleicht ist es ja kein Transport sondern ein Transponder-Stream
Ne weiß ich nicht, hat mich auch noch nie interessiert bei mir ist der Overhead normalerweise nur wenige MB groß.