Verbesserte Frame-Erkennung (bitte mal testen)

kls · 31. Oktober 2012

Nachdem es einige Probleme mit der Frame-Erkennung gegeben hat (insbesondere bei H264 mit "fields"), habe ich mir das Ganze nochmal gründlich angeschaut und parse jetzt die NALUs etwas weiter, bis alle nötigen Infos gefunden wurden.
Als erste Anregung hierzu diente "Joe_D"s Posting.

Anbei ein Patch gegen die VDR-Version 1.7.31, der die Frame-Erkennung verbessern soll. Es sind darin auch noch einige Sachen, die für das PTS-Fixing beim Schnitt benötigt werden, die wollte ich aber nicht extra weglassen. Momentan geht es nur um die Frame-Erkennung.
Bevor ich das in einer neuen Developer-Version freigebe wäre es nett, wenn einige hier mal drüberschauen und es vielleicht mal ausprobieren könnten.

Das Beispiel von hier klappt damit einwandfrei.

Beim Beispiel von hier werden zwar die Frame-Rate richtig und wohl auch die Frame-Grenzen leidlich erkannt, aber beim schnellen Vor-/Rücklauf sowie beim Bewegen von Schnittmarken kommt es zu überlagerten Teilbildern.
Vielleicht kann ja jemand erkennen, was da schiefläuft.

Im Zuge dieser Änderungen konnte ich auch die ganze Frame-Erkennung beschleunigen, so daß nur noch eine komplette GOP abgewartet wird (bisher wurde immer noch eine zweite GOP verstreichen lassen). Damit starten Aufnahmen und insbesondere das Pausieren des Live-Signals jetzt deutlich schneller (bis zu zweimal so schnell).

Klaus

jsffm · 31. Oktober 2012

Muss ich den vdr-1.7.31-cutterptsfix-4.diff erst rausnehmen?

Code

gentoo64 vdr-1.7.31 # patch < vdr-1.7.31-framedetect-1.diff
patching file remux.c
Hunk #2 FAILED at 112.
Hunk #3 succeeded at 212 with fuzz 1 (offset 85 lines).
Hunk #4 succeeded at 292 (offset 85 lines).
Hunk #5 succeeded at 336 with fuzz 1 (offset 119 lines).
Hunk #6 succeeded at 996 with fuzz 1 (offset 138 lines).
Hunk #7 succeeded at 1159 (offset 138 lines).
Hunk #8 succeeded at 1515 (offset 138 lines).
Hunk #9 succeeded at 1550 (offset 138 lines).
Hunk #10 succeeded at 1633 (offset 138 lines).
1 out of 10 hunks FAILED -- saving rejects to file remux.c.rej
patching file remux.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
6 out of 6 hunks ignored -- saving rejects to file remux.h.rej

Alles anzeigen

kls · 31. Oktober 2012

Zitat von jsffm

Muss ich den vdr-1.7.31-cutterptsfix-4.diff erst rausnehmen?

Ja.
Am besten einfach auf eine frische 1.7.31 anwenden.

Klaus

mini73 · 31. Oktober 2012

Moin!

Ich hab ein paar Sender durchprobiert, SD wie auch HD, scheint soweit alles in Ordnung zu sein.

Das hier kommt übrigens bei einem Radiosender, keine Ahnung, was da stehen sollte...

Code

//
Delta = 6480  FPS = 13.89  FPPU = 1 NF = 2

Lars.

kls · 31. Oktober 2012

Zitat von mini73

Ich hab ein paar Sender durchprobiert, SD wie auch HD, scheint soweit alles in Ordnung zu sein.

Wunderbar!

Zitat
Das hier kommt übrigens bei einem Radiosender, keine Ahnung, was da stehen sollte...
Code
//
Delta = 6480  FPS = 13.89  FPPU = 1 NF = 2

Das sind nur die Debug-Ausgaben für die Payload-Start-Marker. Da es bei Radiosendern keine I-, P- oder B-Frames in dem Sinne gibt, steht dazwischen nichts. Das ist also vollkommen OK so.

Da fällt mir noch was ein: bei meinen Tests hatte ich mit dem Kanal

Code

BBC HD;BSkyB:10847:vC56M2O0S1:S28.5E:23000:5500=27:5502=NAR@3;5501=eng@106:5503;5504=eng:0:6940:2:2050:0

ab und zu ein unterschiedliches Verhalten.
Mal waren die Testausgaben

Code

sIt/APb/ABt/ABb/ABt/ABb/ABt/ABb/APt/APb/ABt/ABb/ABt/ABb/ABt/ABb/APt/ABt/ABt/ABt/APt/ABt/ABt/ABt/ABt/ABt/ABt/ABt/AsI
Delta = 1800  FPS = 50.00  FPPU = 1 NF = 24

und ein anderes Mal war es

Code

sIt/ABt/ABt/ABt/ABt/ABt/APt/ABt/ABt/ABt/ABt/ABt/ABt/ABt/APt/ABt/ABt/ABt/ABt/ABt/ABt/ABt/AsIt
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 22

Wobei mir beides nicht ganz koscher erscheint.
Im ersten Fall scheint es zunächst der Fall mit "fields" zu sein (also interlaced), und es geht auch mit abwechselnd 't' und 'b' los, aber am Schluß kommen dann nur noch 't' (also "top fields"), was ja eigentlich nicht sein kann, oder?
Im zweiten Fall werden zwar "fields" angekündigt, aber kommen tun dann nur "top fields". Ob das sinnvoll sein kann, weiß ich auch nicht.
Ich hege ja den Verdacht, daß beim Handling von interlaced fields noch irgendwas nicht ganz stimmt. Falls also speziell dazu jemand was sagen kann, wäre das schön.

Klaus

Copperhead · 1. November 2012

Zitat von kls

Damit starten Aufnahmen und insbesondere das Pausieren des Live-Signals jetzt deutlich schneller (bis zu zweimal so schnell).

Beeindruckend!

Ich will zwar gleich noch ein paar Tests mit HD+ Aufnahmen machen, aber der Start vom Timeshift ist schon ziemlich schnell.

Edit: Also mit HD+ (speziell Prosieben HD) ruckelt es noch an der Schnittstelle. Aber nur ganz minimal

S:oren · 2. November 2012

Zitat von kls

Wunderbar!

Ich kann mich hier anschliessen, keine prinzipiellen Probleme, konnte allerdings nur "Standardkost" (H.264 720p und MPEG-2 576i) testen.

Zitat von kls

Damit starten Aufnahmen und insbesondere das Pausieren des Live-Signals jetzt deutlich schneller (bis zu zweimal so schnell).

Gefuehlt ist das Umschalten beim Zappen auch deutlich schneller, sehr schoen.

Zitat von Copperhead

Also mit HD+ (speziell Prosieben HD) ruckelt es noch an der Schnittstelle. Aber nur ganz minimal

So wie ich das verstanden habe, wurde das Schneiden an sich noch nicht verbessert. Subjektiv bleiben fuer mich auch die entsprechenden Ruckler gleich. Allerdings gibt es jetzt auch bei MPEG-2 wieder Kloetzchen an der Schnittstelle, ist hier das Handling des BrokenLink-Flags nicht mehr so wie vorher? Oder habe ich ohne Patch nur zufaellig keine Kloetzchen gesehen? Auch die Schnittmarken liegen in der geschnittenen Aufnahme noch nicht wieder uebereinander, aber das sollte der Patch ja auch nicht fixen.

Gruss,
S:oren

kls · 2. November 2012

Zitat von S:oren

Gefuehlt ist das Umschalten beim Zappen auch deutlich schneller, sehr schoen.

Hmm, das kann ich aber mit dieser Änderung nicht erklären, denn die Frame-Erkennung spielt beim Zappen gar keine Rolle.

Zitat

So wie ich das verstanden habe, wurde das Schneiden an sich noch nicht verbessert. Subjektiv bleiben fuer mich auch die entsprechenden Ruckler gleich. Allerdings gibt es jetzt auch bei MPEG-2 wieder Kloetzchen an der Schnittstelle, ist hier das Handling des BrokenLink-Flags nicht mehr so wie vorher? Oder habe ich ohne Patch nur zufaellig keine Kloetzchen gesehen? Auch die Schnittmarken liegen in der geschnittenen Aufnahme noch nicht wieder uebereinander, aber das sollte der Patch ja auch nicht fixen.

Während der Arbeiten an der Schnittproblematik hat sich herausgestellt, daß wohl die Frame-Erkennung noch nicht ganz astrein ist. Daher habe ich erstmal diese Baustelle in Angriff genommen. Der Schnitt kommt gleich danach.

Klaus

Uwe · 2. November 2012

Zitat von kls

Hmm, das kann ich aber mit dieser Änderung nicht erklären, denn die Frame-Erkennung spielt beim Zappen gar keine Rolle.

Hi,
hier geht nun das zappen auch merklich flotter mit der FF HD 6400... auch der "kurze Schluckauf im Ton" beim hinzappen zu einem neuen Sender, ist weg! Super, weiter so!
kls Schau Dir mal folgendes an: Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Viele Grüße, Uwe

kls · 3. November 2012

Zitat von Uwe

hier geht nun das zappen auch merklich flotter mit der FF HD 6400... auch der "kurze Schluckauf im Ton" beim hinzappen zu einem neuen Sender, ist weg! Super, weiter so!
kls Schau Dir mal folgendes an: Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Danke für den Hinweis - ich hatte schon eine Weile keinen neuen Treiber mehr gebaut.
Da wurde ja anscheinend tatsächlich einiges verbessert

Klaus

Verbesserte Frame-Erkennung (bitte mal testen)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema