» Off-"Flitsservice" » Auto's » Dashcam info Reclamevrij? Log aub in, kost niets   



 Pagina 1 van 1  [ 48 berichten ]
dvdouden
Die hard
 Bericht 
Technisch verhaal, bedoelt voor wie dit soort dingen interessant vind :thumb:

Bij gebrek aan een fatsoenlijke export mogelijkheid in DOD player om de GPS data te exporteren ben ik maar op onderzoek uitgegaan waar en hoe dat spul opgeslagen zit in de mov bestanden.
Het antwoord op de "waar" vraag is gelukkig gewoon op internet te vinden: achter de audio samples. Binnen de 'mdat' atom zitten meerdere 'free' atoms van 64 KiB, de eerste bytes van die atoms bevat de tekst "GPS P". Deze atoms lijken altijd achter de audio samples te zitten en die kun je weer mbv een lookup table achterin de mov vinden; dat scheelt weer tig honderd MB aan data doorzoeken ;)
De eerste 40 byte aan data (beginnend met "GPS P") lijkt altijd hetzelfde te zijn en mag je negeren.
Hierna volgen 30 frames van 52 bytes. Voor de duidelijkheid: per seconde worden dus 30 frames aan data in een atom opgeslagen waarvan er 25 ook in de vorige atom zaten en de andere 5 nieuw zijn. De 5 nieuwe frames overschrijven de 5 oudste frames van de vorige atom als ware het een soort circular buffer. Het eerste frame binnen een atom is dus niet per se de oudste (die kan ook halverwege zitten).
Tot zover wat ik van internet heb kunnen plukken, wat volgt is eigen research gebaseerd op 1 filmpje van anderhalve minuut en een hoop gepiel met een hex editor ;)
Vervelend genoeg is vrijwel alle data binnen een frame versleuteld. Gelukkig bleek het niet bijster complex te zijn: een simpele XOR :lol:
Bytes 0-11 worden geXOR'd met byte 3 (beginnen bij 0, dus 4e byte)
Bytes 12-20 worden geXOR'd met byte 20
Bytes 21-23 zijn altijd hetzelfde "ATC"
Bytes 24-27 worden geXOR'd met byte 20
Byte 28 wordt geXOR'd met byte 28
Bytes 29-31 zijn altijd hetzelfde "001"
Bytes 32-47 worden geXOR'd met byte 28
Bytes 48-49 worden geXOR'd met byte 49
Bytes 50-51 zijn denk ik checksum bytes, ziet er nogal random uit

Na het "ontsleutelen" en wat puzzelen kom ik op het volgende uit:
byte 0: waarschijnlijk de tijdzone, staat bij mij altijd op 1
byte 1: sequence number, hoogt op met 1 bij elk nieuw uniek frame. Overflowt van 255 naar 0
byte 2: sequence number binnen atom, eerste frame heeft 0 als waarde, laatste 29.
byte 3: "decryption key", na ontsleuteling altijd 0
byte 4: onbekend, bij mij 74 (0x4A)
byte 5: onbekend, bij mij 190 (0xBE)
byte 6: onbekend, bij mij 15 (0x0F)
byte 7: onbekend, bij mij 0
byte 8: onbekend, hoogt elke seconde op met 1
byte 9: onbekend, bij mij 198 (0xC6)
bytes 10-11: onbekend, bij mij 0
byte 12: onbekend, heeft mogelijk iets met de aanwezigheid van GPS signaal te maken. Is 2, soms 1, bij wegvallen GPS 0
byte 13: uur (in GMT)
byte 14: minuut
byte 15: seconde
bytes 16-19: latitude, byte 16 is least significant, byte 19 most significant. Delen door 10.000.000 om waarde in graden te krijgen. Positief is noordelijk, negatief is zuidelijk (gok ik)
byte 20: "decryption key", na ontsleuteling altijd 0. Bij mij vrijwel altijd gelijk aan byte 3
byte 21: altijd 'A' (0x41)
byte 22: altijd 'T' (0x53)
byte 23: altijd 'C' (0x43)
bytes 24-27: longitude, least significant byte first. Delen door 10.000.000 om waarde in graden te krijgen. Positief is oostelijk, negatief is westelijk (gok ik)
byte 28: "decryption key", na ontsleuteling altijd 0.
byte 29: altijd '0' (0x30)
byte 30: altijd '0' (0x30)
byte 31: altijd '1' (0x31)
bytes 32-35: snelheid, least significant byte first. Delen door 100 om waarde in meters per seconde te krijgen.
bytes 36-39: heading, least significant byte first. 0 is noorden, 16384 is oost, 32768 is zuid, 49152 is west, overflowt bij 65535, twee most significant bytes zijn dus altijd 0.
bytes 40-43: geen idee, mogelijk hoogte ofzo? Blijft hangen als GPS signaal wegvalt.
byte 44-45: jaartal, least significant byte first (2015 = 0xDF,0x07)
byte 46: maand (1 = jan, 12 = dec)
byte 47: dag vd maand
byte 48: geen idee, bij mij 8
byte 49: "decryption key", na ontsleuteling altijd 0, bijna altijd gelijk aan byte 28
bytes 50-51: waarschijnlijk checksum, nogal random

Tot zover de info die ik tot nu toe heb weten te verzamelen. Ik mis nog de G sensor data, die stond helaas niet aan :( Nu nog een tooltje in elkaar knutselen wat alle gegevens uit een of meerdere filmpjes trekt :)

Feitelijk
Master
 Bericht 
Cool! 40-43 zal inderdaad de hoogte wel zijn.

dvdouden
Die hard
 Bericht 
Mogelijk is het de hoogte, er zit wel wat fluctuatie in maar ik kon het niet helemaal goed koppelen aan de route die gereden werd. Binnenkort maar eens een heuveltje/dijk opzoeken :)

Pietert
Master
 Bericht 
dvdouden schreef:
byte 8: onbekend, hoogt elke seconde op met 1

unix epoch? O:) :wink:

dvdouden schreef:
Binnenkort maar eens een heuveltje/dijk opzoeken

Huidige GPS systemen op de WGS84 correctie zijn redelijk waardeloos qua hoogte. fluctuaties van 10m of meer zijn niet uitzonderlijk. Je moet echt een behoorlijke heuvel op wil je verschil zien :)

dvdouden
Die hard
 Bericht 
Pietert schreef:
unix epoch?

Mogelijk het aantal seconden sinds het begin van de rit of iets dergelijks. :)
Pietert schreef:
Huidige GPS systemen op de WGS84 correctie zijn redelijk waardeloos qua hoogte. fluctuaties van 10m of meer zijn niet uitzonderlijk. Je moet echt een behoorlijke heuvel op wil je verschil zien

Flinke parkeergarage dan :)

Er is overigens geen timestamp in milliseconden aanwezig, frames binnen dezelfde seconde hebben dus dezelfde timestamp, wat mogelijk verklaart waarom registratorviewer maar 1 positie per seconde exporteert.

Feitelijk
Master
 Bericht 
Pietert schreef:
unix epoch?

In 1 byte?! :lol:
Pietert schreef:

Huidige GPS systemen op de WGS84 correctie zijn redelijk waardeloos qua hoogte. fluctuaties van 10m of meer zijn niet uitzonderlijk. Je moet echt een behoorlijke heuvel op wil je verschil zien


Ik ben redelijk te spreken over de u-blox 5 chip, die doet stapjes van een meter maar lijkt redelijk betrouwbaar. In ieder geval een stuk beter dan de sirf-III.

Pietert
Master
 Bericht 
Feitelijk schreef:
u-blox

:kniktja: ook mee gewerkt op de TU op 5 Hz. Vooral hun binaire protocol gaat lekker rap. Dat NEMA is toch maar een hoop overhead voor een i2c verbinding :)

Feitelijk
Master
 Bericht 
Even geanalyseerd: de standaarddeviatie voor hoogte is zo'n 2 meter.

dvdouden
Die hard
 Bericht 
Bytes 8-9 zijn toch een soort 16 bits epoch :lol: loopt keurig op per seconde en overflowt na 65535 naar 0
laatste regel uit een ritje en eerste regel van de volgende rit een paar minuten later
Code:
2015-02-21 11:09:12  4B C2
2015-02-21 11:13:08  47 C3

Verschil is 252 (decimaal), ofwel 4 minuten en 12 seconden. Dat komt dan weer niet helemaal overeen met de timestamp in de data, maar het kan niet altijd meezitten :lol:

Pietert
Master
 Bericht 
En zoals we allemaal weten: in Computer Science is "ongeveer" ook gewoon goed. Rounding errors enzo :wink:

dvdouden
Die hard
 Bericht 
Jammer dat klanten daar meestal anders over denken, vooral als het om geld gaat :lol:

Maar het lijkt toch niet helemaal aan tijd gerelateerd te zijn. Elke vijf frames hoogt byte 8 op, wat op zich wel weer overeen komt met het aantal nieuwe "gps frames" per seconde, maar niet per sé met de timestamp binnen het frame.

Byte 4 heb ik ondertussen al zien veranderen. Lijkt per dag op te hogen. Was op 10 feb 0x4A, op 23 feb 0x57, verschil van 0x0D, 13 decimaal dus. Wellicht betekend dat dan dat byte 6 0x0F (15) voor 2015 staat...

Byte 12 lijkt nog steeds gerelateerd te zijn aan de staat van het GPS signaal. 0 bij afwezigheid, de eerste paar seconden 1, en 2 bij een stabiel signaal.

Helaas nog steeds geen spoor van de G sensor data :(

dvdouden
Die hard
 Bericht 
Byte 0 lijkt helaas toch niet de timezone te zijn; blijft op 1 staan ongeacht de ingestelde tijdzone :(

G sensor data dacht ik gevonden te hebben in een andere atom, maar helaas, dat bleek iets compleet anders te zijn... Ik ben ondertussen redelijk overtuigd dat het niet bij de GPS data opgeslagen zit, maar waar dan wel? :huh:

Pietert
Master
 Bericht 
Je kan er een mailtje naar help[at]datakam.com aan wagen. Die heeft het er toch redelijk succesvol uit gekregen :)

dvdouden
Die hard
 Bericht 
Ik heb de developer rechtstreeks gemaild, kijken of hij reageert. :thumb:
Heb ondertussen een progseltje gebouwd wat automagisch alle nieuwe filmpjes van de camera's af haalt en archiveert zodra ik ze aan m'n pc hang. Nu nog alle gegevens in een DBtje hangen ofzo en dan eens gaan bedenken wat ik er nou eigenlijk mee kan/wil :lol:

Pietert
Master
 Bericht 
Vraag dat maar aan Feitelijk! :lol:

dvdouden
Die hard
 Bericht 
Zat al te denken aan gemiddelde snelheden visualiseren op een kaartje, gemiddelde wachttijden bij stoplichten, waar ik het meeste moet remmen, enz :woop:

Feitelijk
Master
 Bericht 
Ah, het meantoall.sh scriptje!

Pietert
Master
 Bericht 
Doe anders even een scatterplotje van de gemiddelde rijsnelheid over de A13 :)

Brandjuh
Master
 Bericht 
dvdouden schreef:
Zat al te denken aan gemiddelde snelheden visualiseren op een kaartje, gemiddelde wachttijden bij stoplichten, waar ik het meeste moet remmen, enz

Lijkt me ook wel leuk!

Feitelijk
Master
 Bericht 
Pietert schreef:
Doe anders even een scatterplotje van de gemiddelde rijsnelheid over de A13

Mijn reistijden daar of de live snelheden?
Afbeelding

Pietert
Master
 Bericht 
Voor de live snelheden hoef je geen GPS data te verzamelen. (Daar waar dit hele topic over gaat)

Feitelijk
Master
 Bericht 
Maar ik rij daar eens in de twee weken terwijl ik dagelijks 1440 metingen op elk van de 80 lussen doe. Me beperken tot die gps data is dan wel een flinke ondersampling.

Op andere wegen kan ik me voorstellen dat je de 1Hz sampling van de GPS wil ja!

dvdouden
Die hard
 Bericht 
Helaas nog geen inhoudelijke reactie uit Rusland mbt de G sensor data :(

M'n camera-detecteer-en-kopieer-tooltje daarentegen werkt perfect 8) Nu nog een extra (externe) HD aanschaffen want met 13GB per dag gaat het best rap qua schijfruimte. :)

dvdouden
Die hard
 Bericht 
Jeuj! Vadim heeft gereageerd! :woop:
De G sensor gegevens worden 1x per seconde opgeslagen en komen rechtstreeks na het 30e GPS frame binnen de atom. 3x 4 byte. Hoe dat verder geinterpreteerd moet worden (en in wat voor eenheid het opgeslagen wordt) ga ik vanavond wel bekijken

8)
Afbeelding

Pietert
Master
 Bericht 
Misschien even re-encoden naar 720p

dvdouden
Die hard
 Bericht 
Dat is ook een optie, maar de externe schijf is al besteld :)
De database gaat ook wel aardig aantikken, ongeveer 20K records per uur. Qua ruimte valt het wel mee, maar om het allemaal te analyseren en wat zinnigs uit te halen wordt nog wel een uitdaging. Dat is niet echt mijn 'field of expertise' :x

De G sensor gegevens worden nu ook geëxporteerd, maar heel zinnig is het nog niet. Sowieso is de sample rate veel te laag om bruikbaar te zijn in bijvoorbeeld racerender. Ook lijkt de resolutie behoorlijk grof te zijn. Toch de ADXL345 eens onder het stof vandaan halen dan maar :kniktja:

Pietert
Master
 Bericht 
1 Hz is ook wel bijzonder. Ik meen toch wel plotjes te zien van die sensoren die een betere redolutie hebben.

dvdouden
Die hard
 Bericht 
Beetje raar, maar het klopt wel met wat DOD Player aan informatie toont. :( Jammer, ik geloof best dat de sensor een stuk vlotter is, een paar honderd Hz zou me niks verbazen, maar er wordt helaas maar 1 sample per seconde weggeschreven. 30Hz had een stuk bruikbaarder geweest.

Pietert
Master
 Bericht 
dvdouden schreef:
wel met wat DOD Player aan informatie toont

Hm, verdomd, je hebt gelijk. Ook in DATAKAM PLAYER is het inderdaad 1Hz
dvdouden schreef:
een paar honderd Hz zou me niks verbazen

Nouja, 100Hz dan. Blijft een goedkope sensor waarschijnlijk ;) Maar wel in ieder geval >1Hz.

Feitelijk
Master
 Bericht 
Pietert schreef:
Misschien even re-encoden naar 720p

Ik doe het zelfs naar 540 en met een mini bitrate. (na een maand)

dvdouden
Die hard
 Bericht 
Damnit, weer een afwijkende sample tegengekomen...
Code:
                      00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
YYYY-MM-DD HH:MM:SS   Tz?Sq Pa Key      Yr?   S?          ?  H  M  S  LatLatLatLatKey         LonLonLonLonKey         VelVel      HeaHea      ?? ??       YY YY MM DD Key?? Cs?Cs?

2015-03-05 16:31:22 - 01 A0 16 00 65 BE 0F 00 D6 17 01 00 02 10 1F 16 CD 1B 00 1F 00 41 54 43 DC 3C D4 02 00 30 30 31 B4 04 00 00 AA 44 00 00 B5 CE 00 00 DF 07 03 05 00 08 62 D1 lat:  52,0100813 lon:   4,7463644 vel:  12,04 hea: 17578 ???: 52917
2015-03-05 16:31:22 - 01 A1 17 00 65 BE 0F 00 D6 17 01 00 02 10 1F 16 F5 1A 00 1F 00 41 54 43 F1 3C D4 02 00 30 30 31 B8 04 00 00 AF 44 00 00 5D CE 00 00 DF 07 03 05 00 08 9E 7C lat:  52,0100597 lon:   4,7463665 vel:  12,08 hea: 17583 ???: 52829
2015-03-05 16:31:23 - 01 A2 18 00 65 BE 0F 00 D6 17 01 00 02 10 1F 17 9E D3 FD E2 00 41 54 43 79 CB 29 FF 00 30 30 31 28 E9 ED ED 5A 3B 00 00 EA 23 ED ED DF 07 03 05 00 08 00 00 lat: 380,8285598 lon: 428,0929145 vel: 39917919,12 hea: 15194 ???: -303225878
2015-03-05 16:31:23 - 01 A3 19 00 65 BE 0F 00 D6 17 01 00 02 10 1F 17 3C 19 00 1F 00 41 54 43 17 3D D4 02 00 30 30 31 D5 04 00 00 C0 44 00 00 B1 CD 00 00 DF 07 03 05 00 08 58 14 lat:  52,0100156 lon:   4,7463703 vel:  12,37 hea: 17600 ???: 52657
2015-03-05 16:31:23 - 01 A4 1A 00 65 BE 0F 00 D7 17 01 00 02 10 1F 17 5B 18 00 1F 00 41 54 43 30 3D D4 02 00 30 30 31 E2 04 00 00 B3 44 00 00 3C CD 00 00 DF 07 03 05 00 08 B8 0B lat:  52,0099931 lon:   4,7463728 vel:  12,50 hea: 17587 ???: 52540
2015-03-05 16:31:23 - 01 A5 1B 00 65 BE 0F 00 D7 17 01 00 02 10 1F 17 7C 17 00 1F 00 41 54 43 42 3D D4 02 00 30 30 31 DA 04 00 00 CB 44 00 00 EC CC 00 00 DF 07 03 05 00 08 9F 1D lat:  52,0099708 lon:   4,7463746 vel:  12,42 hea: 17611 ???: 52460


Ik dacht al, waarom komt m'n average speed op -9396 km/u uit in dat filmpje..

Pietert
Master
 Bericht 
Even testen op geldige lat-lon waarden ;) Eventueel in combinatie met ingestelde timezone. Al is dat listig :)

dvdouden
Die hard
 Bericht 
snelheid > mach 2 is sowieso al foute boel :lol: Maar zo te zien is m'n decryptiealgoritme niet helemaal correct. :schudnee:
Opvallend is ook dat de laatste 2 bytes 0 zijn. Toeval? Nah

dvdouden
Die hard
 Bericht 
Jeuj, weer wat gevonden :D
Bytes 8-11
inlezen als 32 bits int (byte 8 = LSB) en dan als volgt interpreteren:
bits 0-5 seconden
bits 6-11 minuten
bits 12-16 uren
Dit is de tijd zoals weergegeven op het scherm, dus met tijdzone correctie. Zo te zien is het niet rechtstreeks gerelateerd aan de timestamp van bytes 13-15, maar het lijkt erop alsof dit het tijdstip is waarop het sample weggeschreven wordt.

dvdouden
Die hard
 Bericht 
En dat verklaart bytes 4-7 ook gelijk :woop:
Eveneens als 32 bits int inlezen met byte 4 = LSB
Bits 0-4: dag vd maand (1-31)
Bits 5-8: maand (1-12)
Bits 9-19: jaar
4A BE 0F is dus 0x000FBE4A, ofwel 11111011111 0010 01010 (2015 2 10)

Dan blijven eigenlijk alleen nog de eerste byte en de laatste drie bytes onverklaard :D

dvdouden
Die hard
 Bericht 
Correctie op bytes 36-39: heading
Betreft 16 bit signed int. Alleen bytes 36 en 37 zijn van belang. Waarde is heading in centigraden, loopt dus van -17999 tot 18000 waarbij 0 noord is, -9000 oost, +9000 west en 18000 zuid. Bytes 38 en 39 zijn altijd 0.

En vwb de afwijkende samples:
Code:
2015-03-05 16:31:23 - 01 A2 18 00 65 BE 0F 00 D6 17 01 00 02 10 1F 17 9E D3 FD E2 A5 41 54 43 79 CB 29 FF DC 30 30 31 C5 04 00 00 5A 3B 00 00 07 CE 00 00 DF 07 03 05 08 00 31 31 lat: 380,8285598 lon: 428,0929145 vel:  12,21 hea: 15194 ???: 52743

Een seconde later wordt het correcte sample opgeslagen:
Code:
2015-03-05 16:31:23 - 01 A2 18 00 65 BE 0F 00 D6 17 01 00 02 10 1F 17 1A 1A 00 1F A5 41 54 43 04 3D D4 02 31 30 30 31 C5 04 00 00 BD 44 00 00 07 CE 00 00 DF 07 03 05 08 00 1F 4F lat:  52,0100378 lon:   4,7463684 vel:  12,21 hea: 17597 ???: 52743

Kwestie van oude samples overschrijven dus 8)
De rotzooi in het foute sample is trouwens data uit een voorgaand sample.

dvdouden
Die hard
 Bericht 
Feitelijk schreef:
Cool! 40-43 zal inderdaad de hoogte wel zijn.

Jep, het is inderdaad de hoogte in millimeters. Zit zo ongeveer rond de 50000 qua waarde, wat na WGS84 correctie redelijk overeenkomt met de werkelijke hoogte: 0 meter :lol:
Dan blijft tenslotte alleen byte 0 over (altijd 1) en bytes 48-49. 48 xor 49 is altijd 8...
Ondertussen ben ik er ook achter gekomen dat DOD er geregeld een zooitje van maakt. Soms worden samples maar half weggeschreven en bestaan ze voor de andere helft uit oude data van een vorig sample. Het beste is om te kijken of een sample in het volgende dataframe gewijzigd is, en dan de nieuwste waarden aan te houden.
Ook kan het voorkomen dat er na een paar seconden nog een sample verschijnt met een timestamp van een paar seconden terug. En het veld wat aangeeft of er een GPS signaal is (byte 12) is ook niet altijd te vertrouwen. Het is dus van belang een paar sanity checks te gebruiken om de rotzooi eruit te filteren.
Zo bereken ik nu per filmpje de standaard deviatie van latitude en longitude en keur een sample af als de deviatie meer dan vijf keer zo groot is als de standaard deviatie, maar alleen als de standaard deviatie groter is dan een bepaalde waarde (om false positives te voorkomen).

Anyway, 300K samples verzameld, tijd om te bedenken wat ik er mee ga doen :lol:

dvdouden
Die hard
 Bericht 
Voor de volledigheid: de G sensor data bestaat uit 8 bit signed integers. Een waarde van 20 lijkt ongeveer overeen te komen met 1 G / 9.8 M/s². Per seconde worden drie waarden opgeslagen. De eerste (X?) is zijwaartse acceleratie, positief is een bocht naar links, negatief een bocht naar recht. De tweede (Y?) is verticale acceleratie en zal meestal rond -20 zweven qua waarde (= zwaartekracht), in vrije val zal het wel 0 zijn, maar dat ga ik niet uitproberen :lol:
De derde waarde (Z?) is voorwaartse acceleratie, negatief is optrekken, positief is afremmen. Uiteraard hangt e.e.a. af van hoe de camera gemonteerd is, bij een rear cam zullen X en Z gespiegeld zijn qua waarden.

Voorbeeldje:
stilstand:
X en Z zijn niet 0 omdat de camera niet volledig waterpas hangt. Alle waarden moet je dus lezen relatief aan stilstand.
Code:
                                        X      Y      Z
FD 00 00 00 EC 00 00 00 FC 00 00 00    -3    -20     -4


acceleratie: (-Z)
Code:
                                        X      Y      Z
FD 00 00 00 EC 00 00 00 F6 00 00 00    -3    -20    -10


vol in de ankers: (+Z)
Code:
                                        X      Y      Z
FC 00 00 00 ED 00 00 00 0F 00 00 00    -4    -19     15


bochtje naar links: (+X)
Code:
                                        X      Y      Z
02 00 00 00 EC 00 00 00 F7 00 00 00     2    -20     -9


bochtje naar rechts: (-X)
Code:
                                        X      Y      Z
F4 00 00 00 EC 00 00 00 FE 00 00 00   -12    -20     -2


hobbeltje: (-Y)
Code:
                                        X      Y      Z
FD 00 00 00 E7 00 00 00 F8 00 00 00    -3    -25     -8


Rene Demmers
Die hard
 Bericht 
Ik loop er sterk aan te denken om bovengenoemde informatie op te nemen in de handleidingen van dashcams.
Dat zal het voor de klanten een stuk duidelijker maken....;-)

Good job mannen...!!!!

Pietert
Master
 Bericht 
Rene Demmers schreef:
mannen

Alle eer naar dvdouden, hoor ;)

Feitelijk
Master
 Bericht 
Rene Demmers schreef:
Dat zal het voor de klanten een stuk duidelijker maken...

:lol:
Ja, het gros van de vragen die je krijgt gaat hierover, ja?

Rene Demmers
Die hard
 Bericht 
Ik denk dat ik in dit topic de top aan kennis tref....! Vraag.....Ik heb de snelste computers....ik bekijk gemaakte dashcamfilmpjes. Of ik de filmpjes nou via de allernieuwste Samsung 4k TV afspeel, of de (slaapkamer) Panasonic HD ready plasma scherm (9 jaar oud) met SD sleuf en Player afspeel, of een Salora cheap (195 euro) 24 inch HD DV in de serre met een USB aansluiting....!

Alles gaat zonder haperingen, geen verschil tussen 30 frps of 60 frps. Alles draait "superglad". Ook niet als je een hoek omgaat wat op de computer vaak zorgt voor wat schokkerig beeld.
Waarom kan een computer (i7 processor met een van de beste videokaarten) het beeld niet zo goed weergeven als zelfs de simpelste televisie? Dus schokvrij en vloeiender?
De Mini 0801 geeft een scherper beeld bijvoorbeeld op TV dan de 8000 euro kostende camera's van "blik op de weg"....!
Wie heeft daar een antwoord op?

Ik kan het even niet beredeneren/uitleggen/begrijpen....!
Wie doet een voorzet....?
Feitelijk? Pietert? DVDouden?

Feitelijk
Master
 Bericht 
Welke player gebruik je op de i7?

Pietert
Master
 Bericht 
Alles staat of valt met de gebruikte codecs. ffmpeg (en dus VLC player) zouden het zonder moeite moeten kunnen. Het vervelende is dat het vaak puur op CPU gaat en de videokaart nauwelijks wordt aangesproken. Als de implementatie dan ook nog eens single-core is, kan het soms wel gaan stotteren.

Griffin
Master
 Bericht 
Rene Demmers schreef:
Alles gaat zonder haperingen, geen verschil tussen 30 frps of 60 frps. Alles draait "superglad". Ook niet als je een hoek omgaat wat op de computer vaak zorgt voor wat schokkerig beeld.
Waarom kan een computer (i7 processor met een van de beste videokaarten) het beeld niet zo goed weergeven als zelfs de simpelste televisie? Dus schokvrij en vloeiender?

Even afgezien van de oplossing op je PC... "Welkom tot de wondere wereld van de embedded elektronica" (voelt zich net Chriet Titulaer soms).

Er zijn een paar redenen voor dat die TV het een stuk beter doet dan je PC. Maar uiteindelijk komt het allemaal neer op maar 1 ding: het realtime gedrag van het hele systeem. Met de term "real time" bedoelen we dan niet "net zo snel als de echte tijd", maar een systeem dat een gegarandeerde responstijd heeft.

Een PC is heel sterk in raw processingpower. Hij kan super snel rekenen - mits'ie niet continue onderbroken wordt om allerlei andere taken te doen. Een muispointer bijwerken, data van een harde schijf trekken, ethernet pakketjes afhandelen, en zo voorts. Al die interruperende taken maken een PC waar windows op draait tot een onvoorspelbaar ding. Terwijl video wegschrijven nu juist een exacte timing vereist - als je het beeld niet precies synchroon naar je buffers schrijft krijg je last van zaken als tearing, beeldverlies en stotteringen.

In je TV zit hardware die dat allemaal voor z'n rekening neemt. Synchronisatie wordt afgedwongen door hardware; er is andere hardware die bijvoorbeeld het lezen van SD kaart afhandelt. Die hardware kan zelfs fysiek ander geheugen gebruiken dan de hardware die voor de beeldopbouw zorgt (principe: geef ieder soort verkeer z'n eigen rijstrook en de gemiddelde snelheid van alle verkeer neemt toe en wordt voorspelbaar).

Dus: andere hardware, specialisatie op de taak, realtime gedrag van het OS. Daarom kan een TV dat wel en jouw supersnelle PC niet.

dvdouden
Die hard
 Bericht 
Wat Griffin zegt: dedicated hardware vs generic hardware. Overigens doen vrijwel alle mid range en high end TVs aan post processing om het beeld vloeiender te maken, opschalen naar 100Hz, MPEG artifact reduction en dat soort magie.

Verder zou je eens kunnen kijken wat je CPU doet als je aan het afspelen bent via Task Manager/Taakbeheer. Zowel Quicktime als VLC zorgen hier voor ongeveer 15%punt verhoging bij het afspelen (i5, dualcore met hyperthreading).

Griffin
Master
 Bericht 
dvdouden schreef:
Overigens doen vrijwel alle mid range en high end TVs aan post processing om het beeld vloeiender te maken, opschalen naar 100Hz, MPEG artifact reduction en dat soort magie.

...en dat zijn fantastische bewerkingen om in hardware te supporten. Moderne TV's vormen dan ook een van de grootste markten voor FPGA's.


dvdouden schreef:
Zowel Quicktime als VLC zorgen hier voor ongeveer 15%punt verhoging bij het afspelen (i5, dualcore met hyperthreading).

VLC speelt alles, maar is niet bepaald efficiënt in mijn beleving. Ik ben voor 90% overgestapt op MediaPlayer Classic: https://mpc-hc.org/

Rene Demmers
Die hard
 Bericht 
Feitelijk schreef:
Ja, het gros van de vragen die je krijgt gaat hierover, ja?

Zeker... :lol:

Feitelijk schreef:
Welke player gebruik je op de i7?

Ik gebruik zo ongeveer elke player die er bestaat en op de Mac en op de Windows 8 Pc. Het enige wat behoorlijk vloeiend afspeelt, althans op beide computers is de 1080P 60fps opnamen van de Vico Marcus 3.
Maar nogmaals op TV, of je nou filmpjes van 30- of 60 FPS afspeelt, en van welk merk camera dan ook, het is vloeiend. Zelfs de beelden van de MINI 0801, goed beeld, maar net iets minder dan een DOD, Vico of 0805, zien er ongeloofelijk scherp uit op een 55 inch 4K TV. Daar kan "blik-op-de-weg" een voorbeeld aan nemen. :lol:

Griffin schreef:
"Welkom tot de wondere wereld van de embedded elektronica"

Thanks voor jullie uitleg, dvdouden Idem....! Denkt een stuk duidelijker zo. Bijna nooit bekeek ik beelden op de TV, maar kan het iedereen aanraden. Kijkt een stuk prettiger. (f)

 Pagina 1 van 1 [ 48 berichten ] 


Wie is er online

Leden op dit forum: Geen geregistreerde gebruikers en 1 gast


Je mag geen nieuwe onderwerpen in dit forum plaatsen
Je mag niet antwoorden op een onderwerp in dit forum
Je mag je berichten in dit forum niet wijzigen
Je mag je berichten niet uit dit forum verwijderen
Je mag geen bijlagen toevoegen in dit forum

Zoek…         
privacy policy