Frage von Marcus Blomenkamp:Hallo zusammen.
Kann mir jemand sagen, wie ich mit gängigen Programmen unter Linux von
meiner TV/Grabber-Karte ein Interlace-Videosignal auch als solches
speichern kann?
Auf Deutsch: ;)
Ich will alte VHS-Aufnahmen zu DVD/SVCD konformem MPEG2 Video kodieren und
dabei die Halbbildrate beibehalten, sprich nicht zu 25fps Vollbildern
deinterlacen.
MPlayer, XawTv und FFMpeg habe ich bereits installiert. Leider habe ich
keine Kommanozeilen-Variante mit 'ffmpeg' und 'mencoder' gefunden, die mir
augenscheinlich korrektes ---*576i MPEG2 Video liefert.
Hat jemand heisse Tipps für mich?
Hardware: VHS-VCR über FBAS an Technisat Mediafocus Karte, Xp2700
Gruss, Marcus
Antwort von Andreas Wiencke:
Hallo,
> Auf Deutsch: ;)
> Ich will alte VHS-Aufnahmen zu DVD/SVCD konformem MPEG2 Video kodieren und
> dabei die Halbbildrate beibehalten, sprich nicht zu 25fps Vollbildern
> deinterlacen.
Wenn ich Dich also richtig verstehe, möchtest Du ein Mpeg2-Video erstellen,
daß mit 50fps läuft und dabei statt der vollen 768 Pixel Höhe (;PAL) 384
Pixel Höhe (;PAL / 2) hat, wobei 2 aufeinanderfolgende Bilder jeweils 2
Halbbilder sind (;Bewegung der Objekte zwischen 2 Einzelbildern im
erstellten Stream also mit Zeitversatz 0.02 Sekunden).
Ich bin für mich zu dem Schluß gekommen, daß diese mit ffmpeg nicht möglich
ist. Ich mußte darum selber ein Programm schreiben, daß einen mit ffmpeg
erstellten Film in Einzelbildern einliest und ein Vollbild (;mit Kammeffekt)
in 2 Halbbilder aufspaltet (;mit halber Höhe, logisch). Diese Einzelbilder
schreibe ich auf Platte und füge diese mittels ffmpeg und der Option
"-r 50" zu einem Video zusammen.
Das ist umständlich und dauert lange, aber etwas anderes ist mir leider
nicht eingefallen. Sicherlich gibt es Möglichkeiten durch patchen des
Framegrabber-Treibers und/oder ffmpeg eine elegantere Lösung zu schaffen,
dafür hatte ich aber keine Zeit ...
Andreas.
Antwort von Marcus Blomenkamp:
Andreas Wiencke wrote:
>
> Hallo,
>
> Wenn ich Dich also richtig verstehe, möchtest Du ein Mpeg2-Video
> erstellen, daß mit 50fps läuft und dabei statt der vollen 768 Pixel Höhe
> (;PAL) 384 Pixel Höhe (;PAL / 2) hat, wobei 2 aufeinanderfolgende Bilder
> jeweils 2 Halbbilder sind (;Bewegung der Objekte zwischen 2 Einzelbildern
> im erstellten Stream also mit Zeitversatz 0.02 Sekunden).
Moin,
ja wir liegen da schon sehr nah beieinander. Den Unterschied sehe ich im
wesentlichen darin, dass du 25 einzelne interlaced Frames gecaptured hast,
dann daraus 50 progressive Felder halber Höhe extrahiert hast und das dann
als Video mit 50 progressiven Frames pro Sekunde interpretierst und
speicherst, wohingegen ich am liebsten direkt die einzelnen 50 Felder
gegrabbt hätte.
Dieses Material will ich aber nicht als 50fps progressive mit manuell auf
4:3 gesetzem Seitenverhältnis kodieren und auf DVD packen sondern wieder
mit Standard-PAL Eigenschaften (;50 halbe) zu MPEG2 kodieren, damit der
DVD-Player es schick auf dem Fernseher darstellt.
Da fällt mir ein, dass MPlayer das Aufsplitten eines Frames in zwei temporal
folgende Felder unterstützt, also deine Funktion bereits in MPlayer
verfügbar ist. Das würde mir ja das Zwischenspeichern ersparen. Allerdings
muss ich nun mal schauen, ob MPlayer daraus nun auch ein Interlaced MPEG
machen kann...
Auf jeden Fall danke für die Anregung, Marcus
Antwort von Andre Beck:
Marcus Blomenkamp
writes:
>
> Kann mir jemand sagen, wie ich mit gängigen Programmen unter Linux von
> meiner TV/Grabber-Karte ein Interlace-Videosignal auch als solches
> speichern kann?
Indem Du beim Capture entweder unkomprimiert, verlustlos komprimiert
oder verlustbehaftet komprimiert mit einem Codec, der Interlace-aware
arbeitet, aufzeichnest. Ersteres wäre z.B. YV12, letzteres MJPEG.
Guck Dir mal Cinelerra an. Alternativ streamer oder lavrec (;aus
mjpegtools).
> Auf Deutsch: ;)
Wieso, war was unverständlich? ;)
> Ich will alte VHS-Aufnahmen zu DVD/SVCD konformem MPEG2 Video kodieren und
> dabei die Halbbildrate beibehalten, sprich nicht zu 25fps Vollbildern
> deinterlacen.
Äußerst sinnvolle Idee.
> MPlayer, XawTv und FFMpeg habe ich bereits installiert. Leider habe ich
> keine Kommanozeilen-Variante mit 'ffmpeg' und 'mencoder' gefunden, die mir
> augenscheinlich korrektes ---*576i MPEG2 Video liefert.
Naja, zumindest ffmpeg und mencoder sind wohl wenigstens partiell von
der DivX-Seuche mitbeeinflusst, da verwundert das wenig. Aber mencoder
kann z.B. direkt von v4l grabben und auch als YUV4MPEG2 speichern,
was man für mpeg2enc sowieso braucht. Ich bevorzuge aber wie gesagt
YV12 zusammen mit PCM im QT-Container, das kann man mit Cinelerra
capturen, bearbeiten und mit lav2yuv schön in mpeg2enc verfrachten.
Kompromisslose Toolchain, Platte >= 160GB wünschenswert.
> Hat jemand heisse Tipps für mich?
Achso, bei mpeg2enc das "-I 1" nicht vergessen und die korrekte Field
Order übergeben (;"-z b|t").
> Hardware: VHS-VCR über FBAS an Technisat Mediafocus Karte, Xp2700
Dann wünscht man Dir wohl TBC¹ und Material, das stabile Field Order
aufweist. Ansonsten hast Du ein Jammertal vor Dir...
¹) Time Base Corrector - nein, das ist keine Krankheit ;)
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Frank Albrecht II:
Andre Beck wrote:
> Marcus Blomenkamp writes:
>> Kann mir jemand sagen, wie ich mit gängigen Programmen unter Linux von
>> meiner TV/Grabber-Karte ein Interlace-Videosignal auch als solches
>> speichern kann?
> Indem Du beim Capture entweder unkomprimiert, verlustlos komprimiert
> oder verlustbehaftet komprimiert mit einem Codec, der Interlace-aware
> arbeitet, aufzeichnest. Ersteres wäre z.B. YV12, letzteres MJPEG.
> Guck Dir mal Cinelerra an. Alternativ streamer oder lavrec (;aus
> mjpegtools).
Hm. Ich bin bereits häufiger darüber gefallen:
/------------------------------------------------------
streamer -t 150000 -i S-Video -n pal -r 25 -s 720x576
-o movie.yuv -f 4mpeg -F stereo -O movie.wav -R 48000 -p 5 -b 64
yuvdenoise -t2 -b 3,1,710,570-F3 -q6 -R0 -N1.0 -D10 -Khi-res -41 -21 -r16 -c -P -s -b9000
-o movie.m2v 2>&1 | tee mpeg2enc.log
INFO: [mpeg2enc] Selecting DVD output profile
WARN: [mpeg2enc] Unknown input interlacing; assuming progressive.
INFO: [mpeg2enc] Progressive input - selecting progressive encoding.
INFO: [mpeg2enc] Encoding MPEG-2 video to movie.m2v
INFO: [mpeg2enc] Horizontal size: 720 pel
INFO: [mpeg2enc] Vertical size: 576 pel
INFO: [mpeg2enc] Bitrate: 9000 KBit/s
INFO: [mpeg2enc] Quality factor: 6 (;Quantisation = 6)
INFO: [mpeg2enc] Field order for input: none/progressive
INFO: [mpeg2enc] Sequence unlimited length
INFO: [mpeg2enc] Search radius: 16
INFO: [mpeg2enc] GOP SIZE RANGE 9 TO 15 (;all GOPs closed)
INFO: [mpeg2enc] Progressive format frames = 1
INFO: [mpeg2enc] Setting hi-res intra Quantisation matrix
INFO: [mpeg2enc] Buffering 33 frames
---------------------------------------------------------
Parameter -I1 wird abgewiesen, bei Fieldorderwechsel kein
Unterschied(;wie auch, wenn progressive?).
Aber warum? Habe ich da etwas falsch eingestellt oder ein
Verständnisproblem? Oder liegt es an meiner BT878-Karte?
Oder gar an dem nicht vorhandenen mov-Container?
Danke für Antworten...
--
Gruß,
Frank Albrecht II
Antwort von Andre Beck:
Frank Albrecht II writes:
>
> Hm. Ich bin bereits häufiger darüber gefallen:
> /------------------------------------------------------
> streamer -t 150000 -i S-Video -n pal -r 25 -s 720x576
> -o movie.yuv -f 4mpeg -F stereo -O movie.wav -R 48000 -p 5 -b 64
>
> yuvdenoise -t2 -b 3,1,710,570> -F3 -q6 -R0 -N1.0 -D10 -Khi-res -41 -21 -r16 -c -P -s -b9000
> -o movie.m2v 2>&1 | tee mpeg2enc.log
>
> INFO: [mpeg2enc] Selecting DVD output profile
> WARN: [mpeg2enc] Unknown input interlacing; assuming progressive.
Soweit klar, da oben ist keine Angabe zum Interlace, in YUV4MPEG2 wird
es AFAIK auch nicht signalisiert, folglich wird ein Default angenommen.
Allerdings ist Progressive kein wirklich gutes Default, weil es ur-
sprünglich interlacetes Material verhunzt, während Interlace auch bei
ursprünglich progressivem Material nicht stört (;abgesehen von höheren
Bitratenanforderungen). Ein "-I 1" sollte aber helfen.
> Parameter -I1 wird abgewiesen, bei Fieldorderwechsel kein
> Unterschied(;wie auch, wenn progressive?).
Ähm, was heißt "wird abgewiesen"? Vielleicht umbenannt? "Meine" Version
hier sagt bei "mpeg2enc --help" immer noch
--interlace-mode|-I num
Sets MPEG 2 motion estimation and encoding modes:
0 = Progressive (;non-interlaced)(;Movies)
1 = Interlaced source material (;video)
> Aber warum? Habe ich da etwas falsch eingestellt oder ein
> Verständnisproblem? Oder liegt es an meiner BT878-Karte?
> Oder gar an dem nicht vorhandenen mov-Container?
Da mpeg2enc nur ein Inputformat beherrscht - eben YUV4MPEG(;2) - ist
weder die Karte wichtig, noch irgendein Container, der vorher mal
die Daten enthielt. Sie landen letztlich bei mpeg2enc immer im selben
Format, das (;AFAIK) selbst auch kein Interlace signalisieren kann.
Folglich *muss* man mpeg2enc mitteilen, welchen Charakter das Material
hat, und dazu dient der Schalter "-I". Ich habe mir angewöhnt, den
immer zu übergeben, weil ich mich auf kein Default verlassen will,
bisher hat das auch funktioniert.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Frank Albrecht II:
Ups, hier steht noch etwas aus:
Andre Beck wrote:
> Frank Albrecht II writes:
>>
>> Hm. Ich bin bereits häufiger darüber gefallen:
>> /------------------------------------------------------
[...] mpeg2enc mit -I1
>> Parameter -I1 wird abgewiesen, bei Fieldorderwechsel kein
>> Unterschied(;wie auch, wenn progressive?).
> Ähm, was heißt "wird abgewiesen"? Vielleicht umbenannt? "Meine" Version
> hier sagt bei "mpeg2enc --help" immer noch
INFO: [mpeg2enc] Selecting DVD output profile
WARN: [mpeg2enc] Unknown input interlacing; assuming progressive.
WARN: [mpeg2enc] Interlaced encoding selected with progressive input!
WARN: [mpeg2enc] (;This will damage the chroma channels.)
Wenn man mit z.B glav die einzelnen Frames anschaut, sind es
eindeutig Halbbilder, auch die zweier nachfolgender Szenen in
einem.
> --interlace-mode|-I num
Ist noch was dazugekommen:
Setting 0 encodes frame-by-frame with support for interlaced
video turned off, and specifies that progressive chroma
subsampling has been used. Setting 1 encodes frame-by-frame
with interlace-adapted motion compensation and block
encoding, and specifies that interlaced chroma subsampling
has been used. Setting 2 encodes interlaced material
field-by-field, which will produce more accurate results for
highly textured interlaced material with lots of motion, at
the expense of generally less efficiency.
Mit "2" gibt es bei mir schöne bunte, durcheinandergewürfelte
Klötzchen im mpeg-file ;-)
> Folglich *muss* man mpeg2enc mitteilen, welchen Charakter
> das Material hat, und dazu dient der Schalter "-I". Ich habe
> mir angewöhnt, den immer zu übergeben, weil ich mich auf
> kein Default verlassen will,
Das dachte ich eben auch. Hm.
--
Gruß,
Frank Albrecht II
Antwort von Andre Beck:
Frank Albrecht II writes:
> Andre Beck wrote:
>
> > Ähm, was heißt "wird abgewiesen"? Vielleicht umbenannt? "Meine" Version
> > hier sagt bei "mpeg2enc --help" immer noch
>
> INFO: [mpeg2enc] Selecting DVD output profile
> WARN: [mpeg2enc] Unknown input interlacing; assuming progressive.
Irgendwie liest sich das, als könnte YUV4MPEG2 mittlerweile auch ein
Interlaced-Flag mitübergeben. Wenn man sich mal ppmtoy4m(;1) durchliest,
wird das offenbar:
-I x Set interlacing mode, used to interpret the PPM image(;s), and also
encoded in output stream. (;default: 'p')
p - progressive, non-interlaced
t - top/upper-field-first interlaced
b - bottom/lower-field-first interlaced
> WARN: [mpeg2enc] Interlaced encoding selected with progressive input!
> WARN: [mpeg2enc] (;This will damage the chroma channels.)
Puh. Schätzungsweise kann man das getrost ignorieren, weil die
Assumption, der Input sein progressiv, ja bekannt falsch ist. Was
da selbst bei progressivem Input die chroma channels damagen soll,
ist mir aber ein Rätsel. Bestenfalls ist die Endqualität schlechter,
als sie sein könnte, oder die Bitrate höher, oder beides.
> Wenn man mit z.B glav die einzelnen Frames anschaut, sind es
> eindeutig Halbbilder, auch die zweier nachfolgender Szenen in
> einem.
Ja, nur kann mpeg2enc die Frames nicht anschauen, um abzuschätzen, ob
sie interlaced sind (;TMPGEnc versucht das, haut aber auch gern daneben).
Und wenn die bei Dir von streamer kommen, dann fehlt dessen Ausgabemodul
scheinbar das Feature, sie gleich als interlaced zu taggen.
> > --interlace-mode|-I num
>
> Ist noch was dazugekommen:
>
> [...] Setting 2 encodes interlaced material
> field-by-field, which will produce more accurate results for
> highly textured interlaced material with lots of motion, at
> the expense of generally less efficiency.
In der Manpage steht das schon lange. Interessanterweise taucht es bei
"mpeg2enc -h" nicht (;mehr?) auf, andererseits sind dort Optionen hinzu-
gekommen, die nicht in der Manpage stehen (;etwa field order).
> Mit "2" gibt es bei mir schöne bunte, durcheinandergewürfelte
> Klötzchen im mpeg-file ;-)
Ich habe field encoding for field pictures noch nie probiert, weil
das Gerücht geht, es wäre mit vielen Abspielern nicht sehr weit her
mit der Kompatibilität. Weiß nicht, ob das im aktuellen mpeg2enc
überhaupt noch funktioniert (;oder jemals funktioniert hat).
> > Folglich *muss* man mpeg2enc mitteilen, welchen Charakter
> > das Material hat, und dazu dient der Schalter "-I". Ich habe
> > mir angewöhnt, den immer zu übergeben, weil ich mich auf
> > kein Default verlassen will,
>
> Das dachte ich eben auch. Hm.
Sieht aus, als würde -I inzwischen nur noch als "wie ist es zu encoden"
interpretiert, weil man einen out of band channel hat, in dem über-
mittelt werden kann, wie der Input aussieht. Womöglich funktioniert der
auch in Zusammenhang mit lavrec etc. Nur rätselhaft, warum ausgerechnet
lav2yuv (;das ja auch einige Fremdformate lesen kann) dafür keinen
Schalter hat, mit dem man forcieren könnte, dass der Input als interlaced
(;und ob TFF oder BFF) aufzufassen ist.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Frank Albrecht II:
Andre Beck wrote:
> Frank Albrecht II writes:
>> Andre Beck wrote:
[...]
> Irgendwie liest sich das, als könnte YUV4MPEG2 mittlerweile auch ein
> Interlaced-Flag mitübergeben. Wenn man sich mal ppmtoy4m(;1) durchliest,
> wird das offenbar:
[...]
>> WARN: [mpeg2enc] Interlaced encoding selected with progressive input!
>> WARN: [mpeg2enc] (;This will damage the chroma channels.)
> Puh. Schätzungsweise kann man das getrost ignorieren, weil
> die Assumption, der Input sein progressiv, ja bekannt
> falsch ist. Was da selbst bei progressivem Input die
> chroma channels damagen soll, ist mir aber ein Rätsel.
> Bestenfalls ist die Endqualität schlechter, als sie sein
> könnte, oder die Bitrate höher, oder beides.
Aus der ML:
/-------------------------------------------------------------
You should not need to use '-I 0' with the current mpeg2enc
(;>= 1.6.2); it should do the "right thing", based on the
I-tag in the input stream. (;And if it doesn't, I want to
know, because I am triply-responsible for that tiny piece of
the code (;given all the debate I caused on this list).)
Ich sehe zwischen -I0 und -I1 keinen Unterschied, auch die
Dateigröße des mpg2 ist gleich(;ich Esel habe leider kein diff
gemacht, vielleicht wiederhole ich das Experiment nochmal).
-------------------------------------------------------------
Vielleicht ist einfach nur die Ausgabemeldung
falsch/irreführend. Mpeg2enc liest offenbar dieses Flag, und
handelt danach, ohne dass es sich übersteuern ließe.
--
Gruß,
Frank Albrecht II
Antwort von Andre Beck:
Frank Albrecht II writes:
> Andre Beck wrote:
> > Frank Albrecht II writes:
> >> Andre Beck wrote:
>
> [...]
> > Irgendwie liest sich das, als könnte YUV4MPEG2 mittlerweile auch ein
> > Interlaced-Flag mitübergeben. Wenn man sich mal ppmtoy4m(;1) durchliest,
> > wird das offenbar:
>
> [...]
> >> WARN: [mpeg2enc] Interlaced encoding selected with progressive input!
> >> WARN: [mpeg2enc] (;This will damage the chroma channels.)
>
> > Puh. Schätzungsweise kann man das getrost ignorieren, weil
> > die Assumption, der Input sein progressiv, ja bekannt
> > falsch ist. Was da selbst bei progressivem Input die
> > chroma channels damagen soll, ist mir aber ein Rätsel.
> > Bestenfalls ist die Endqualität schlechter, als sie sein
> > könnte, oder die Bitrate höher, oder beides.
>
> Aus der ML:
> /-------------------------------------------------------------
> You should not need to use '-I 0' with the current mpeg2enc
> (;>= 1.6.2); it should do the "right thing", based on the
> I-tag in the input stream. (;And if it doesn't, I want to
> know, because I am triply-responsible for that tiny piece of
> the code (;given all the debate I caused on this list).)
Ist ja schön und gut, wenn das I-tag vorhanden und korrekt ist. Nur kann
man das nicht voraussetzen, weil weder der Grabber noch irgendwelche
anderen Automatismen wirklich *wissen*, ob etwas interlaced ist oder
nicht. Das kann man bestenfalls *versuchen*, mit fortgeschrittenen
Mitteln der Bildverarbeitung zu analysieren, oder (;und das ist vorzu-
ziehen) ein Mensch legt das fest, nachdem er das Material eingehend
studiert hat. Deswegen muss man das Flag selbst setzen, rücksetzen
und beim Encoding überschreiben können.
> Vielleicht ist einfach nur die Ausgabemeldung falsch/irreführend.
Nene, wenn da jetzt dieses I-tag ist (;was es offensichtlich ist), dann
ist die Ausschrift relevant und man sollte sehr darauf achten, dass
einem dieser Automatismus nicht ungewollt was kaputt macht, weil er
danebenhaut. Insbesondere sollte er das *Fehlen* des Tags immer als
Interlaced interpretieren, nicht als Progressiv. In dubio pro reo -
wenn unbekannt, dann besser Interlace annehmen.
> Mpeg2enc liest offenbar dieses Flag, und
> handelt danach, ohne dass es sich übersteuern ließe.
Ähm, es ließ sich doch überstimmen. Es hat nur rumgemault, dass es für
den Fall, dass dieses Überstimmen falsch war, vielleicht mehr Schaden
anrichtet als man haben möchte - aber solange ich das überstimmen kann,
ist IMO noch alles in Ordnung. Ideal wäre wie gesagt, wenn man das Flag
gezielt setzen könnte, etwa bei lav2yuv. Da lav2yuv nun mal auch
YV12-MOVs transcodieren kann und man einem YV12-MOV beim besten Willen
nicht ansehen kann, was es ist (;bei einem DV ist BFF-Interlaced ein
ziemlich wahrscheinlicher Guess, bei MJPEG im Fieldmode ist zumindest
Interlaced wahrscheinlich, die Fieldorder aber schon fraglich), wären
da Schalter zum Override sehr angemessen.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Heiko Nocon:
Andre Beck wrote:
>Das kann man bestenfalls *versuchen*, mit fortgeschrittenen
>Mitteln der Bildverarbeitung zu analysieren, oder (;und das ist vorzu-
>ziehen) ein Mensch legt das fest, nachdem er das Material eingehend
>studiert hat
Man kann mit ziemlich primitiven Mitteln mindestens so zuverlässig wie
ein Mensch erkennen, ob es sich um interlaced Material handelt und
welche Fieldorder vorliegt.
Das bissel Algorithmus, was dazu nötig ist, würde ich noch nicht als
"fortgeschrittenes Mittel der Bildverarbeitung" bezeichnen wollen. Da
braucht man ja noch nichtmal Gleitkommazahlen für. ;o)
Antwort von Andre Beck:
Heiko Nocon writes:
> Andre Beck wrote:
>
> >Das kann man bestenfalls *versuchen*, mit fortgeschrittenen
> >Mitteln der Bildverarbeitung zu analysieren, oder (;und das ist vorzu-
> >ziehen) ein Mensch legt das fest, nachdem er das Material eingehend
> >studiert hat
>
> Man kann mit ziemlich primitiven Mitteln mindestens so zuverlässig wie
> ein Mensch erkennen, ob es sich um interlaced Material handelt und
> welche Fieldorder vorliegt.
Kommt halt drauf an, was man als "ziemlich primitive Mittel" bezeichnet.
Mir ist noch keine zuverlässige Implementation begegnet, aber ich habe
auch nicht wirklich danach gesucht.
> Das bissel Algorithmus, was dazu nötig ist, würde ich noch nicht als
> "fortgeschrittenes Mittel der Bildverarbeitung" bezeichnen wollen. Da
> braucht man ja noch nichtmal Gleitkommazahlen für. ;o)
Sicher werden Leute, die sich mit *wirklich* fortgeschrittener Bildver-
arbeitung beschäftigen, das als Peanuts betrachten. Aber es ist nicht
völlig trivial. Kannst Du mal andeuten, wie Du es machst?
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Heiko Nocon:
Andre Beck wrote:
>Kannst Du mal andeuten, wie Du es machst?
Ich kann noch etwas mehr machen. Ich kann dir nämlich den Quelltext
meines VD-"Repro"-Filters schicken.
(;Gestandene C-Programmierer wie du werden sicher sehr schnell merken,
daß C nicht unbedingt meine bevorzugte Programmiersprache ist. Also
nicht lachen ;o)
Aber egal, der Algorithmus ist das Entscheidende und der ist wirklich
sehr primitiv und trotzdem ziemlich zuverlässig.
Auch wenn er in diesem konkreten Fall nichtmal dazu dient, tatsächlich
interlaced Video zu erkennen, sondern dazu, künstlich "verinterlacestes"
progressives Material, wie es uns die TV- und Rechteverweser-Mafia
anbietet, wieder korrekt zusammenzubauen.
Wenn du es also haben willst->PM.
