Bug #847
closedMarken werden bei HD-Aufnahmen falsch gesetzt, mögliche Lösung!
Description
Bei HD-Aufnahmen werden die Marken zwar meistens anhand von LOGO-Erkennung gesetzt. sind aber an der falschen Stelle. Wenn man den Wiedergabestatus an macht, kann man sehen, dass Marken genau doppelt so weit gesetzt werden, als erforderlich. Außerdem werden nicht alle .ts-Dateien gescannt. Im Beispiel nur bis 0003.ts. Es sind aber 5!
Ich hab mich damit in den Letzten Tagen mal beschäftigt und folgendes gefunden:
1.) in der streaminfo.cpp wird für h264 die fieldrate berechnet, aber nicht in das entsprechende Feld zurückgeschrieben.
wenn man ab Zeile 247 folgendes reinschreibt, dann passt die erkennung für die Framerate.
if (bs.getBit()) // timing_info_present_flag { uint32_t num_units_in_tick, time_scale; num_units_in_tick = bs.getU32(); // num_units_in_tick time_scale = bs.getU32(); // time_scale if (num_units_in_tick > 0) { frame_rate = time_scale / num_units_in_tick; if (frame_mbs_only_flag) { frame_rate/=2; } else { if (pic_order_cnt_type!=2) frame_rate/=2; } } fixedframerate=bs.getBit(); // fixed_frame_rate_flag if ((fixedframerate==1) && (frame_rate!=0)) { maContext->Video.Info.FramesPerSecond=frame_rate; } } #if 0 int nal_hrd_parameters_present_flag = bs.getBit(); // nal_hrd_parameters_present_flag
2.) der verwendete Algorithmus/decoder liefert für H264 bei Interlaced Material jedes "Field" (Halbbild) als eigenständiges Bild. Die sind aber im H264-stream nicht einzeln anspringbar, und werden vom vdr deshalb als einheit indiziert.
Als Folge davon ist die framenummer die von markad für die Marken verwendet wird um den Faktor 2 zu hoch.
ich hab mal testweise in der Funktion "void cMarkAdStandalone::AddMark(MarkAdMark *Mark)"
checks eingebaut, die die framenummer für neue marken vor dem einfügen halbiert, und als Ergebnis hab ich sehr genau sitzende Marken in den HD-Aufnahmen(1080i) im VDR!
ich hab nicht ganz den Durchblick wo das am besten eingepflegt werden sollte, meine Lösung scheint zu tun, ist aber ganz sicher nicht das optimum, darum keine weiteren Details zu dem Hack....
Updated by Joe_D almost 13 years ago
- Status changed from New to Confirmed
- Assignee set to Joe_D
- Target version set to 0.1.3
Funktioniert das auch mit "verschiedenen" Aufnahmen verschiedener Sender? Also ARDHD/ZDFHD, Pro7HD/VoxHD und ServusTVHD evtl. SkyHD, ORFHD?
Updated by MegaV0lt almost 13 years ago
Endlich jemand, der sich das mal angeschaut hat. Ich stehe gerne zum Testen bereit. Ich kann Sky (1080i), und die Privaten (1080i) in HD empfangen und würde gerne auch dazu beitragen. ARD und ZDF Senden in 720p Leider sind meine Programmierkenntnisse praktisch gleich Null.
Updated by Joe_D almost 13 years ago
- % Done changed from 0 to 10
Ich habe es ins aktuelle GIT eingepflegt (0.1.3pre). Bitte testen!
Updated by MegaV0lt almost 13 years ago
Der erste Test lief eben durch. Die Marken werden immer noch doppelt so weit gesetzt. Liegt aber sicher daran:
2.) der verwendete Algorithmus/decoder liefert für H264 bei Interlaced Material jedes "Field" (Halbbild) als eigenständiges Bild. Die sind aber im H264-stream nicht einzeln anspringbar, und werden vom vdr deshalb als einheit indiziert. Als Folge davon ist die framenummer die von markad für die Marken verwendet wird um den Faktor 2 zu hoch. ich hab mal testweise in der Funktion "void cMarkAdStandalone::AddMark(MarkAdMark *Mark)" checks eingebaut, die die framenummer für neue marken vor dem einfügen halbiert, und als Ergebnis hab ich sehr genau sitzende Marken in den HD-Aufnahmen(1080i) im VDR! ich hab nicht ganz den Durchblick wo das am besten eingepflegt werden sollte, meine Lösung scheint zu tun, ist aber ganz sicher nicht das optimum, darum keine weiteren Details zu dem Hack....
Laut Anzeige (Wiedergabeinfo) scheint nun aber der ganze Bereich gescannt zu werden (Getestet mit Aufnahme auf Pro7 HD). Hat also schon was gebracht.
Updated by MegaV0lt almost 13 years ago
@Anonym
Kannst du den Workaround hier mal Posten. Ich würde den gerne auch testen. Wie läuft das bei Dir? Ist das verhalten bei SD noch ok?
Updated by Joe_D almost 13 years ago
- Status changed from Confirmed to Closed
- % Done changed from 10 to 100
Sollte mit den Änderungen im GIT nun behoben sein...