@Garfield:
Das Problem ist noch nicht ganz gelöst. Ich komm mit der Bit-Auslesung nicht klar.
0.06a war nur so ein Versuch. 0.06 war eigentlich die letzte Version.
Das mit den zwei Frame_rate ist so:
Wenn ich nach Leerzeichen suche kommt automatisch auch die Zeile mit Frame_rate.
Hier nochmal ein Ausschnitt der zu bearbeiteten Datei:
Code:
DGIndexProjectFile13
1
I:\Delphi\D2VCreateCLI\test\test.vob
Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=2
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=704x576
Field_Operation=2
Frame_Rate=25000 (25/1)
Location=0,0,0,26F7F
900 1 0 190464 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 638976 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 1081344 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 1523712 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 1921024 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 2351104 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 2754560 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 3147776 1 16 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
Der Leerzeichencode hat eh noch einen Bug, da ich erst ab der Zeile Stream_Type= anfangen zu Suchen müsste. Es würd ein Fehler passieren, wenn die Dateienpfade (hier im Beispiel 'I:\Delphi\D2VCreateCLI\test\test.vob') Leerzeichen enthalten. (Edit: habs grad getestet. Passiert anscheinend doch nichts ...)
Mit dem neuen Tool D2VCreate hab ich einen Weg gefunden, die Datei über das Programm DGIndex auszulesen, welches auch die Dateien erstellt hat. Nur würd ich gern das Gleiche auch anhand der D2V-Datei mit D2VParse können wollen.
Falls Du also noch nen Tip für mich hättest, wie ich das mit den Bit6 machen kann, währe ich dankbar.
Auch über folgendes müsste ich mir noch Gedanken machen:
Zitat:
by neuron2
There's too much context missing for me to do more than make a few comments. Certainly, I can't see *any* bit operations in that last code fragment.
Why would you try to convert '0' and '2' to uppercase?
Seems to me that Pos() is just going to test if a '2' is present, i.e., in either the least significant or the most significant nibble of the flags byte. But it is only the least significant nibble of the flags byte that should be considered. You should use bit operations as I showed in an earlier post.
You are missing cases for '1' and '3'. A clip starting with a BFF repeat (1) is BFF. A clip starting with a TFF repeat (3) is TFF.
I'll just warn you that you have to be careful in interpreting the meaning of the TFF flag when pulldown is present. For example, a clip may start off as TFF (2). Then say a TFF repeat occurs (3). Now, strangely, the next frame will be flagged as BFF (0) even though it is continuing a TFF sequence!
And here's something else to think about... An MPEG2 clip can change field order anywhere at any time:
000000000002222222222222222...
It's OK as long as the display process skips or repeats a field so that a strict field alternation is preserved. But if you convert such a clip to AVI and do not correct that, you'll have a mess (that's why DGIndex has the 'Correct Field Order' option). Also, how would you report a clip like the one above, TFF or BFF?
My policy to avoid all these complications is to look at just the flags byte of the first encoded picture. If it is TFF, then the clip is called TFF.