Preview nicht möglich: "preview not available"

[DigiBC]

Hallo allerseits,

ich arbeite schon lange und sehr gerne mit ProjectX (ds.jar), nur eine Funktion hat bei mir leider irgendwie noch nie richtig funktioniert, nämlich die Preview.

Egal, welchen MPEG-Dateityp ich als Quelle verwende, unter "collection specials" wird stets "preview not available" angezeigt.
Im Vorschaufenster meldet das Programm: 0*0 bad(0) p bad comp MPEG1

Das Problem besteht auch mit der aktuellen Version X081.5++_int24/28.11.2003 (unter Windows XP SP1 + JRE 1.4.2.01).
Vor längerer Zeit, als die Funktion noch neu war, hatte es zumindest ab und zu mal funktioniert. (Zu den damals eingesetzten Versionen kann ich leider nichts mehr sagen.)

Ich bin zwar Java-Laie, aber die Fehlermeldung scheint auf ein MPEG-Decoderproblem hinzudeuten.
Ist die Preview auf bestimmte Java-/Windows-MPEG-Codecs angewiesen?
(Auf meinem System sind Windows-MPEG2-Decoder von MainConcept, Cyberlink und Ahead installiert, wobei der erstgenannte standardmäßig eingesetzt wird und im Windows Media Player sogar PVA-Files wiedergeben kann.)

Hat jemand eine Idee?

Gruß - DigiBC

[TheHorse]

X ist plattform-unabhängig und benutzt keine Fremd-Decoder, Plugins oder System-dlls. Alles wird per Hand (per Code) selbst dekodiert.
Ich hab grad mal ein MPEG1 in die int 24 reingeladen. Das geht in der Preview ohne Probleme.
Da in deinem Fall nicht mal die Bildgröße richtig erkannt wird, vermute ich, dass es sich um gar kein MPEG1 handelt, sondern ein wirklich nicht unterstütztes Format. Verdacht: AVI-Format oder wahrscheinlicher: Audio-Datei mp2 oder so erwischt?
Bei mir hat sich in der Preview nichts verändert, außer dass nun die (echten) MPEG 1 auch gehen.
PS: d*.j*r gibt's nicht mehr.

[DigiBC]

Auch wenn die Fehlermeldung etwas anderes suggeriert: Bei den Quelldateien handelt es sich um keine MPEG1-Dateien!
Ich habe VOB's, PVA's (von WatchTVPro) und diverse andere MPEG2-Dateien getestet, alle mit demselben negativen Ergebnis. Die sonstige Weiterverarbeitung (Demux) dieser Dateien macht in ProjectX übrigens keinerlei Probleme.

Bei der 0.81.5'er "Standard"-Version sah die Fehlermeldung noch geringfügig anders aus: 0*0 bad(0) p bad comp 0|res@res

Testweise hatte ich eben auch mal eine MPEG1-Datei reingeladen, was aber leider ebenfalls nichts ändert.

[TheHorse]

Richtig. MPEG1 ist die Defaultvorbelegung der Variable.
Puh. Probier mal die neue Option "also preview without sequence header".
Oder hast du etwa "use GOP (Frame) number for cuts" eingestellt? Stell auf "Use BytePos. ...". Ich glaub eher, daran liegt's?

[DigiBC]

Stell auf "Use BytePos. ...".
Das ist tatsächlich die Lösung!!! :o :o :o

Ich hatte schon alles Mögliche ausprobiert, aber nie vermutet, dass diese Einstellung irgendwelche Auswirkungen auf die Preview haben würde!

Die funktionierende Preview ist ein riesiger Komfort-Gewinn. :)

Vielen Dank und Gruß - DigiBC

[TheHorse]

Auf das Naheliegendste kommt man nicht immer gleich. Erst als du darauf bestandst, dass es wirklich mpeg2-Dateien sind. :D

[Pedant]

Hallo Ihr Lieben,
da das hier mein erster Beitrag ist, möchte ich zunächst mal einen guten Tag wünschen und nicht unerwähnt lassen, dass ich ProjectX und Vorgänger seit meinen Anfängen mit Begeisterung nutze. An dieser Stelle also, vielen Dank dafür und natürlich auch für die Arbeit hier im Forum.

@TheHorse
Oder hast du etwa "use GOP (Frame) number for cuts" eingestellt? Stell auf "Use BytePos. ..."
Den "Fehler" hatte ich auch mal gemacht, kam aber zufällig selbst drauf.
Ist das denn ein Bug, oder gibt es da einen schlüssigen Zusammenhang?
Die Anzeige mit Frame-Nummern würde mir wesentlich besser gefallen, aber den Preview möchte ich dafür mit Opfern.
Unter Frames kann ich mir gut was vorstellen, Byteposition dagegen ist mir zu abstrakt, besonders bei variabler Bitrate. Hat die Einstellung, abgesehen vom Preview, noch andere Auswirkungen?

Gruß Frank

[TheHorse]

Um AFAIK nach einem bestimmten GOP oder Frame zu suchen, müsste das File aufwändig nach jedem GOP-Header etc. abgescannt werden. Die GOPs tragen ja keine Etiketten mit ihrer Nummer, man muss immer von Anfang an mitzählen. Es würde evtl. bei Elementarströmen einfacher gehen, aber da nutzt's ja nix mehr.
Für eine vernünftige Geschwindigkeit der Preview käme dazu nur das Anlegen einer Indexdatei beim Laden jedes Files in Frage, was das Handling von X sehr umständlich machen würde.

[Pedant]

Hallo TheHorse,

danke für die Antwort, das ist leider irgendwie einleuchtend, aber im Grunde auch kein Problem.

Was mir mehr Kopfzerbrechen bereitet ist der unexakte Schnitt bei meinen Streams.
Wenn ich per dbox/Jack/udrec Filme aufnehme und anschließend mit ProjectX bearbeite, lassen die sich leider selten exakt schneiden. Das heißt die Bilder, die ich im Preview sehe, sind nicht unbedingt die Positionen an denen dann auch geschnitten wird.

Ich habe mal Folgendes probiert:
Meine Quelldateien eingeladen, Schnittpunkt gesetzt und cut/demux ausgeführt. Der Cutout fand dabei einige Sek. zu früh statt, was bei mir eher üblich ist.
Danach habe ich bei ProjectX, was immernoch geöffnet war, den Cutout entsprechend weiter nach hinten gesetzt, wobei der Preview dann hinter dem Film lag und cut/demux neu gestartet. Das Ergebnis lag dann schon recht nah am Ziel, aber der Film war dann ca. eine Sekunde länger als gewünscht.
Danach habe ich das geschnittene Material per ProjectX neu eingeladen, den Cutout passend zum Preview gesetzt und erneut cut/demux ausgeführt. Dabei kam genau das raus, was bestellt war.

Für den Cut in ist das weniger problematisch, da klicke ich zunächst auf "i" und sehe mir das kleine Videofile an, gegebenenfalls kann ich dann den Cutin etwas korrigieren ohne den ganzen Vorgang abzuwarten.
Die Verschiebung zwischen Soll- und Istwerten scheint zum Ende des Filmes auch größer zu werden.

Fazit: Wenn beim zweiten Durchlauf der Schnitt exakt ist, beim Ersten aber nicht, liegt die Vermutung nah, dass es am Quellmaterial liegt und nicht an ProjectX. Aber auch wenn ProjectX nichts dafür kann, stellt sich die Frage, ob es was dagegen kann? Oder bleibt mir nur die Option es zweimal zu machen, wenn der Film passend sein soll?

Hatte mit search hier zunächst nichts Entsprechendes gefunden. Falls das also ein ungewöhnliches Problem sein sollte, die entsprechenden Logs habe ich noch.

Gruß Frank

PS: Danke für den Titel.

[leth]

Hallo Pedant,

wenn ich mich nicht täusche, dann authorst Du deine DVD's doch mit DVD-Lab. Dort hast Du die Möglichkeit das Ende des Video-Materials zusätzlich zu schneiden. Sollte der Anfang also nach Project-X passen, dann kannst Du dir einen zweiten Durchlauf sparen und mal die Trim-Funktion in DVD-Lab probieren.

Wie du weißt schneide ich auch mit Project-X, allerdings hatte ich die von dir genannten Probleme noch nie *aufholzklopf*.

Cu leth

[Pedant]

Hallo Leth,

'ne ich nehme einfach nur IfoEdit und fertig und da gibt's meines Wissens diese Option nicht, aber da kann ich mich auch täuschen.
DVD-Lab wäre dann für mich, zumindest bei 3APid-Aufnahmen, genauso ein weiterer Zwischenschritt, wie die zweite Runde ProjectX.
Trotzdem danke für den Tipp.

Gruß Frank

[dvb.matt]

Horse hat schon alles gesagt :)
Die Anzeige mit Frame-Nummern würde mir wesentlich besser gefallen,
sie würde nur nichts nützen bzw. zu was würdeste die dann benützen?
Wenn du mit Vorschau (also 'optisch') schneidest, spielt doch alles andre keine Rolle.
leider selten
war also schon vor 081.6?
Wenn beim zweiten Durchlauf der Schnitt exakt ist, beim Ersten aber nicht, liegt die Vermutung nah, dass es am Quellmaterial liegt und nicht an ProjectX
sind das jetzt die 'typischen' udrec .v0 Dateien? (also PES vpacketsize=0 unter files)
leth nimmt ja wohl auch udrec's?
da kann man nochmal nachgucken, ob die zurückgegeben Bytepos. evtl. nicht ganz stimmen.
Bei meinen Tests vorhin war jedenfalls bei so'nem Typ statt die angegebne 'vorgeschaute' GOP die _vor_ dem Schnitt beim demux als 'Kriterium' genommen worden.
soll soo nich sein...
vorher jedoch in irgendein andres StreamFormat (PVA,VDR..) gewandelt, passt es genau. (wie du ja mitm mpv festgestellt hast)
die entsprechenden Logs
für die Vorschau gibts keine Logs, daher ist dann ein Fileausschnitt vonnöten..
aber hierbei kann ichs auch 'selbst' nachvollziehen..

[Pedant]

Hallo dvb.matt,

sie würde nur nichts nützen bzw. zu was würdeste die dann benützen?
Ich war es nur von ds.jar gewohnt, die per Moonligt ermittelten Framenummern als Cutpunkte einzusetzen. Außerdem kann ich mir unter einem Frame was vorstellen unter einer Byteposition nicht so richtig.
Das ist aber Alles nicht wichtig, die Erklärung von TheHorse war ausreichend um die Frage abzuschließen.
Framenummern wären eventuell für einen Batchbetrieb von Vorteil, aber dafür habe ich im Moment keinen Bedarf oder keine Idee wie mir das was nützen sollte.

sind das jetzt die 'typischen' udrec .v0 Dateien? (also PES vpacketsize=0 unter files)
Das sind jedenfalls per udrec aufgenommene .v0 Dateien. Was "PES vpacketsize=0 under files" bedeutet weiß ich leider nicht.

war also schon vor 081.6
Genau genommen kenne ich es nicht anders, für mich also ab ds.jar 0.60b.
Die Abweichung variiert von Film zu Film, bei manchen stimmt es sogar, aber meist wird zuviel abgeschnitten.
Die Logs hatte ich erwähnt, in der Annahme, dass bei meinen Streams was nicht stimmt und beim ersten Schnitt, die Fehler eventuell dokumentiert werden.

da kann man nochmal nachgucken, ob die zurückgegeben Bytepos. evtl. nicht ganz stimmen.Ist "man" Du oder ich? Falls Du mich meinst, weiß ich leider nicht wo ich da was nachsehen kann.

Bei meinen Tests vorhin war jedenfalls bei so'nem Typ statt die angegebne 'vorgeschaute' GOP die _vor_ dem Schnitt beim demux als 'Kriterium' genommen worden.
Diesen Satz verstehe ich leider gar nicht.

Gruß Frank

[TheHorse]

gewohnt, die per Moonligt ermittelten Framenummern als Cutpunkte einzusetzen.Das kannst du ja trotzdem. Nur springt halt die X-Preview nicht dorthin, aus den angeführten Gründen. Ich habe das früher so viel über mme.exe gemacht, als X noch keine Preview hatte. Das geht ja weiterhin.
Zu meinem Glück kenne ich mit den Topfield-Streams keine Schnittprobleme in X. Wenn da ein Cut-Frame angezeigt wird, dann ist das auch wirklich der "echte". Ich kenne die anderen Aufzeichnungsformate nur vom Mitlesen und weiß eigentlich wenig darüber, erfahre aber hin und wieder, dass die Entwickler dieser Streams manchmal etwas eigene Wege gehen.

matt schließt nicht ganz aus, dass bei Streams in deinem speziellen Format in X noch Nachbesserungsbedarf sein könnte. Das möchte er wohl mit dem Satz aussagen, er kann ja die Streams selbst analysieren, da ihm solche wohl vorliegen.
Also mal abwarten und viel Kaffee trinken ... :wink: :wink:

[Pedant]

Hallo TheHorse,

gut Kaffee trinken und Füße still halten, hoffe es ergeben sich neue Erkenntnisse bei dvb.matt und hoffentlich hat er keine Files von z.B. Leth sondern so blöde Dinger, wie ich sie habe.

Gruß Frank

[petgun]

hiho,
ich klinke mich hier mal ein ;-) hab' auch 'ne Dbox und Files wie Leth und Pedant. Meine _einzige_ 'Kritik' an ProjektX, ist die (nur bei mir ?)langsame Schnittfunktion mit Preview...trotz P4 2,2 Ghz.

Laesst sich das nicht beschleunigen ? Vielleicht in einer 'optimierten' Windows-Variante unter Aufgabe der Plattformunabhaengikeit ? Ich denke an eine abschaltbare Option...'use overlay/DirectX/DirectShow-Filter' oder so aehnlich ;-)

cu,
peter

PS: Danke fuer dieses geniale Programm !!

[dvb.matt]

sondern so blöde Dinger, wie ich sie habe.
ja hab ich :) und die ermittelten Vorschaupunkte sind iO, an andrer Stelle ist aber was zu ändern.
bis spät. zum WE gibts das dann, wobei ich dies' Jahr eigentlich nichts mehr fiXen wollte :?

Laesst sich das nicht beschleunigen ?
dies' Jahr nicht mehr, vielleicht im nächsten. :wink:

@all JtG'ler
da euer Forum für unreg's nicht mehr sichtbar ist, _müsst_ ihr eure Sorgen mit X _hier_ posten...

[petgun]

dies' Jahr nicht mehr, vielleicht im nächsten. :wink:
:) :) ich kann warten...Du kannst keine Aussage machen wieviel Beschleunigung Du Dir erhoffst/erwartest ?

@all JtG'ler
da euer Forum für unreg's nicht mehr sichtbar ist, _müsst_ ihr eure Sorgen mit X _hier_ posten...

...bevor wir (JtG Team-Member) Bloedsinn im JtG-Forum posten oder wenn wir mit unserem Latein am Ende sind wenn's um Dein ProjektX geht, gibt's natuerlich einen Link hier ins Forum....oder wir opfern uns auf und fragen hier stellvertretend ;-)

cu,
peter

[dvb.matt]

Du kannst keine Aussage machen wieviel Beschleunigung Du Dir erhoffst/erwartest ?
erhoffen tu ich mir garnichts, weil es für mich persönlich nicht so wichtig ist und eher nebensächlich.
wenn X n' Schneidetool hätte werden sollen, läge das Vorschaufenster im Zentrum aller 'Knöppe' und Bemühungen. :wink:


hier (http://forum.dvbtechnics.info/viewtopic.php?t=414) das Spieleupdate.
was mich diesbzgl. arg verwundert ist, dass das vorher niemandem aufgefallen ist? Insbes. den WinPVR-raw Benutzern...

na jedenfalls jetzt solltes dabei die Punkte richtig auswerten, und zudem auch schneller laufen.
evtl. sind die Bufferwerte nun neu anzupassen!

[petgun]

Hi,
...ich freue mich auf den Test heute Abend :D

cu,
peter

<edit>
Danke fuer die neue Version! Der Schnitt war jetzt bei meinem ersten Test exakt an der markierten Stelle...einen Geschwindigkeitszuwachs beim Preview konnte ich leider nicht feststellen :| ...und meine Wunschvorstellung dazu schminke ich mir auch besser ab, nachdem Du hier noch mal klar gemacht hast wo der Fokus Deines Programmes liegt...sehe ich 100% ein !
</edit>

[dvb.matt]

Geschwindigkeitszuwachs beim Preview
neenee, der Zuwachs gilt den Dateilesevorgängen bei diesem Formattyp, was insbes. bei HDTV am ehesten bemerkbar sein sollte.
das war vorher bei diesem speziellen Rohformat quasi unmöglich...
(die jetzigen Buffer erlauben nun aber auch da eine halbwegs vernünftige 'Arbeit')

[Pedant]

Hallo dvd.matt,

die aktuelle Version X081.6_int03 hat meine Schnittschwierigkeiten wahrscheinlich völlig beseitigt.
Habe jetzt beim sechsten Schnitt mit dieser Version immer eine Übereinstimmung mit den gesetzten Punkten und dem fertigen Schnitt.
Vielen Dank, dafür.

Gruß Frank

[TheHorse]

die aktuelle Version X081.6_int03Du meinst int_05! :wink:

[dvb.matt]

na eigentl. ab 02, gell?

nochmal:
wichtig ist, das der I-Buffer (max Größe eines PES-Packets, da keine Größenangabe im Strom, vorher war das automatisch aber ineffektiv) angepaßt wird, also normal ~190kB, ORF mehr, HDTV am höchsten, jedoch ausschließlich bei diesem Type wirksam.

desgleichen gilt für die V-'raw's des Hyundai/Kathrein und dgl...