Beiträge von Wilbert

  • Braucht man die colormatrix.dll?

    Zitat

    Naja, DVB-Dateien sollten als Transportstream an sich keinen Header haben.

    Ich dachte das mpeg2 streams (auch mpeg2 in ts) immer ein header hatte.

    Zitat

    Das wäre aber nicht so toll. Wenn die Art und Weise, wie die YUV->RGB Umwandlung stattfinden müßte, von Headerinformationen abhängt, und wenn diese nach dem Import in dvd2avi verloren gehen, dann kann die colormatrix.dll ja auch auch keine ideale Lösung sein. Wenn nämlich dvd2avi zufällig genau so decodiert, wie es lt.

    dvd2avi decodiert nicht. Aber du bist richtig, wenn das mpeg2 stream bt.601 coefficients brauchte, und er encodiert das zu XviD/DivX, sollte ihr keine colormatrix gebrauchen.

  • Braucht man die colormatrix.dll?

    Zitat


    Ich hab mal nach der colormatrix.dll gesucht, aber nicht viel gefunden, siehe aber hier.

    Meine Fragen:
    - Haben DVD2AVI/DGIndex wirklich einen Bug, oder verhalten sie sich lediglich anders (vielleicht sogar richtiger) als mpeg2-Decoder von Playern? Siehe auch hier.

    Es ist nicht ein bug. Es gibt mehrfache weisen, eine YUV->RGB umwandlung zu tun. Die weise fur eine mpeg2 stream ist gespeichert (stored) in der header. Wenn du die mpeg2 in dvd2avi importiert ist die info verloren gegangen.

    Zitat


    - Ich habe von der colormatrix in Verbindung mit DVD's gelesen. Betrifft das auch andere mpeg2-Quellen, z.B. DVB?

    Um dieser zu kontrolieren (konnte vom dvb stream abhangen, keine ahnung ...) sollen sie die stream in gspot offnen um die gebrauchte koeffizienten zu lesen.

  • suche neue doc writers

    Zitat

    Wilbert: weisst du, was aus jernst und dolemite geworden ist?

    I know jernst stopped AVSEdit development (and stuff for windows in general). He's working solely on linux now. He told me he's waiting for avs 3.0 :)

    I don't know about dolemite. I try to contact him several weeks ago, but he never responsed. Nor did I see him posting lately on one of the forums.

    about CVS: I think the easiest is to copy the wiki changes to cvs. Of course I (or WarpEnterprises) can mail anyone the html pages (so you don't need to fork with cvs itself).

  • SAA 7134 und Auflösung

    Zitat


    okay, dann ist dein 720er dasjenige welche mit dem richtigen PAR
    und das 704 hat ein falsches PAR

    Er ist keine richtige oder falsche PAR. Ja, ich weiss was er meinst. Aber, er sollte es richtig sagen:

    aktieve capture fenster = PAL fenster (aktieve PAL teil) oder != PAL fenster.

    Zitat

    Ist ja durchaus einsichtig, wenn man auf die Balken schaut, die sowohl bei 720 als auch bei 704 vorhanden sind. Dann muss ja, von korrekter Breite der Balken ausgehend, die 704 falsch sein.

    Dass ist nicht immer richtig. 704 mit aktieve fenster 52 kann auch schwarze balken haben (sie vorhergehende post).

    Btw: wenn 720 balken hast, hast 704 das auch.

  • SAA 7134 und Auflösung

    Das ist richtig.

    Wenn die aktieve capture fenster 53.333 ist, dann hattest du scharze pixelbalken (> 16 pixeln).

    Aber wenn die aktieve capture fenster 52.15 ist, du kannst auch scharze pixelbalken haben:

    * die chip/treiber captured mit ein offset (transl?); mit ein "verschoben" fenster

    * die broadcasting (transl?) hatte selbst scharze pixelbalken (zum beispiel ein resultat of NTSC->PAL convertierung)

    http://www.doom9.org/index.html?/capture/sizes_newbies.html :


    Probiere mal ein taugliche (suitable) broadcast.

    Oder besser, wie incredible gesagt habe, probiere mal die test selbst zu tun:

    http://www.doom9.org/index.html?/capture/capture_window.html

  • Auflösungen

    Zitat

    Mal so, auf die Schnelle:
    Unter 5.6 (examples): "So, remove 18 black pixels of your 702x576 cap. " muß richtig 720 heißen.

    Ich weiss es :) Ich solle das korrigieren die nachste version.

    nvbmenu_register("postmenu_122239", true); @ incredible, vbmenu_register("postmenu_122239", true
    13.5 Mhz * 52.03µs = ca. 702px Active capture Area [in dvd pixels]
    13.5 Mhz * 51.56µs = ca 696px !!! Active capture Area [in dvd pixels]

    Zitat

    Die BT8x8 digitalisieren nicht mit 13,5 MHz; die Endauflösungen werden über einen "scaler" und ein "Fenster" erzeugt.

    from same page as Der Karl linked: "for bt8x8/cx2388x cards for example: NTSC: 28.64 MHz, and PAL: 35.48 MHz"

  • suche neue doc writers

    Zitat

    (Where shall we start - docs from the installer, based on the changelog, or docs from the website? Are there central locations for organizing the work?)

    There are two central locations :) The one at sourceforge, and the one at avisynth.org. If I update the english docs I do them both at the same time, but sometimes people update avisynth.org and I copy it to sourceforge (or the other way around).

    If you browse the CVS (which is not possible at the moment), you can easily see what is changed/updated after the release of AviSynth v2.54. Those changes/updates should be translated (and copied to sourceforge and avisynth.org).

    So, I suggest you wait until you can browse the CVS again. After that I can add one of you (or both) to sourceforge, so you can also commit your stuff there.

    Btw, if you look at the "recent changes" at avisynth.org:

    http://www.avisynth.org/index.php?page=RecentChanges&full=1

    you need all the changes which are newer than this item:

    "(2004.01.16 06:54:26) (history) ChangeList Deutsch . . . . Arlsair [Typo]"

    So you can also start there, if you can't wait :) But, make sure to copy the changes to sourceforge at the same time.

    I hope this is enough info to get you started :)

  • suche neue doc writers

    Arlsair hatte keine zeit mehr um die docs zu ubersetzen (translate) :( Wir suchen neue leute die zeit haben um die doc zu ubersetzen (avisynth.org und sourceforge).

    Die deutsche ubersetzung ist gut and immer aktuell (das heist bis zu v2.54). I hoffe, dass dieses so bleibt in zukunft!

  • Script für neuen Analog Capture Guide v4

    I will read the german part of your post tomorrow, it's too late for that now.

    Zitat

    In case of a capture chip based correct internal µs related resizing in FitCD, ... that would mean you would have to add a "used Capturecard chip" Gadget, ... right?

    Sort of. We just need to add an active capture window box. That's all.

    Zitat

    AIK there's still a bug in that old FitCD release related to the correct NTSC 528/544 Target PAR, but maybe Im wrong.

    Oh, I don't know. I will ask shh about this.

    Zitat

    Und jetzt kommt eben das was mich stutzig macht: Wenn ich z.B. mit einer 53.3333 µs arbeitenden Karte auf 704 beim capturen gehe, würde sie dann auch jene 9+...+9 lediglich auf 704 runter resizen und nicht croppen??? Denn dann wäre dies eben der Knackpunkt. Hmmmm .....


    Remember a cap at 720x576 or 704x576 is just a scaling of each other.

    I will adjust example 1 in section 5.6:

    1) Say you want to make a DivX/XviD (PAL). Full PAL TV on a PC gives 52 µs * 14.7692 MHz = 768 pixels, ending with 768x576. Your "SAA7108, Nvidia with a WDM driver" has a capture window of 53.33 µs. So, how many PC sized pixels fit in the capture window? 53.33 µs * 14.7692 MHz = 788 pixels. So you have two options here (however, if you can't capture at arbitrary sizes you only have one option):

    a) Cap pixels that are at or close at the target size. That's not always possible.

    b) Capping at another resolution and resize to the correct pixel size afterwards. If you want that, cap high, say 704x576.
    However, your card caps only 53.33 µs, so you need less pixels to make up the difference with the 52 µs a PC needs for correct AR. How many?
    (52 / 53.333) * 704 = 686 in total.

    So, remove 704-686.4=17.6 ~ 18 black pixels of your 704x576 cap
    [*]. You now have 52 µs of info in 704 pixels. Resize the resulting 686x576 to 768x576 or a scaling of it.


    [*] If you would have capped at 720x576, you get (52 / 53.333) * 720 = 702 and you have to remove 720-702=18 black pixels of your 720x576 cap. Resize the resulting 702x576 to 768x576 or a scaling of it.

    I hope it's a bit clear ?

  • Doom's Analogue Capture Guide v4 fertig!

    Zitat


    Are you shure this is correct? As a 720 width PAL capture would have to be resized using a generic PAR (45/48). Better would be resizing or even capturing to/at 704.

    Wouldnt that direct non ITU compilant capturing 720 case screw up all the past discussions related to this?

    Many of those discussion about generic par are not applicable to most cap card / drivers. Let me explain this:

    1) As we tried to explain in the guide (I hope you will take the time to read it), many capture card / drivers don't use an active capture window of 52 µs (pal)). Just look at the table in section 5.2 and look with drivers use 52 µs for PAL and 52.666 µs for NTSC. Not many :)

    2) Note, the active capture window is independent of the capture size. In other words, capping at different sizes implies that the resulting clips are always scalings of each other. That means even if you card/driver caps at 52 µs, you can't use this 45/48 generic PAR for other cap sizes (other than 720x576), because they are scaling of each other. If your active cap window is 52 µs you always have to resize to a 4:3 format for DivX/XviD, no matter what capture size you used.

    In section 10 you can find out how to determine the active capture window for your card/driver combo.

    This implies that we avoided the use of PAR in the main section, because the PAR also depends on the active capture window, and not only on the capture size. In section 16 we give some examples in case someone wants to use PAR.

    I hope this is a bit clear.

    Zitat

    Seems to be a lot of work for us to bring into German language.

    Yeah, sorry about that :)

  • Doom's Analogue Capture Guide v4 fertig!

    Die neue version of die analogue capture guide is fertig! Dieses mal viel Material wird addiert und neu geschrieben. Der guide kann hier gefunden werden:
    http://www.doom9.org/index.html?/capture/start.html

    Die changelog ist sehr groß. Eine kleine Zusammenfassung:

    * A neues There's a new einleitender abschnitt (introductiory section) uber analogen video.

    * Da ist ein abschnitt wie stellen Sie das aktive sicherung fenster fest und wie man das fur resizing (tr ?) bestimmen verwendet.

    * Die resizing abschnitt ist splitted oben in einem Teil fur neue und fur benutzer mit vorkenntnissen. Das letzte schließt informationen uber musterstuck, Nyquist und qualitat der scalers der verschiedenen capture (tr ?) karten ein.

    * Der VirtualDub nachbearbeitung abschnitt ist durchgefuhrt worden (deinterlacing, color adjustment, etc.).

    * Anweisungen, wie man Klicken und Kratzer (clicks and scratches) sind addiert.

    * und viel mehr ...

    Diese version ist geschreiben durch trevlac, arachnotron, i4004 und mich. I hoffe Sie mogen es auch, und das es nutzlich ist.


    btw, I probably messed up the translation here and there, but I hope it's understandable :)

  • Gesichter noch zu unscharf

    Zitat

    SeparateFields()
    ConvertToYV12(interlaced=true)
    deen("a3d",3,4,1,4)
    Weave()
    ConvertbackToYUY2()

    Drei probleme:

    1) ConvertToYV12(interlaced=true) braucht ein interlaced source, keine progressive.

    2) deen("a3d",3,4,1,4) ist auch temporal. Du brauchst ein spatial filter hier.

    3) Convertbacktoyuy2 nimmt an das der source YUY2->RGB convertiert ist. Aber die source ist YV12 hier.

    Correct script:

    ConvertToYV12(interlaced=true)
    SeparateFields()
    deen("a2d",3,4,1,4)
    Weave()
    ConvertToYUY2(interlaced=true)

    oder

    ConvertToYV12(interlaced=true)
    SeparateFields()
    even = SelectEven(last).deen("a3d",3,4,1,4)
    odd = SelectOdd(last).deen("a3d",3,4,1,4)
    Interleave(even, odd)
    Weave()
    ConvertToYUY2(interlaced=true)