VOB-Datei viel grösser als die Summe der Streams?

[Tensai]

Ich bin dabei eine miniDVD zu erstellen für einen 46:42min langen Film. Enthalten sollen zwei Audio-Tracks sein (jeweils AC3, 2.0, 160 kbit/s) sowie ein Subpicture-Stream.
Mit diversen Bitratecalculatoren habe ich nun die Bitrate für den Film berechnet und je nach Programm wurde mir gesagt, dass ich mit den gemachten Vorgaben eine Bitrate von 1704 bis 1711 kbit/s wählen soll, wobei schon eine Sicherheitsreserve für den Subpicture-Stream (~1.5MB) und die ifo und bup-Files von 5MB eingeplant war.
Also habe ich den Film mit 1700kbit/s codiert und dann alles in IFOEdit authored.
Zu meinem erschrecken musste ich nun feststellen, dass das VOB-File ca. 10MB grösser war als die Summe der einzelnen Streams und somit hat das ganze auch nicht mehr auf meinen 700MB-Rohling gepasst.
Im nachhinein muss ich sagen, dass das ja logisch ist, da im VOB ja auch noch die Navigation-Pakets Platz haben müssen.
Da anscheinend bei den Bitraterechnern davon ausgegangen wird, dass man nur wenige Minuten Film auf eine miniDVD brennt, werden die wohl vernachlässigt bzw. gehören zu den 5 MB Sicherheitsplatz.
Ich frage mich nun, wie man nun am besten die Bitrate für einen Film unter Berücksichtigung aller Komponenten berechnen kann um einen Rohling obtimal auszunutzen.
Gibt es z.B. ein Programm, dass ein theoretisches VOB-File berechnet damit man die CD-R kapazität nicht überschreitet.
Oder wie berechnen ich sonst die genau grösse eines VOB-Files.

Jede Hilfe ist willkommen.

P.S. Und bitte nicht motzen 1700kbit/s für eine miniDVD sei viel zu tief. Es handelt sich um ein Kinofilm (2.35:1) welcher im D1/2-Format 4:3 Fullscreen encodet wird und daher auf meinem 70cm TV auch bei 1700kbit/s immer noch 1. Sahne aussieht (keinerlei Verblockung).

[shh]

Ich habe jetzt mal in Fit2Disc eingetippt:
- 46:42min
- 2x 160kbps AC3
- 4096KB Extra-Daten (Menü etc)
- ~1,5MB Subpictures auf der Festplatte (bevor sie komprimiert werden)
- 1x 80er Rohling (150blocks Sicherheit)

Da bleiben fürs Video genau 1700kbps übrig (nix gerundet).
D.h. dein Video hätte auch auf den 700er Rohling passen müssen. (am Ende hätte noch 408KB frei sein müssen)

Fehlerquellen:
- in TMPGEnc 1700 eingegeben. Dann macht das Programm 1700*1024bps = 1740.8kbps = 1700Kbps.
- falsches Multiplexing
- extrem viele Scene-changes (unwarscheinlich)
- schlechtes Authoring: Nero zB

Wie gross (in KB) sind denn deine Audio + Videodateien? Wie gross genau deine subs?

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Tensai]

Danke für die Antwort.....

Das ganze hat sich erledigt und es lag wohl irgendwie am Erstellen der Image-Datei. Hab's nochmals probiert, mit ImgTool und siehe da, es bleiben tatsächlich noch ca. 600KB frei....(knapp 300 Blocks)

Trotzdem scheint es mir, dass die Berechnung der Bitrate ohne Kenntnis der Anzahl GOP eine Glückssache bleibt, da man nur wenn man die Anzahl GOP kennt auch weiss, wieviel Navigation-Packets im resultierenden VOB geschrieben werden....

[shh]

> Trotzdem scheint es mir, dass die Berechnung der Bitrate ohne Kenntnis der Anzahl GOP eine Glückssache bleibt,

Vollkommen korrekt. Deswegen sollte ein Bitratenrechner auch die Eingabe der GOP-Länge erlauben und bei automatischer scene-detection zumindest eine grobe Anpassung der GOP-Längen vornehmen. Siehe: FitCD
Die meisten Bitratenrechner berechnen das Multiplexing aber gar nicht und es wird das overhead nur grob geschätzt. NAV-packs werden da vermutlich eh nicht mitgerechnet.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Tensai]

Naja, der Aufbau eines VOB ist ja auch nicht so einfach zu verstehen und ich bin mich da immer noch am Einarbeiten.

Wie berechnet denn Dein Programm konkret das Multiplexing bzw. die VOB Grösse und wie viel Reserve kalkuliert es ein?
Vielleicht "donate" ich ja auch noch....
Wobei man aber eigenlich ja auch alles von Hand rechnen kann.

[shh]

> Wie berechnet denn Dein Programm konkret das Multiplexing bzw. die VOB Grösse

Betriebsgeheimnis.
...aber eben so, wie die VOBs auch von DVDMaestro, ULead Powertools usw. rauskommen.
D.h. wenn sich die encoder an die eingestellte bitrate halten, passt das auch auf die CD/DVD.

> wie viel Reserve kalkuliert es ein

Kann man sich einstellen. Standardeinstellung sind 150blocks per Rohling, d.h. sowiel bleibt mind. frei. (wenn die encoder mal spinnen, oder der Film extra viel I-frames hat)
Fürs minimale DVD-Authoring (nur IFOs + Grunddateien) habe ich 450blocks einkalkuliert. Wenn noch mehr Sachen noch draufpacken möchte, gibt man einfach die entspechende Abzugsmenge an.

Sicherlich kann man sich das alles per Hand ausrechnen ausrechnen, ist aber auf Dauer etwas "pfimelig". Deswegen habe ich mir das Programm ja geschrieben.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Tensai]

Also ich habe mir mal die Mühe gemacht und alles mal ein wenig durchgerechnet. Folgendes sind die Ausgangsdaten:

AC3 Stream: 56042880 bytes (2x)
Video Stream: 595496276 bytes
Sub Stream: 1175028 bytes (Bereits im .sup-Format)

Das ganze gemuxt mit IFOEdit ergibt:

VOB: 736016384 bytes
NV_PCK: 5996
A_PCK: 2x 27800
V_PCK: 297031
S_PCK: 756

Da ja die V_PCKs am Ende jedes VOBU nicht ganz voll sind habe ich fogende Annahme getroffen:

5996 V_PCK sind im Durchschnitt nur halb voll, also ~1024bytes

5996 x 1024 = 6139904 bytes

595496276 bytes (Videostream)
-6139904 bytes
= 589356372 bytes

589356372 : 291035 = ~2025 bytes/sector

Für die A_PCK gilt:

56042880 : 27800 = 2015.93 also 2016 bytes/sector

Rechnet man: 27799 x 2016 = 56042784
56042880 - 56042784 = 96
Und tatsächlich befinden sich im letzten A_PCK nur 96 bytes Daten.

Die S_PCK habe ich nicht gross angeschaut. Anscheinend braucht es pro Subtitel einen Sektor.

Schlussfolgerung:

Der Datenbereich pro Sektor bei Video-Packs beträgt "nur" ~2025 bytes und bei Audio-Packs "nur" 2016 bytes.
Dies stimmt sehr schön überein mit den Daten die ich hier (http://www.dma.org/) gefunden habe.

Mit diesen Angaben kann man nun die voraussichtliche Grösse eines VOBs schon sehr gut bestimmen. Natürlich fehlt immer noch die Anzahl GOP. Aber man kann ja mal einen erste Codierung mit einer ungefähren Bitrate starten undso die Anzahl GOP bestimmen. Anschliessend korrekte Bitrate bestimmen und entgültig codieren.

Wobei aber unter obigem Link gesagt wird, dass der Datenbereich unterschiedlich gross sein kann (z.B. V_PCK: 2025 byte or less, Header up to 29 byte). Hängt das vom Authoringprogramm ab oder vom Stream?

Rechnet Dein Programm auch mit den oben genannten Datenbereichen?

Ist alles wohl doch sehr sehr kompliziert......

Was ich noch anfügen wollte:

Auf der CD befindet sich also nun:
Video_TS.IFO     4 Sektoren
Video_TS.BUP    4 Sektoren
VTS_01_0.IFO   19 Sektoren
VTS_01_1.VOB  359383 Sektoren
VTS_01_0.BUP  19 Sektoren

Also total 359429 Sektoren. Kommen noch 256 Sektoren fürs UDF ergibt 359685 Sektoren. Bleiben noch 315 Sektoren übrig.
Also 613 KB und da frage ich mich, wo da die 4096 KB Zusatzdaten noch Platz haben sollten. Also hat Dein Programm wohl doch auch falsch gerechnet. Und mit Durchschnittlich 11 Frames pro GOP habe ich auch nicht besonders viel I Frames, oder?



Zuletzt bearbeitet von Tensai

[Tensai]

Ich wollte nochmals was anfügen.

Ich habe nämlich gerade das VOB noch in VOBEdit betrachtet und dort sieht man wunderschön, dass bei den Video-Packs der MPEG-Frame Inhalt bei Byte Nr. 23 beginnt und somit der Datenbereich korrekt 2025 Bytes beträgt (meine Rechnung oben stimmt somit genau). Auch bei den Audio-Packs beginnt der Audio-AC3-Frame bei Byte Nr. 32 und der Datenbereich beträgt wie oben errechnet 2016 Bytes.
Da hätte ich mir dieses Rechnen auch ersparen können....  

[shh]

> Video: 2025 Bytes beträgt
> Audio-AC3: 2016 Bytes

Nicht immer, aber meistens.

> Also hat Dein Programm wohl doch auch falsch gerechnet

Pah! kann ich mir doch nicht bieten lassen...

Ich hatte angenommen (die Info hast du mir ja vorenthalten),  dass du eine GOP-Länge von 15 verwendest.
Subs hängen, wie du schon vermutet hast, von deren Anzahl ab. Die fehlt mir auch zum berechnen. Zudem hatte ich angenommen, du meinst mit den 1,5MB die BMPs vor der Komprimierung.

Dreht man die GOP-Länge von 15 auf 12 runter reduziert sich die nötige Videobitrate ganz schnell von 1700kbps auf 1690kbps. (deswegen hast du auch keine 4MB mehr frei)

Mit deinen neuen Infos über GOP + Subs:
incl. 4MB frei: Video: 1689kbps
ohne 4MB frei: Video: 1701kbps

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Tensai]

Dein Programm kann ja anscheinend wirklich was.
Ich habe nämlich tatsächlich den Film in CCE 2.5 mit M=3 und M/N=4, also 12 Frames/GOP encoded. War mir voher gar nicht aufgefallen.... Sorry  
Ich dachte ich habe 15 Frames/GOP und die durchschnittlichen 11 Frames/GOP stammen von der Scene-Detection.
Habs mal noch schnell nachgerechnet und...

>Mit deinen neuen Infos über GOP + Subs:
>incl. 4MB frei: Video: 1689kbps
>ohne 4MB frei: Video: 1701kbps

stimmt genau....

Da kann ich nur sagen:

>Pah! kann ich mir doch nicht bieten lassen...

Sorry und nichts für ungut. Musst Dir auch nichts bieten lassen  


Noch betreffend Subs hab ich mal nochmals nachgeschaut und es scheint mir, dass pro Subtitel durchschnittlich 2.13 Sektoren gebraucht werden. In meinem Fall 354 Subtitle BMPs in 756 S_PCK.
Aber die Subs sind wohl wirklich am Schwierigsten zu berechnen....

>> Video: 2025 Bytes beträgt
>> Audio-AC3: 2016 Bytes
>
>Nicht immer, aber meistens.

Was sind denn die Ausnahmen???

Auf jeden Fall weiss ich jetzt wie ich die Bitrate "von Hand" ziemlich genau berechnen kann.
Aber vielleicht spende ich Dir ja doch noch die €9.30 für Dein Programm um mir die "Handarbeit" abzuehmen. Aber warum ist PayPal (für mich als Schweizer wohl die einfachste Möglichkeit) denn so viel teuerer?

[shh]

> Was sind denn die Ausnahmen???

Nun ja, der erste PACK und die mit einem Sequence-header fassen ein paar Bytes weniger. Ich habe mir tatsächlich mal die Mühe gemacht, die irrelevante Feinheit zu implementieren.

> Subs

Stimmt, die sind wirklich ein Problem.
Bei SVCDs hatte man i.a. BMPs als Ausgangspunkt, da habe ich die Kompression nach vielen Tests schätzen müssen.
Weil man bei DVD-Material aber eh schon komprimierte subs hat, sollte ich vielleicht mal wieder ein bisschen analysieren und aktualisieren - bei der DVD ist's halt doch anders. Zumindest grob scheint die jetzige SUB-Schätzung aber zu treffen.

PayPal ist leider ein ziemlich teuerer "Spass". Die ziehen erheblich Gebühren ab, sei's bei Währungswechseln, bei Auslandstransaktionen und beim finalen "Abheben" auf mein Konto. Am Schluss bleiben von den 9,30 nur etwa die 8,- EUR übrig, also soviel wie ein anderer per Banküberweisung in D. zahlen müsste.
D.h. ich wälze nur die Zusatzkosten ab. PayPal ist schuld - bitte da beschweren.
So wie ich das gesehen habe, scheinen die Moneybookers für Europäer aber etwas günstiger zu sein: http://www.moneybookers.com/app/help.pl?s=fees
Das läuft auch alles ohne Kreditkarte (Validierung geht recht flott über's Bankkonto).

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools