| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
dominique 
Anmeldungsdatum: 10.08.2002
Beiträge: 187
  |
 Beitrag 20 - Verfasst am: Sa Dez 07, 2002 18:25 Titel: |
 |
|
[quote] | Zitat: | Zumindest mein Player hatte noch nie Probleme mit bff-Material (bis auf die Procoder-Field-Streams).
Es sollte also schon möglich sein, das auf den Playern hinzukriegen, die normalerweise auch bff akzeptieren. |
Hi,
die Fieldreihenfolge bei Field-Encoding ist von der Behandlung her wesentlich komplexer als bei Frame-Encoding. Liegt ein Frame mit 2 Fields vor, so muss der Player nur entscheiden, ob er Zeile 1,3,5... oder Zeile 2,4,5... zuerst darstellen soll.
Bei Fieldencoding gibt es aber vereinfacht ausgedrückt so etwas wie 50 einzelne Frames (bei PAL) pro Sekunde. Bei Bottom Field First müsste der Player dann die Frames in er Reihenfolge 2,1,4,3,6,5.... statt 1,2,3,4,5,6,... darstellen - also ganze Frames vertauschen. Daran scheitern definitv einige Player - auch Markenprodukte wie Sony.
Dazu baut die Kompression eines Frames ja meistens auf seinen Vorgängerframe auf. Wenn da der falsche gewählt wird (wegen nicht interpretiertem Bottom Field First) sieht das Ergebnis auch wieder sehr interessant aus.
Durch diesen feinen Unterschied zwischen Frame- und Fieldstruktur kommt es dazu, dass einige Player bff bei Framestruktur sauber verarbeiten, bei Fieldstruktur jedoch unrettbar an ihr scheitern. Hier bleibt nur tff als Ausweg.
Viele Grüße
Dominique |
|
 |
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 21 - Verfasst am: Sa Dez 07, 2002 18:29 Titel: |
|
|
Tja, genau dieses Problem könnte mein Player haben.
Werde jetzt mal einen sauber laufenden tff Stream zu bff patchen. Dann dürfte vermutlich das undefinierbare Pixelsalat-Bild herauskommen - und ich weiß, dass mein Player field encoding mit bff generell nicht darstellen kann.
NACHTRAG:
Ist natürlich quatsch. Kann ja nicht gehen, da die Bilder voneinander abhängen. Wird die Abspielreihenfolge umgepatcht, kann ja nur Pixelsalat rauskommen.
Heute bin ich aber auch wieder begriffstutzig. Ist wohl der bereits geraubte Weihnachtsnerv ... 
Nochmal NACHTRAG 
Ich werde jetzt mal mit I-Frames only encoden und dann tff und bff testen. Da gibt es die Folgebildabhängigkeit ja nicht.
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
Der Karl
V.I.P. Mitglied
Anmeldungsdatum: 15.02.2002
Beiträge: 1416
|
| Beitrag 22 - Verfasst am: Sa Dez 07, 2002 20:10 Titel: |
|
|
Shh hat doch in FitCD in weiser Voraussicht dieses Problems schein eine bff -> tff
conversion eingebaut.  
Gruß Karl |
|
|
A. Dittrich
Anmeldungsdatum: 03.03.2002
Beiträge: 49
|
| Beitrag 23 - Verfasst am: Mo Dez 09, 2002 20:33 Titel: |
|
|
Hallo,
| Zitat: | Bei Fieldencoding gibt es aber vereinfacht ausgedrückt so etwas wie 50 einzelne Frames (bei PAL) pro Sekunde. Bei Bottom Field First müsste der Player dann die Frames in er Reihenfolge 2,1,4,3,6,5.... statt 1,2,3,4,5,6,... darstellen - also ganze Frames vertauschen. Daran scheitern definitv einige Player - auch Markenprodukte wie Sony.
|
@dominique:
Bist Du Dir sicher, dass die Fields immer in der Reihenfolge (Top,Bottom) im Datenstrom codiert werden müssen? Macht das der Procoder immer so, unabhängig von dem ttf-Flag?
Hab nämlich gerade nochmal in die MPEG-2 Spec reingeschaut, und unter 6.3.10 (Picture coding extension) folgendes gefunden:
"... The first encoded field of a frame may be a top-field or a bottom field, and the next field must be of opposite parity."
Ich würde das jetzt so interpretieren, dass man die Reihenfolge beim encodieren beliebig wählen darf, unabhängig davon ob man das Flag top_field_first setzt oder nicht. Für mich würde es dann Sinn machen, im Falle von bff auch das bottom-Field zuerst zu codieren, so daß der Player die Fields dann schon in der richtigen zeitlichen Reihenfolge bekommt.
Gruß,
AndreasD |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 24 - Verfasst am: Mo Dez 09, 2002 21:42 Titel: |
|
|
| Zitat: | picture_structure -- This is a 2-bit integer defined in the Table 6-14.
Table 6-14 Meaning of picture_structure
picture_structure Meaning
00 reserved
01 Top Field
10 Bottom Field
11 Frame picture
When a frame is encoded in the form of two field pictures both fields must be of the same picture_coding_type, except where the first encoded field is an I-picture in which case the second may be either an I-picture or a P-picture.
The first encoded field of a frame may be a top-field or a bottom field, and the next field must be of opposite parity.
When a frame is encoded in the form of two field pictures the following syntax elements may be set independently in each field picture:
• f_code[0][0], f_code[0][1]
• f_code[1][0], f_code[1][1]
• intra_dc_precision, concealment_motion_vectors, q_scale_type
• intra_vlc_format, alternate_scan
top_field_first -- The meaning of this element depends upon picture_structure, progressive_sequence and repeat_first_field.
If progressive_sequence is equal to ‘0’, this flag indicates what field of a reconstructed frame is output first by the decoding process:
In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.
In a frame picture top_field_first being set to ‘1’ indicates that the top field of the reconstructed frame is the first field output by the decoding process. top_field_first being set to ‘0’ indicates that the bottom field of the reconstructed frame is the first field output by decoding process
If progressive_sequence is equal to ‘1’, this flag, combined with repeat_first_field, indicates how many times (one, two or three) the reconstructed frame is output by the decoding process.
If repeat_first_field is set to 0, top_field_first shall be set to ‘0’. In this case the output of the decoding process corresponding to this reconstructed frame consists of one progressive frame.
If top_field_first is set to 0 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of two identical progressive frames.
If top_field_first is set to 1 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of three identical progressive frames. |
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
dominique
Anmeldungsdatum: 10.08.2002
Beiträge: 187
|
| Beitrag 25 - Verfasst am: Mo Dez 09, 2002 22:12 Titel: |
|
|
| Zitat: | | Ich würde das jetzt so interpretieren, dass man die Reihenfolge beim encodieren beliebig wählen darf, unabhängig davon ob man das Flag top_field_first setzt oder nicht. Für mich würde es dann Sinn machen, im Falle von bff auch das bottom-Field zuerst zu codieren, so daß der Player die Fields dann schon in der richtigen zeitlichen Reihenfolge bekommt. |
Hi,
hmmm... interessanter Ansatz... Die Specs lesen sich tatsächlich so... Wäre vielleicht doch einmal interessant nur den ttf-Flag umzupatchen und zu sehen, ob das irgendeinen Einfluss hat...
Ganz sicher bin ich mir nicht was Procoder macht, hier wäre ein Analysetool toll, mit dem man bei Field-Encoding Infos zu den einzelnen Fields, deren Zugehörigkeit und Reihenfolge im Stream bekommen kann...
Kennt jemand so ein Tool? Und/oder eines, bei dem man die Maximallänge der verwendeten Motionvectoren für einen Frame oder Stream sehen kann?
Viele Grüße
Dominique |
|
|
A. Dittrich
Anmeldungsdatum: 03.03.2002
Beiträge: 49
|
| Beitrag 26 - Verfasst am: Mo Dez 09, 2002 22:37 Titel: |
|
|
@mb1: Danke für den "fetten" Hinweis.
Korrigiert mich bitte wenn ich falsch liege, aber das würde ja dann bedeuten, dass tff=1 bei "field picture" nicht standardkonform ist.
Um-patchen fällt dann schon mal aus.
Oder muss man dann die field_sequence patchen?
Um sicher zu gehen mal die folgende Frage:
- Wenn hier von "field encoding" und "top/bottom field first" geredet wird, ist dann
a) das top_field_first-Flag gemeint,
b) die Encodier-Reihenfolge der Fields oder
c) die field_sequence-Information? |
|
|
WarpEnterprises
Anmeldungsdatum: 19.04.2002
Beiträge: 256
|
| Beitrag 27 - Verfasst am: Mo Dez 09, 2002 22:40 Titel: |
|
|
mit mpegrepair sieht man ziemlich alles, leider nicht gerade "schön".
http://www.google.com/
Musste den Link leider abwandeln, da auf der einzigen auftauchenden Seite Warez angeboten werden.
Bitte die Nutzungsbestimmungen einhalten. mb1 |
|
|
conan
Anmeldungsdatum: 24.04.2002
Beiträge: 3814
Wohnort: Wohnort
|
| Beitrag 28 - Verfasst am: Mo Dez 09, 2002 22:59 Titel: |
|
|
dat is aber nen gewagter link...  
_________________
Das perlt jetzt aber richtig.
------
Nachtisch essen ist der erste Schritt zum Gasgrillen.
---
http://tinyurl.com/d4r54z |
|
|
dominique
Anmeldungsdatum: 10.08.2002
Beiträge: 187
|
| Beitrag 29 - Verfasst am: Mo Dez 09, 2002 23:10 Titel: |
|
|
| Zitat: | Korrigiert mich bitte wenn ich falsch liege, aber das würde ja dann bedeuten, dass tff=1 bei "field picture" nicht standardkonform ist.
Um-patchen fällt dann schon mal aus.
Oder muss man dann die field_sequence patchen? |
Hui, jetzt wirds langsam kompliziert. Leider finde ich meine Mpeg-Specs jetzt gerade nicht mehr. Was war die "Progessive Sequence" denn jetzt genau? War die für DVD nicht sowieso verboten?
Und wie oft wird der ttf flag pro Stream denn gesetzt? Einmal oder pro Frame?
Es ist auf jeden Fall so, dass innerhalb eines Streams frei wechselnd field pictures (pic struc= 01,10) und frame pictures (11) verwendet werden dürfen. Für die Framepictures ist der ttf flag dann auf jeden Fall relevant und darf damit auch auf "1" stehen.
Bei Field-Encoding und bottom/top field first ist im wesentlichen die Einstellung für pic-structure und interlacing unter "target" im Procoder gemeint.
Die pic-structure dürfte sich dabei hauptsächlich auf den entsprechenden 2-bit-integer aus mb1's Posting auswirken. Was jetzt aber alles durch ttf und bff beeinflusst wird, wird immer unklarer... (zumindest mir). Ich würde auf a) und b) tippen...
Viele Grüße
Dominique |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 30 - Verfasst am: Mo Dez 09, 2002 23:48 Titel: |
|
|
@ dominique
| Zitat: | Ganz sicher bin ich mir nicht was Procoder macht, hier wäre ein Analysetool toll, mit dem man bei Field-Encoding Infos zu den einzelnen Fields, deren Zugehörigkeit und Reihenfolge im Stream bekommen kann...
Kennt jemand so ein Tool? Und/oder eines, bei dem man die Maximallänge der verwendeten Motionvectoren für einen Frame oder Stream sehen kann? |
MProbe kann das.
Allerdings kann es nicht die benutzte Maximallänge der Motionvektoren ermitteln, sondern nur die Länge bei einem ausgewählten Makroblock anzeigen. Das sieht dann z.B. so aus:
| Zitat: | Macroblock Number : 55
Motion Vector Parameters(in units of pixel):
MV Forward Frame x:18.5, y:21.5
Other parameters:
usw. |
MpegRepair zeigt nur die Motionvektoren graphisch an, Längenwerte (in Pixel) konnte ich bisher noch nicht angezeigt bekommen. Denke, MpegRepair kann das nicht.
@ Andreas
| Zitat: | | das würde ja dann bedeuten, dass tff=1 bei "field picture" nicht standardkonform ist |
So sehe ich das auch.
Denke ebenfalls wie dominique, dass a) und b) zutreffen.
Die Homepages der Analysetool-Hersteller sind:
Pixeltools MpegRepair
Interra MProbe
Über diese Seiten kann man auch Demo-Versionen beziehen.
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
dominique
Anmeldungsdatum: 10.08.2002
Beiträge: 187
|
| Beitrag 31 - Verfasst am: Di Dez 10, 2002 11:45 Titel: |
|
|
Hi,
stimmt, Mprobe zeigt das alles an. Demnach wird
a) der ttf flag für jeden einzelnen Frame gesetzt (oder nicht gesetzt), der mit pic-structure = frame kodiert wurde
b) Die Reihenfolge der Fields bei pic-struc = field durch die Reihenfolge innerhalb des Streams bestimmt. Bei field-pictures ist der ttf-flag nicht gesetzt.
So erzeugt auch Procoder die Dateien. Interessant ist dann aber wieder, warum denn einige Player die Fields bei pic-structure field vertauschen, wenn sie doch nur nacheinander das abspielen müssten, was ihnen vorgesetzt wird...
Viele Grüße
Dominique |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 32 - Verfasst am: Fr Dez 13, 2002 5:36 Titel: |
|
|
Sieht so aus, als würde Procoder tff (aus bff-Source) durch Verschieben einer Zeile realisieren (im Prinzip ähnlich CCE):
| Zitat: | Procoder Field Options- one of us is not Smart
12/12/02 12:26 PM Edit Reply
When you select source and add a Canopus codec file the Field automatically selects lower field When you select Target and then PAL DVD the fields show as upper.
If I am right in thinking that the Field should match the source, isn't it reasonable for Procoder to "check" the source and smartly select the correct field.
David
Post Extras:
CanopusOH
ProCoder Team
Reged: 09/03/02
Posts: 28
Loc: San Jose
Re: Procoder Field Options- one of us is not Smart [re: DigitalDave]
12/12/02 06:32 PM Edit Reply
Procoder will convert the field order if it doesn't match between source and target. There is no quality loss involved - only one video line is getting lost at top or bottom.
So - you can freely select your target as long as the source setting is right.
You asked for checking the source and setting the target accordingly.
2 reasons why not:
1) we found many DVD players "like" upper field much more (compatibility issue)
2) we can have many different sources in one project. How should we really decide which one is the master ? (true enough - we could do it for only one, so here (1) os valid...)
Regards,
CanopusOH |
Korrekt wäre dagegen, die Frames in Fields aufzuspalten, das erste Field wegwerfen und den Rest wieder zu neuen Frames zusammenzusetzen.
Die Unsitte, das Bild um eine Zeile zu verschieben, hasse ich auf Teufel komm raus.
Für mich bedeutet das, mein DV.avi mit avisynth auf tff (korrekt) umzuwandeln und dann erst in den Procoder zu füttern.
Dann gibt es keine "field order conversion" und der Output ist tff für größtmögliche Kompatibilität und optimal für "field picture type".
Warum nur macht Canopus eine ähnlich unsaubere Lösung wie CinemaCraft.
Ich meine, in dem Fall habe nicht ich unrecht, sondern die Firmen, oder.
Jedenfalls verändern sie das Bild in einer Weise (eine Zeile verschieben), die ich absolut nicht gebrauchen kann.
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
mosher2k
Anmeldungsdatum: 22.03.2002
Beiträge: 30
|
| Beitrag 33 - Verfasst am: Fr Dez 13, 2002 14:01 Titel: |
|
|
Hi mb1,
magste mir verraten mit welchen Avisynth-Befehlen Du solch eine Konvertierung erreichst ?
Danke und Gruss,
Mosher2k |
|
|
bergH
Moderator
Anmeldungsdatum: 14.06.2001
Beiträge: 13672
Wohnort: Am Kamener Kreuz
|
| Beitrag 34 - Verfasst am: So Jan 12, 2003 14:21 Titel: |
|
|
tach auch !
Habe mich gerade , weil ich wieder ein wenig mit dem ProCo beschäftige durch diesen Thread gekämpft.
@Mosher 2k
Fit2Disc macht das , wenn man bff>tff anclickt so:
#Plugins *****
AviSource("D:\DieKatzeAufDemCyberhome.avi")
DoubleWeave().SelectOdd()
BicubicResize(464,336,0,0.6,0,0,688,304)
AddBorders(8,120,8,120)
#Trim(0,-1).FadeOut(150)
_________________
Gruß BergH |
|
|
Helmut
globaler Moderator
Anmeldungsdatum: 06.05.2001
Beiträge: 30601
Wohnort: Frankfurt
|
| Beitrag 35 - Verfasst am: So Jan 12, 2003 18:57 Titel: |
|
|
Hmmm. Na gut ... aber jenseits dem getrickse da:
Hat sich denn beim ProCoder in Sachen "Field-Encoding" in der mittlerweile langen Zwischenzeit was getan ? Hat jemand Infos ?
Habe gerade die Tage eine SVCD mit dem ProCoder (Frame-Option natürlich) und absoluter SVCD-Standard erstellt. Vorlage eine DV-Stream, von analogKamera über A/D-Wandler gewonnen. Ausgangsmaterial war nicht gerade Spitze.
SVCD desdeswegen weil derjenige aus der Verwandschaft welcher den Film letztlich erhält keinen miniDVD-fähigen Stehallein hat und mir ne DVD zu "Schade" war für die 30 Minuten Film. Zudem war nicht bekannt ob der Stehallein mit XSVCD zurecht kommt.
Muß sagen (wie schon festgestellt) : Die Qualtiät der SVCD war im Rahmen des möglichen "überwältigend" ! Bin mal wieder begeistert von dem ProCoder.
Bekäme man nun noch die Fieldstrukture kompatibel in den Griff - die SVCD wäre dann für viele Gelegenheiten zum ersten Male eine echte Überlegung wert
_________________
Wenn mer sich uffreche will: - Eintrachtfan und SPD Mitglied! |
|
|
conan
Anmeldungsdatum: 24.04.2002
Beiträge: 3814
Wohnort: Wohnort
|
| Beitrag 36 - Verfasst am: So Jan 12, 2003 19:01 Titel: |
|
|
| Zitat: | Bekäme man nun noch die Fieldstrukture kompatibel in den Griff - die SVCD wäre dann für viele Gelegenheiten zum erstem Male eine echte Überlegung wert
|
jo,absolut wäre dann der optimale encoder für alles,svcd,dvd...
hoffentlich klappts
_________________
Das perlt jetzt aber richtig.
------
Nachtisch essen ist der erste Schritt zum Gasgrillen.
---
http://tinyurl.com/d4r54z |
|
|
bergH
Moderator
Anmeldungsdatum: 14.06.2001
Beiträge: 13672
Wohnort: Am Kamener Kreuz
|
| Beitrag 37 - Verfasst am: So Jan 12, 2003 19:23 Titel: |
|
|
tach auch !
Na ja die Field Geschichte:
Ich habe heute mal etwas getestet.
DV von einer TV Karte aufgezeichen (Ja das Ding kann MPEg,DV usw ausgeben.)
BFF eingestellt bei der Source und Mal BFF und TFF mit Field Dingens auf Auto bei Target.
1.) Himage-Player Target bff saugut , TFF Blockartefakte und MPEG Artefakte , aber sonst flüssiges Bild.
2.) SEG2K Target bff Pixelsalat bis zum Totalbildverlust, TFF kaum anschaubar aber noch was zu erkennen.
Für Helmut sicher nix neues Die Field Option ist beim SEG für den Po.
Aber selbst Frame wir d bei Highest Qualy schon saugut, und ich muesste bei TM alle Register ziehen , um da halbwegs dranzukommen.
_________________
Gruß BergH |
|
|
Helmut
globaler Moderator
Anmeldungsdatum: 06.05.2001
Beiträge: 30601
Wohnort: Frankfurt
|
| Beitrag 38 - Verfasst am: So Jan 12, 2003 19:30 Titel: |
|
|
Die Field Option ist beim SEG für den Po. 
Eben. Und net nur da. Solange man nicht sicher sein kann das mit FieldOption erstellte Streams ÜBERALL laufen ist das halt net brauchbar ... leider.
_________________
Wenn mer sich uffreche will: - Eintrachtfan und SPD Mitglied! |
|
|
Helmut
globaler Moderator
Anmeldungsdatum: 06.05.2001
Beiträge: 30601
Wohnort: Frankfurt
|
| Beitrag 39 - Verfasst am: Mi Jan 29, 2003 12:57 Titel: |
|
|
Nochmal aufwärmen :
Hat sich denn beim ProCoder in Sachen "Field-Encoding" in der mittlerweile langen Zwischenzeit was getan ? Hat jemand Infos ?
_________________
Wenn mer sich uffreche will: - Eintrachtfan und SPD Mitglied! |
|
|
|
FAQ
Suchen
Mitgliederliste
Einloggen, um private Nachrichten zu lesen
Profil
Login
Registrieren
