Es kommen immer die beiden Halbbilder eines Vollbildes nacheinander, dann die beiden Halbbildes des nächsten Vollbildes.
Ist mir neu. Hast du dafür eine Quelle?
Probleme mit ProSiebenSat.1 auf Satellit 12544 horizontal
-
-
Hi,
Es gibt einen zeitlichen Versatz zwischen den Halbbildern da sie nacheinander aufgenommen sind.
Zeilensprungverfahren – Wikipediade.m.wikipedia.orgMfG Stefan
-
Jedes Frame enthält nur ein halbes Bild.
Es kommen immer die beiden Halbbilder eines Vollbildes nacheinander, dann die beiden Halbbildes des nächsten Vollbildes.
Nein, es wird immer ein Frame übertragen das in den geraden Zeilen ein Halbbild und in den ungeraden Zeilen ein Halbbild enthält.
Edit: Diese Halbbilder werden deinterlaced im Abstand von 20ms dargestellt. Die gesendeten progressiven Frames werden im Abstand von 40ms dargestellt. Die Bildinformationsmenge ist die gleiche, nur anders auf Bilder und zeitlich verteilt.
-
Genau und die sind nicht vom selben Vollvild, sondern von 2 verschiedenen nacheinander Aufgenommenen. Sonst hätte man ja analog speichern müssen. Das gab es damals nicht.
-
Nochmal nachlesen hilft: sorry for the noise, ihr habt Recht.
-
Sonst hätte man ja analog speichern müssen.
Doch, das war analog. Digital kam später.
Es wurde oben links angefangen ein Pixel nach dem anderen mit dem Elektronenstrahl zeilenweise zu schreiben. Dabei wurde jede zweite Zeile ausgelassen. Diese wurde im zweiten Duchgang dargestellt. Danach wurde wieder oben angefangen. Der Elektronenstrahl hat permanent ein Pixel geschrieben. Daraus ergab sich dann durch die Trägheit der Röhre ein Bild.
Heute werden die Informationen verarbeitet und das Bild zu einem Zeitpunkt dargestellt.
-
Ist mir klar, deshalb ja hätte...
-
Das Bild, das du aus Wiki zitiert hast, ist ja auch nur verwirrend.
Wenn die Quelle Frame A dann B hat, wird ja A first und B second übertragen und es kommt A/B zeilenweise gemischt raus.
Oder nicht ?
-
Das aber interlaced und progressive Frames gemischt in einem Stream vorkommen ist neu. Keine Ahnung ob das von einen Standart gedeckt ist.
Die Frage stellte sich mir auch, da man mit sowas prima einen Deinterlacer durcheinander bringen könnte.
Explizit verboten scheint es wohl nicht zu sein. Eine wirkliche Aussage dazu konnte ich aber nicht finden.
Wirklich Sinn macht das hin und her für mich aber aktuell nicht.
Wenn man eine ...25p Quelle hat (zB. Kinofilm mit speedup), dann gehören die beiden Halbbilder zu selben Bild (sofern der Abtaster korrekt arbeitet). In diesem Fall macht es Sinn das progressive Flag zu setzen.
Man kann dann bei der Nachbearbeitung aufs deinterlacen verzichten, was sich positiv auf die Bildqualität auswirken sollte.
Bei einer ...25i Quelle wurden die beiden Halbbilder zeitlich nacheinander aufgenommen und gehören eigentlich nicht zu selben Bild.
Stellt man dieses Bild "einfach so"(*) dar, gibt es die bekannten Streifen, wenn sich was bewegt.
Man muss das Bild irgendwie deinterlacen, sei es mittels Software / ICs (LCD, OLED, Plasma, PC-Röhrenmonitor, 100Hz-Röhren-TV) oder des Bildschirms (standard 50Hz Röhren-TV).
(* Genau genommen ist das auch schon ein deinterlacing mittels "weaving".)
Da bei interlaced Videos diese Streifen mit kodiert werden müssen senkt das die Effizienz den Codecs zum Teil deutlich.
Des weiteren gehen, zumindest bei mp4, einige, für die Effizienz wichtige, Funktionen nicht bei interlaced Material.
Ich hatte vor Jahren mal versucht, mir das deinterlacing zu sparen und TV-Aufnahmen mittels x264 interlaced zu archivieren. Nach einigem Aufwand ist mir das zwar gelungen, das Ergebnis war aber enttäuschend. Die Dateien waren im Vergleich fast doppelt so groß.
Das Bild, das du aus Wiki zitiert hast, ist ja auch nur verwirrend.
Wenn die Quelle Frame A dann B hat, wird ja A first und B second übertragen und es kommt A/B zeilenweise gemischt raus.
Oder nicht ?
Wirklich schön ist dieses Beispiel nicht, da es unnötig verwirrend ist und nicht mal "echtes" interlaced.
A und B sollen nur den Bildinhalt darstellen. Es ist links also nur ein Bild mit rotem A und blauem B untereinander.
Da beide Halbbilder (video fields) vom selben Bild stammen, ergeben die, zeilenweise gemischt (= weave), natürlich wieder das Ausgangsbild.
Das heisst dies ist ein Beispiel, wo man das progressive Flag setzen sollte!
Die Übertragung ist interlaced, aber der Bildinhalt eigentlich nicht.
Bei einem "echten" interlaced Beispiel würde übrigens nicht das Ausgangsbild raus kommen. Was allein schon deswegen nicht geht, weil es 2 Ausgangsbilder wären.
-
Die scheinen wirklich nicht mehr interlaced zu senden.
Ich habe es heute kurz am Computermonitor ohne Deinterlacer versucht und einerlei Kammbildung mehr feststellen könne. Selbst die Laufschriften waren frei davon und da hat man es eigentlich immer sofort gesehen.
Faszinierend, was mit der alten Technik alles möglich ist.
-
Interessant, der Stream von Pro7 wird von ffmpeg auch als progressive erkannt, aber mit 25 fps ?!?
Die Simpsons:
Input #0, mpegts, from '00001.ts':
Stream #0:0[0x1ff]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbcUnd der FrameParser des VDR erkennt aus dem DVB-Stream das MPEG2 als "720 x 576i 25,00 fps", also interlaced
EDIT: Aber bei taff ist es dann doch wieder interlaced:
Input #0, mpegts, from '00001.ts':
Stream #0:0[0x1ff]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25
fps, 25 tbr, 90k tbn, 50 tbc
Evtl. ist das nur bei zugekauften Inhalten progressive ?
Bei einer Aufnahme von Pro7 von 2011 sieht das so aus:
Input #0, mpegts, from '00001.ts':
Stream #0:0[0x1ff]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Und bei RTL sieht es heute noch so aus:
Input #0, mpegts, from '00001.ts':
Stream #0:0[0xa3]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt470bg, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
-
Welche Stelle im Code produziert denn diesen Output?
Wenn es sehr lange dauert, würde ich auch überlegen, ob ein PTS Wrap in diesem Fall ordentlich abgefangen wird.
-
Welche Stelle im Code produziert denn diesen Output?
Das Log habe ich nach dem Decoder eingefügt. Bevor entschieden wird ob deinterlaced werden muss.
Auf den PTS sollte es keinen Einfluss haben. Der ist per Frame. Das beinhaltet ein Bild wenn progressive oder ist dem ersten Bild wenn interlaced zugeortnet.
-
Das Log habe ich nach dem Decoder eingefügt. Bevor entschieden wird ob deinterlaced werden muss.
Da kann ich mir nichts genaues drunter vorstellen.
Zeig mal den Code
Softhddevice macht auf den Sendern auch merkwürdiges, das gucke ich mir gerade an. Er bleibt aber nicht hängen, sondern dropt und dupt gelegentlich.
-
Zeig mal den Code
Codeif (render->interlaced_frame != frame->interlaced_frame) { #include <time.h> time_t now; time(&now); fprintf(stderr, "VideoRenderFrame: interlaced_frame changed to %d , %s\n", frame->interlaced_frame, ctime(&now)); render->interlaced_frame = frame->interlaced_frame; }Er bleibt aber nicht hängen,
Ich denke das das nur mein Plugin macht. Weiss aber noch nicht warum.
sondern dropt und dupt gelegentlich.
Das muss ich auch noch klären. Ein progessive Frame kann sofort in die Queue. Ein interlaced muss erst durch den Deinterlacer. Das braucht seine Zeit. Da kann ein progessive Frame die interlaced Fames sozusagen überholen und in falscher zeitlicher Reihenfolge in der Queue ankommen.
-
Interessant, der Stream von Pro7 wird von ffmpeg auch als progressive erkannt, aber mit 25 fps ?!?
Das ist nach meinem Verständnis auch korrekt so.
EDIT: Aber bei taff ist es dann doch wieder interlaced:
Die Simpsons und Galileo waren aber progressive.
(Ich hatte die Simpsons zufällig extra mal aufgenommen, um was zu probieren.)
Ich hatte noch Simpsons von 2021 drauf. Die sind interlaced markiert, aber scheinen trotzdem progressive zu sein.
Selbst ohne Deinterlacer sehe ich 0 Kammeffekte und bei den Cartoons sind die eigentlich sehr auffällig.
Evtl. ist das nur bei zugekauften Inhalten progressive ?
Evtl spinnt auch deren Technik einfach nur?
ffprobe liefert bei mir aber mehrfach die folgenden Fehler:
[mpegts @ 0x55e0ecf7aa00] PES packet size mismatch
[mpegts @ 0x55e0ecf7aa00] Packet corrupt (stream = 1, dts = 6921192061).
Habt Ihr die auch, oder muss ich nach dem Feher in meiner SAT-Verteilung suchen gehen?
-
Code
[mpegts @ 0x5587c691fec0] PES packet size mismatch [mpegts @ 0x5587c691fec0] Packet corrupt (stream = 1, dts = 4534808530). [mpegts @ 0x5587c691fec0] PES packet size mismatch [mpegts @ 0x5587c691fec0] Packet corrupt (stream = 2, dts = 4534805477).Die habe ich auch. Bei ein paar Stichproblem ist es immer genau an einer Stelle in beiden Audio Streams. Das kann aber wohl nichts mit dem Video Problem zu tun haben.
-
Die Simpsons und Galileo waren aber progressive.
Es wechselt im Stream immer wieder hin und her. Ein Muster habe ich bisher nicht finden können. FFmpeg untersucht nur einige Frames am Anfang der Aufnahme und gibt diese Ergebnisse aus.
Habt Ihr die auch, oder muss ich nach dem Feher in meiner SAT-Verteilung suchen gehen?
Solche Fehler findet FFmpeg hier auch. Mit Mediaplayer und über vdr wird die Aufnahme aber abgespielt. Das muss ich noch genauer untersuchen. An der SAT Anlage brauchst du wohl erst mal nix machen.
Meinen Fehler habe ich wohl gefunden. Seit gestern Abend keine Segfaults mehr. Es war dann wohl ein Threading Problem. Jetzt muss ich noch die zeitliche Reihenfolge der Bilder sicher stellen.
-
Evtl spinnt auch deren Technik einfach nur?
Genau, ich denke mittlerweile, dass deren Encoder fehlerhaft ist.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!