Schnittpunkte an falscher Stelle

Begonnen von Leugenios, März 05, 2019, 08:17:19

« vorheriges - nächstes »

Leugenios

Hallo,
ich arbeite schon jahrelang mit dem TS Doctor, nun habe ich aber eine Frage was da falsch läuft.
Setze ich ein Schnittpunkt (F) nimmt er immer den nächsten und schneidet da. Somit gibt es dann immer Ruckler.
Ist aber erst seit einigen Tagen (Wochen) weiß gar nicht genau seit wann.
gibts da eine Lösung für? danke
Neutrino Boxen ZEE, HD1, Trinity, NEO V2, Neo²

Mam

Da gibts sonne Option für "Bevorzuge Schnitt vor dem Cut-Out Punkt".
Je nachdem, ob gesetzt oder nicht, verlagert der Doc den wirklichen Schnittpunkt einen I_Frame VOR oder NACH dem Punkt, den Du anvisiert hast.
Bei moderneren (H264 und neuer) Videocodecs ist ein Schnitt an beliebige Stelle nicht möglich.

Leugenios

Hab das jetzt so eingestellt. Aber dennoch schneidet er erst den nächsten iframe nicht den ich genommen habe sondern immer direkt den folgenden. Macht er aber erst seit dem letzten oder vorletzten update ist mir sonst nie aufgefallen.
Neutrino Boxen ZEE, HD1, Trinity, NEO V2, Neo²

Leugenios

Ich wollt mal wieder nachfragen ob es da schon eine Lösung für gibt. Denn es ist immer noch so das der Schnitt immer 2-3 Iframe später erfolgt als gesetzt.
Neutrino Boxen ZEE, HD1, Trinity, NEO V2, Neo²

Mam

Zitat von: Leugenios am April 05, 2019, 07:50:23
Ich wollt mal wieder nachfragen ob es da schon eine Lösung für gibt. Denn es ist immer noch so das der Schnitt immer 2-3 Iframe später erfolgt als gesetzt.
Deine einzige Chance hierbei ist ein (hoffentlich erfolgreiches) Update des Videotreibers. Manche Treiber lassen die Info "I-Frame" nicht immer durch, so dass der Doc "durchrutscht". Achte besonders darauf, dass Du keine "Hardwareunterstützung" aktivierst, die haben die starke Tendenz, die Daten bei sich zu behalten und den Doc im Dunkeln zu lassen.

gizmo23

#5
Ich habe mal ein paar Tests gemacht, da die letzten geschnittenen Filme bei mir ebenfalls nicht passten. Es handelt sich dabei erst einmal um MPEG2-Material. Evtl. schaue ich mir das auch später noch mal für H.264-Videos an.

Cut1 nach 20 Fames. Das wäre ein B-Frame, also müsste am letzten I- oder P- Frame geschnitten werden ("Bevorzuge Schnitt vor dem Cut-Out-Schnittpunkt" ist gesetzt).

Original Frame-Strukturen:
IBBIBBIBBPBBPBBPBBPB BIBBPBBPBBPBBI..
(cut1)
IBBPBBPBBPBBPBBI..
(cut2)


Es sollte nach dem Schnitt also so aussehen:
IBBIBBIBBPBBPBBPBBP-IBBP..
(cut1)              (cut2)

Herausgekommen ist allerdings:
IBBIBBIBBPBBPBBPBBPB BIB-IBBP..
(cut1)                   (cut2)


(Die Leerzeichen habe ich mal zur Kenntlichmachung der 20 Frames eingefügt.)

Wie man sieht, wird nach dem B-Frame des NACHFOLGENDEN I-Frames geschnitten. Das bedeutet, dass sowohl die Einstellung "Bevorzuge Schnitt vor dem Cut-Out-Schnittpunkt" nicht beachtet wird, als auch fälschlicherweise nach einem B- und nicht, wie es richtig wäre, nach einem P- oder I-Frame geschnitten wird. Wenn ich die Option "Bevorzuge Schnitt vor dem Cut-Out-Schnittpunkt" ausschalte, kommt das gleiche Ergebnis heraus.

Treffe ich (zufällig) manuell ein P-Frame für den cut-out, so wird korrekt geschnitten:

IBBIBBIBBPBBPBBPBBP-IBBP..
(cut1)              (cut2)


Setze ich manuell die cut-outs auf I-Frames, so wird ebenfalls (fast) korrekt geschnitten. Beim allerletzte cut-out fehlt das letzte I- oder P-Frame, wenn der cut-out manuell auf ein solches gesetzt wird. Somit endet die Sequenz mit einem B-Frame, was ebenfalls nicht ganz korrekt ist.

Die Frame-Strukturen im Video-PID habe ich mit dem DVB Inspector ausgelesen.


---------------------- System Information -----------------------
TSDoctor.exe V 2.2.18 (Build 0539B3)
Instance : 1
Serial   :
OS       : Windows 10 Build 17763 x64
CPU type : Intel(R) Core(TM)2 Duo CPU     T9400  @ 2.53GHz
CPU count: 2
System memory: 3,95 GB / Free: 806,07 MB
Used memory  : 242,69 MB
Temp folder  : C:\ProgramData\Cypheros\TsDoctor2\Temp
OS language     : DE
Appl. language  : German
OCR             : 4.10
Free disk space : (C:) 20,2 GB
Mobile Intel(R) 4 Series Express Chipset Family (Microsoft Corporation - WDDM 1.1) (DISPLAY2) igdumd32.dll 8.15.10.2702
Mobile Intel(R) 4 Series Express Chipset Family (Microsoft Corporation - WDDM 1.1) (DISPLAY1) igdumd32.dll 8.15.10.2702
Resolution   : 1920 x 1080 (32Bit) 96 DPI
Monitors     : 2
Supported splitter filter found   : [Haali Media Splitter], LAV Splitter
Supported audio filter found      : LAV Audio Decoder, ffdshow Audio Decoder, [Cypheros Audio Decoder]
Supported Mpeg video filter found : [LAV Video Decoder], Cypheros MPEG2 Video Decoder, ffdshow Video Decoder(4532)
Supported H264 video filter found : [LAV Video Decoder], ffdshow Video Decoder(4532), Microsoft DTV-DVD Video Decoder
Supported video renderer found    : [Video Renderer], Haali Video Renderer, Enhanced Video Renderer
-----------------------------------------------------------------

Kiraly-Cutter

#6
Die "Serial   : TSD- ...."  lösch aber bitte im Beitrag, sonst tut es Cypheros.
Dreambox DM920 UHD 4K
VU+ Duo 4K SE

gizmo23

Zitat von: Kiraly-Cutter am April 19, 2019, 21:34:51
Die "Serial   : TSD- ...."  lösch aber bitte im Beitrag, sonst tut es Cypheros.

Vielen Dank für den Hinweis. Hatte ich übersehen.

gizmo23

Ich habe mal noch ein wenig mit H.264 Videos herungespielt. Es handelt sich dabei um 1440x1088 i 25 fps Material. Da es interlaced kodiert ist, gehören immer 2 AUs zu einem Frame.
Normalerweise sollte eine Sequenz folgendermaßen aussehen:
IPBBBBBBPPBBBBBBPPBBBBBBPPBBBBBBPPBBBBBBPPBBBBBBPPBBBBBB IPBB..
Diese wiederholt sich dann immer mehr oder weniger regelmäßig, da an Schnitten üblicherweise zusätzliche IP-Frames eingefügt werden.

Zuerst ist mir aufgefallen, dass bei jedem cut-in (egal ob es der erste ist oder ein weiterer) nach dem IP-Frame die 3 BB-Frames zu fehlen scheinen:
IPPPBBBBBBPPBBBB..

Weiterhin wird auch bei H.264 immer am NÄCHSTEN I-Frame geschnitten. Auch hier scheint der Parameter "Bevorzuge Schnitt vor dem Cut-Out-Schnittpunkt" nicht zu greifen.
Wenn ich es richtig verstanden habe, müsste ein Schnitt bei H.264 (interlaced) folgendermaßen aussehen:
..BBPPBBBBBBIPIPBBBBBBPPBB..
Damit würde cut1 mit einem IP-Frame enden und cut2 auch mit einem IP-Frame beginnen.

Setze ich nun den cut-out auf ein BB- oder PP-Frame, so sieht das Ergebnis folgendermaßen aus:
..BBPPBBBBBBIPPPBBBB..
Es scheint also das letzte IP-Frame von cut1 zu fehlen und die dem 1. IP-Frame aus cut2 nachfolgenden BB-Frames sind (wie schon oben erwähnt) verschwunden - es geht dann direkt mit einem weiteren PP-Frame weiter.

Setze ich den cut-out auf ein IP-Frame, sieht es noch merkwürdiger aus:
..BBPPBBBBBBIPBBBBBBIPPPBBBB..
Hier werden nach dem letzten IP-Frame von cut1 also noch die 3 BB-Frames mitgenommen und dann mit dem bereits bekannten IPPP aus cut2 begonnen.

Das Ende des gesamten Video-Streams sieht wieder sehr offen aus:
..BBIPBBBBB
Da scheinen 2,5 Bilder in Form von 5! B-AUs zu viel kopiert zu werden.

Die Ergebnisse sind so auch jederzeit zu 100% reproduzierbar, variieren also nicht bei einem erneuten Schnitt.
Also wenn der Parser des DVB Inspectors nicht rumspinnt, dann stimmt etwas mit den Schnitten des TSD nicht - oder aber ich habe da etwas komplett missverstanden.

gizmo23

Liegt das irgendwie am Splitter? Ich dachte immer, dass der Haali Splitter da recht zuverlässig wäre. Andere Splitter haben bei mir zumindest bisher nur mehr Probeme bereitet (keine oder schlechtere I-Frame detection).
Oder hat es andere Gründe, dass die Schnitte so merkwürdig aussehen?

Mam

Zitat von: gizmo23 am Mai 06, 2019, 09:48:19
Ich dachte immer, dass der Haali Splitter da recht zuverlässig wäre.
Jein  ;D
Eigentlich ist er ganz gut, nur leider auch in die Jahre gekommen und schon lange nicht mehr gepflegt worden. Die Sender experimentieren reichlich mit den Encoder Einstellungen, manche davon gefallen dem Haali gar nicht mehr so toll...

gizmo23

Zitat von: Mam am Mai 06, 2019, 14:04:37
Jein  ;D
Eigentlich ist er ganz gut, nur leider auch in die Jahre gekommen und schon lange nicht mehr gepflegt worden. Die Sender experimentieren reichlich mit den Encoder Einstellungen, manche davon gefallen dem Haali gar nicht mehr so toll...

Gibt es eine Empfehlung für einen anderen Splitter, der dann möglichst auch die I-Frame Detection zuverlässig ermöglicht?

Mam

Zitat von: gizmo23 am Mai 07, 2019, 16:20:04
Gibt es eine Empfehlung für einen anderen Splitter, der dann möglichst auch die I-Frame Detection zuverlässig ermöglicht?
Ich bleib beim ollen Haali, die anderen sind noch schlechter.
Unbestätigten Gerüchten zufolge wollte Scheff irgendwann mal einen eigenen machen, der dann natürlich die ultimative Rampensau sein wird.

gizmo23

Zitat von: Mam am Mai 07, 2019, 16:21:56
Ich bleib beim ollen Haali, die anderen sind noch schlechter.
Unbestätigten Gerüchten zufolge wollte Scheff irgendwann mal einen eigenen machen, der dann natürlich die ultimative Rampensau sein wird.
Ok, dann bleibt mir da wohl auch erst mal nichts anderes übrig..

Was aber immer noch offen ist, ist die nicht funktionierende Option "Bevorzuge Schnitt vor dem Cut-Out-Schnittpunkt". Die hat definitiv mal gegriffen. Seit wann sie nicht mehr funktioniert, kann ich nicht sagen, aber ich habe jetzt in etlichen Schnitten festgestellt, dass immer am nachfolgenden Punkt geschnitten wird. Die Folge ist, dass jedes mal ein paar Bilder der Werbung aufblitzen. Das hatte ich in früher geschnittenen Sendungen nicht.


www.cypheros.de