TTD Forum

Nein, das wird jetzt keine Frage wie man einen Time Tunnel baut.
Vielmehr brauche ich einen Tipp, wie man während der Wiedergabe einer Aufzeichnung von der aktuellen Position möglichst präzise um x Sekunden vor oder zurückspringen kann. Wenn ich mir die API (v1.22) so anschaue, kommt da eigentlich nur die Funktion TAP_Hdd_ChangePlaybackPos() in Frage, aber dort kann man nur einen Block als Parameter angeben und keinen Zeitindex. Wie haben das die Programmierer von SmartSkipper oder Improbox gelöst?
Danke schon mal im voraus.

Jetson hat geschrieben:Nein, das wird jetzt keine Frage wie man einen Time Tunnel baut.

und ich wollt grad mit dem flux kompensator anfangen.

und ich wollt grad mit dem flux kompensator anfangen.

Dazu mußt Du den Topf aber ganz schön auf Geschwindigkeit bringen.

DeJe hat geschrieben:Dazu mußt Du den Topf aber ganz schön auf Geschwindigkeit bringen.

dafür hat man doch nen reaktor im keller.

Jetson hat geschrieben:Wie haben das die Programmierer von SmartSkipper oder Improbox gelöst?
Danke schon mal im voraus.

Ich denke mal so:
TotalBlocks / Gesamtspieldauer = Blöcke pro Minute.
Und so dann pro Minute dieses Ergebnis auf CurrentPos draufrechnen?

General hat geschrieben:dafür hat man doch nen reaktor im keller.

endlich bekommt meiner im Keller mal einen nutzen, danke für die tolle Idee !

Jetson hat geschrieben: Vielmehr brauche ich einen Tipp, wie man während der Wiedergabe einer Aufzeichnung von der aktuellen Position möglichst präzise um x Sekunden vor oder zurückspringen kann. Wenn ich mir die API (v1.22) so anschaue, kommt da eigentlich nur die Funktion TAP_Hdd_ChangePlaybackPos() in Frage, aber dort kann man nur einen Block als Parameter angeben und keinen Zeitindex.

TAP_Hdd_GetPlayInfo(TYPE_PlayInfo *playInfo ) gibt dir unter anderem den "Current" Block der Wiedergabe.

Bei Playback wird die Zeit/Block so berechnet, wie Elle4u schon geschrieben hat, bei Aufnahmen/Timeshift muss man die Aufnahmezeit aus den RecInfo TAP_Hdd_GetRecInfo( byte recSlot, TYPE_RecInfo *recInfo ) holen. Achtung, testen, welcher der beiden Rec Slots für dich in Farge kommt.

Beim Sprung für X Sekunden mit TAP_Hdd_ChangePlaybackPos( dword blockPos ); wird dann blockPos berechnet aus

playInfo ->currentBlock + (X * Blöcke pro Sekunde)

Alles klar?

Pippin hat geschrieben:TAP_Hdd_GetPlayInfo(TYPE_PlayInfo *playInfo ) gibt dir unter anderem den "Current" Block der Wiedergabe.

Bei Playback wird die Zeit/Block so berechnet, wie Elle4u schon geschrieben hat, bei Aufnahmen/Timeshift muss man die Aufnahmezeit aus den RecInfo TAP_Hdd_GetRecInfo( byte recSlot, TYPE_RecInfo *recInfo ) holen. Achtung, testen, welcher der beiden Rec Slots für dich in Farge kommt.

Beim Sprung für X Sekunden mit TAP_Hdd_ChangePlaybackPos( dword blockPos ); wird dann blockPos berechnet aus

playInfo ->currentBlock + (X * Blöcke pro Sekunde)

Alles klar?

Erstmal Danke Elle4u und auch Dir. Die Berechnung auf diese Weise ist mir klar, ich bin mir aber nicht sicher ob jeder Block eine konstante Zeitspanne repräsentiert. Aufgrund der variablen Bitrate sollte eine Sequenz von relativ statischen Bildern weniger Platz in einem Block belegen als sehr dynamische Szenen. Letztendlich müssen ja immer 25 Bilder pro Sekunde dekodiert werden. Darüber hinaus ist die duration in den TYPE_(Play/Rec)Info Strukturen ganzzahlig, eine Aufnahme mit 45 Minuten hat also die gleiche Dauer wie eine Aufnahme die 45 Minuten und 1-59 Sekunden lang ist. Ich werde es mal mit obiger Formel testen und schauen, wie präzise die Sache ist. Ich hatte gehofft, es gäbe vielleicht eine undokumentierte API-Funktion, die einen Zeitindex als Parameter hat. Eigentlich möchte ich für das TAP, an dem ich gerade schreibe, nur wissen, ob beim Drücken der gelben Jump-Taste tatsächlich eine Bookmark angesprungen wurde oder ob lediglich 30 Sekunden vorgespult wurde.

Jetson hat geschrieben:Eigentlich möchte ich für das TAP, an dem ich gerade schreibe, nur wissen, ob beim Drücken der gelben Jump-Taste tatsächlich eine Bookmark angesprungen wurde oder ob lediglich 30 Sekunden vorgespult wurde.

Du könntest im Header der Datei nachschauen, wo die Bookmarks gesetzt sind und diese Stellen mit der angesprungenen vergleichen. Oder habe ich da einen Denkfehler?

Elle4u hat geschrieben:Du könntest im Header der Datei nachschauen, wo die Bookmarks gesetzt sind und diese Stellen mit der angesprungenen vergleichen. Oder habe ich da einen Denkfehler?

Hatte ich auch schon dran gedacht, nur leider fehlt mir der Aufbau des Headers. Es können ja maximal 64 Bookmarks gesetzt werden, also vermute ich mal, dass es irgendwo im Header einen Bereich gibt, wo 64 Blocknummern gespeichert werden können. Das wäre natürlich optimal für das was ich machen möchte. Ich werde mal einen Binärvergleich derselben Aufzeichnung mit und ohne Bookmarks machen. Im Header stehen ja auch noch die ganzen Textinfos zur Sendung, aber die Bookmarks sollten eigentlich an einem festen Offset beginnen.

Jetson hat geschrieben:Hatte ich auch schon dran gedacht, nur leider fehlt mir der Aufbau des Headers. Es können ja maximal 64 Bookmarks gesetzt werden, also vermute ich mal, dass es irgendwo im Header einen Bereich gibt, wo 64 Blocknummern gespeichert werden können. Das wäre natürlich optimal für das was ich machen möchte.

Es gibt da eine inoffizielle Übersicht von FireBird. Frag ihn mal, ob er sie Dir zur Verfügung stellt. Ich möchte sie nicht ohne Rückfrage rausgeben...

P.S. Da fällt mir gerade ein: Ob da die Bookmarks aufgeführt sind müßte ich erst noch checken...

Hi!

http://www.topfield.co.kr/data/product/ ... 02004).doc

Gruß,
Gerti

Habe gerade mal den Link von Gerti angeschaut. So wie es aussieht, stehen die Bookmarks dort nicht drin, es sei denn sie sind in dem Text-Bereich von EVT_INFO oder EXT_EVT_INFO mit drin. Kann es sein, dass die Bookmarks in einer separaten Datei abgelegt werden, die als Hidden markiert ist und deshalb unter Altair oder im Menü des Topfields nicht angezeigt wird?

Jetson hat geschrieben:Habe gerade mal den Link von Gerti angeschaut. So wie es aussieht, stehen die Bookmarks dort nicht drin, es sei denn sie sind in dem Text-Bereich von EVT_INFO oder EXT_EVT_INFO mit drin. Kann es sein, dass die Bookmarks in einer separaten Datei abgelegt werden, die als Hidden markiert ist und deshalb unter Altair oder im Menü des Topfields nicht angezeigt wird?

Hm.
TFHead kann sie aber anzeigen...??? Daher kam ich drauf...

Elle4u hat geschrieben:Hm.
TFHead kann sie aber anzeigen...???

Leider nicht beim TF5200PVRc. Das Programm zeigt beim Laden der rec-Datei eine Fehlermeldung. Wahrscheinlich ist die Struktur des Headers etwas anders beim Kabelmodell. Interessant ist aber die Doku! Hatte eben auch schon bei meinem Binärvergleich die entsprechende Stelle im Header gefunden ab wo die Bookmarks gespeichert sind. In der Doku steht außerdem die Bookmarks sind im Header in der Einheit 1/10 s eingetragen. Damit bin ich eigentlich wieder am Anfang, denn wenn dort keine Blocknummern stehen, muß ich wieder wissen, bei welchem Zeitindex ich mich exakt befinde, um den Wert mit den Bookmark-Einträgen im Header vergleichen zu können.

Schade...

Aber hauptsache ich hatte mal einen guten Einfall

Elle4u hat geschrieben: Aber hauptsache ich hatte mal einen guten Einfall

Auf alle Fälle!

Irgendwo hier im Forum gibt es die Info, dass der Beader vom 5200 4 Byte kürzer (oder länger?) ist. Deshalb der Fehlschlag von TFHead.

Das mit der Einheit 1/10s muss ich so hinnehmen, nur fehlt mir der Glaube. Um einen Bookmark so anzuspringen müsste die Datei durchsucht werden, und selbst für eine Binärsuche mit Schätzung des Einsprungpunktes geht mir das Springen zu schnell.

Harvey hat geschrieben:Irgendwo hier im Forum gibt es die Info, dass der Beader vom 5200 4 Byte kürzer (oder länger?) ist. Deshalb der Fehlschlag von TFHead.

Korrekt.
Es ist dieser Thread

Hi,

leider habe ich den Thread erst jetzt gesehen.

Jetson hat geschrieben:Die Berechnung auf diese Weise ist mir klar, ich bin mir aber nicht sicher ob jeder Block eine konstante Zeitspanne repräsentiert.

Die Einheit eines Blocks ist 1 Sektor x 1 TS Paket = 512x188 = 94kB. Das macht die Sache zwar wunderbar unabhängig von der Clustergrösse einer HDD, hat aber keinen Bezug zur Zeit. Damit bleibt das Ausdividieren die beste Schätzung.

MfG. Alex