Fit2Disc v1.2.8

{ Abgetrennt aus Fit2Disk v1.2.8 aus dem News-Bereich - zisoft }

Zitat von shh

Im Grunde ist das fehleranfällige D2V-Parsing eh nicht nötig, weil bei installiertem DGDecode.dll + avisynth die frames via AVI-Interface geholt werden.

Musst du noch nicht mal.
Einfach die genutzte dgdecode.dll aufrufen und die Rückkgabe aus dem Befehl openMPEG2Source("Source.d2v") an einen Memorypointer mit folgeneder Struktur übergeben:

Structure VideoInfo 
 	width.long
 	height.long
 	fps_numerator.long
 	fps_denominator.long
 	num_frames.long
EndStructure

somit muss bei DgIndex d2v files lediglich die source AR als string ausgelsen werden. Was "alte" DVD2AVI Files angeht, tja, da muss eben noch der AR- VOB Parser her.

Neuron kann somit seine DgIndex d2v struktur ändern wie er will, es muss lediglich "Aspect_Ratio=X:X" als string auftauchen.

Die MPEG2Dec3.dll hat dieselbe API wie die dgdecode.dll (daher mein Tip), lediglich die AR müsste bei DVD2AVI d2v's noch im original VOB ge'parsed werden.

Ich wüsste aber keinen Grund warum man nicht komplett auf DgIndex und dessen resultierenden d2v's umsteigen sollte.

Zitat

Zurzeit hängt halt die Vorschaufkt auch noch an dem DGDecode.dll+avisynth+AVI-Interface, was ich auch anpassen müsste. (=> größere Änderungen)

Via SetDIBits geht das fix:

Procedure DisplayFrame(input_frame.l, input_imagehdl.l) 

  Structure myBITMAPINFO
	bmiHeader.BITMAPINFOHEADER
	bmiColors.RGBQUAD[1]
  EndStructure


  Global bmi.myBITMAPINFO, hBmp, ImgID2 
  Protected bmi.myBITMAPINFO , input_imagehdl;, hBmp 


  If source_width
	bmi\bmiHeader\biSize		= SizeOf(BITMAPINFOHEADER)
	bmi\bmiHeader\biWidth	   = source_width
	bmi\bmiHeader\biHeight	  = -source_height ; Flip the RGB Image !!! vertically!
	bmi\bmiHeader\biPlanes	  = 1
	bmi\bmiHeader\biBitCount	= 24
	bmi\bmiHeader\biCompression = #BI_RGB

	*rgb24 = getRGBFrame(input_frame)

	If *rgb24
	  hBmp = UseImage(videobmp)
	  hdc  = StartDrawing(ImageOutput())
	  SetDIBits_(hdc, hBmp, 0, source_height, *rgb24, bmi, #DIB_RGB_COLORS)
	  StopDrawing() 
	  SetGadgetState(input_imagehdl.l, hBmp)
	Else 
	EndIf 

  Else
	MessageRequester("Error!","The Videodata in the d2v contains NO width!?",0)
	ProcedureReturn #False
  EndIf 
  ProcedureReturn #True
EndProcedure

Den hdc erlange ich in Purebasic via StartDrawing(), geht aber in Delphi (meine mich zu erinnern, dass du darin programmierst) auch via API.

Mir ist da ein Bug was die PAR von 544 und 528 bei dir angeht aufgefallen:
Bei 720x576 als Source und 544 als Target wird von 720 DIREKT zu 544 resized, was imho falsch wäre.

720 gleicht 53,33333µs @ 13,5 Mhz
544 gleicht 53,72840µs @ 10,125 Mhz

53,3333/53,72840 = 0,99265

Aktive 720 (also 53,3333µs) innerhalb von 544 sind somit ...
544*0,99265 = 540!
Somit wäre 720x576 zu 540x576 + padding hin zu 544x576 richtig.

Bei 528 siehts "ähnlich" aus.

704 hat 52,14815µs
528 hat 52,14815µs --> passt also
Somit müsste direkt von 704x576 zu 528x576 hin resized werden.

Dein Ergebnis:

Zitat

BicubicResize(528,576,0,0.6,0,6,704,564)

Du versuchst also die "Höhe" via Cropping vorab zu kompensieren, was nicht nötig ist.

Erstmal, .... meine BugReports beziehen sich auf FitCD, Fit2Disc habe ich nicht. Hatte vergessen dies zu sagen.

Klar, temp-avs scripte sind weitaus flexibler, denn da kann es dir egal sein, was da wann, wie und wo für eine HulaHulaDecode.dll genutzt wird, um mpeg2source("") im script funktionieren zu lassen. Lediglich die ARs muss man im d2v als String parsen. - wenn das nicht mal irgendwann geändert wird - Und selbst dann wird ein "auf Nummer sicher"-Parsing der orig VOBs tricky sein, wenn nicht sodann da auch im d2v die Architektur geändert werden wird, WO der Pfand zum orig. VOB steht.

Zitat

Einer hat mir damals geschrieben, dass 544 UND 528 vom DVD-Player einfach auf 720 skaliert werden. Ich hätte halt doch mal wieder nach http://www.uwasa.fi/~f76998/video/conversion/ schaun müssen.

Moment, ... ganz so abwägig ist so ein "falsches" playback via SAP nicht.

Jukka Aho hat ja mit seiner Seite einen Meilenstein gesetzt, da er exact die analogen Standards hin zu digitalen Werten beschrieben hat und wie dies ausgerechnet wird - das ist uns ja klar.

Nur .... wenn schon Adobe hingeht und in ALL seinen EBV Programmen und AfterEffects mit generic PAR - was 720er DV/D1 Endgrößen angeht - rechnet, dann möchte ich nicht wissen, inwieweit sich da die Hardware von manchen SAPs (egal welche Marke) nicht an jene Specs hält!

Bedeutet: Man müsste mal ein Testchart-Playback eines 544 und 528 mpegs von einem SAP via Capturekarte einfangen und genau die "abgespielten" µs abmessen.
Also wie dies z.B. im Doom9 Captureguide für Capturekarten gilt.

Wenn meine SAA7134 also mit 704x576 bei 52.148µs digitalisiert und ich via angeschlossenem SAP GENAU den Bildinhalt des Testcharts eines 528x576 exact auf HD bekomme, inkl. dessen vollen activen 52.148µs, dann gibt der SAP 528x576 richtig wieder. Bei 544er Testcharts müssten sodann die activen 53.728µs auf 52.148µs "gecropped" auf HD ankommen.

Werde dies mal die Tage checken. Habe einen Mediencom und einen Cyberhome505 Player und bin gespannt, ob's da leckere Überraschungen geben wird.

Zitat von Shh

Einer hat mir damals geschrieben, dass 544 UND 528 vom DVD-Player einfach auf 720 skaliert werden.

Ansch nicht, ... 528 werden ansch. zur gleichen Breite hin entzerrt wie 544 auch! nicht 720!.
Habe einen Test gemacht

Playback via Cyberhome505:

Referenz ist ein 720 image in PAR1:1 für den Vergleich in Photoshop:

[Blockierte Grafik: http://img488.imageshack.us/img488/6562/720pure2jm.gif]

Habe die korrekt resized 544 gecaptured (7134er Chip, cinergy 1.4er Treiber = 52,14815µs
Und, passt (wie es auch sollte):

[Blockierte Grafik: http://img488.imageshack.us/img488/3939/5442jf.gif]

Hier die resultierenden 528!

[Blockierte Grafik: http://img488.imageshack.us/img488/8392/5287tt.gif]

Der CH505 geht sogar hin und zieht die 528x576 was in die Höhe *graus

Somit behandelt der Ch505 die 53,72840µs des 544er richtig, also nicht wie dir beschrieben wie die 53,333µs eines 720ers. Dennoch mus man nun die PAR von den 528 heausbekommen, ansch. "PAR_528 = PAR_544/(544/528)" nur wäre damit nicht der "Höhen-Verzug" mit einbezogen, das kann aber auch ein "bug" des CH505 sein.