Forfatter |
Emne Søg Emne-funktioner
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 12:11 |
Jeg læste lige lidt op på det: Hvis CEC ikke virker, kan det næsten kun være fordi ben 13 i HDMI stikket ikke er forbundet. Det kan man naturligvis aldrig afvise hvis vi taler ultra-billige kineser-kabler - men Tech-link burde nu være fuldt forbundet. Det er et krav i HDMI specifikationen at alle stik er forbundne, så hvis kablet til ben 13 er sparet væk, så må de slet ikke kalde det HDMI.
|
|
Hessi
Guld medlem
Oprettet: 24-December-2006
Sted: Århus N, DK
Status: Offline
Point: 1528
|
Sendt: 15-November-2011 kl. 12:14 |
Otto J skrev:
Jeg er ikke sikker på at jeg kan finde en konkret kilde, men det er ikke dét jeg fandt frem til sidst jeg gravede i det, og det giver ikke mening at det skulle kunne lade sig gøre - det ville indebære et delay i én eller anden udstrækning. HDMI overførslen er real-time. |
Læser de virkelig ikke forud og gemmer i en buffer?
Hvis ikke giver det jeg skrev i hvert fald ingen mening, eller det kan i hvert fald ikke lade sig gøre.
|
|
|
Skovbo
Super bruger
Oprettet: 17-Januar-2010
Sted: Glamsbjerg
Status: Offline
Point: 351
|
Sendt: 15-November-2011 kl. 12:16 |
Otto J skrev:
Jeg vil ikke afvise at jeg kan tage fejl, men jeg kunne godt tænke mig at se det i praksis - er det helt konsekvent at tech-link kablerne ikke virker? Har de forskellige modelvarianter, og i så fald hvilken model ved du der er problemer med? Så vil jeg prøve at købe sådan en fætter. |
Jeg vil lige undersøge nærmere på jobbet i morgen :) I starten kørte vi med flere typer kabler som vi solgte - Tech Link (mellem varriant) og så vores eget brand (High End) Vi endte med at stoppe med at sælge Tech Linken fordi kunderne klagede over Sync'en ikke virkede.
Vi har også "No Name" i vægge og små steder - og disse No Name virker heller ikke med sync'en. De er også endnu ringere end Tech Link (prismæssigt)
|
|
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 12:22 |
Hessi skrev:
Læser de virkelig ikke forud og gemmer i en buffer?
|
Hvis de gjorde, hvordan skulle HDMI så kunne bruges til f.eks. computerspil?
Eller rettere, jo der læses til en FIFO buffer (der som navnet angiver er First In, First Out, dvs. der kan ikke læses baglæns og gensendes pakker der mangler), men det er minimalt hvad der ligger af delay dér, og det giver ikke mulighed for gensendelse af pakker.
Bemærk at det kun er HDMI overførslen vi taler om her. Hvis vi nu taler om f.eks. aflæsningen af en DVD eller BD skive, så læses der muligvis til en buffer, med mulighed for genlæsning (det sker ikke normalt for CD, men jeg ved ikke på rygraden om det sker ved DVD - den skal jeg lige slå op...). Men der er også den meget væsentlige forskel på de to typer data, at data fra en DVD/BD skive til decoderen er komprimerede og skal viderebehandles, mens data via HDMI er ukomprimerede.
|
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 12:24 |
Skovbo skrev:
Jeg vil lige undersøge nærmere på jobbet i morgen :) I starten kørte vi med flere typer kabler som vi solgte - Tech Link (mellem varriant) og så vores eget brand (High End) Vi endte med at stoppe med at sælge Tech Linken fordi kunderne klagede over Sync'en ikke virkede.
Vi har også "No Name" i vægge og små steder - og disse No Name virker heller ikke med sync'en. De er også endnu ringere end Tech Link (prismæssigt)
|
Hvis du har noget til at ligge i en skuffe som du ikke bruger, må du da gerne sende et... Tech Link er mere interessant end noname, da jeg som sagt vil påstå at det er et brud på licensen at sælge et kabel der ikke er fuldt monteret (og jeg kan ikke se at en simpel kvalitetsforskel kan betyde at CEC ikke kan overføres, da det er ret små datamængder der er tale om dér).
|
|
tvkartoffel
Guld medlem
Oprettet: 18-Juni-2009
Sted: Denmark
Status: Offline
Point: 1998
|
Sendt: 15-November-2011 kl. 12:31 |
Otto J skrev:
Hessi skrev:
Og så lige en sidste ting, som jeg absolut ikke er sikker på men mener jeg har hørt i et program på DR1 hvor de forklarede HDMI-teknologien og lavede målinger af HDMI-kabler. Jeg husker (kan huske forkert) de snakkede om at HDMI bruger en protokol der ligner lidt TCP-IP/Internet protokollen. Altså hvis en pakke har får forkert cheksum så sender modtageren info tilbage til senderen om at pakken skal sendes igen (eller at den ikke blev modtaget korrekt). Og det sker asynkront indtil det ikke kan nås længere og så springes pakken over. |
Jeg er ikke sikker på at jeg kan finde en konkret kilde, men det er ikke dét jeg fandt frem til sidst jeg gravede i det, og det giver ikke mening at det skulle kunne lade sig gøre - det ville indebære et delay i én eller anden udstrækning. HDMI overførslen er real-time. |
Så vidt jeg har kunne google mig til ligger svaret sådan lidt imellem. Det er ret svært stof så jeg kan have taget fejl, men hvis man kigger i HDMI manualen så ser det ud til at der er indbygget datarecovery. Forstået på den måde at hvis fejlraten ikke kommer over et vist niveau kan motagesiden selv korrigere for manglende/forkerte bits. Det ser ikke ud til at pakker gensendes. Se nederst side 46 og prøv ellers at søge på f.eks "error correction" i dette dokument fra hdmi.org. MVH
|
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 12:40 |
tvkartoffel skrev:
Så vidt jeg har kunne google mig til ligger svaret sådan lidt imellem. Det er ret svært stof så jeg kan have taget fejl, men hvis man kigger i HDMI manualen så ser det ud til at der er indbygget datarecovery. Forstået på den måde at hvis fejlraten ikke kommer over et vist niveau kan motagesiden selv korrigere for manglende/forkerte bits. Det ser ikke ud til at pakker gensendes. |
Det var også dét jeg skrev på side 4 Der er fejlkorrektion, men kun så længe checksummen kan genskabe den enkelte pakke. Hvis en pakke ikke kan genskabes, kasseres hele pakken, den kan ikke sendes igen. Dermed kan det ikke sammenlignes med ethernet-overførsel.
|
|
tvkartoffel
Guld medlem
Oprettet: 18-Juni-2009
Sted: Denmark
Status: Offline
Point: 1998
|
Sendt: 15-November-2011 kl. 12:46 |
UPS. Fik vist kun læst det med et halvt øje ;-) MVH
|
|
Hessi
Guld medlem
Oprettet: 24-December-2006
Sted: Århus N, DK
Status: Offline
Point: 1528
|
Sendt: 15-November-2011 kl. 12:46 |
Otto J skrev:
Hvis de gjorde, hvordan skulle HDMI så kunne bruges til f.eks. computerspil? |
Nårh ja, men de kunne vel bruge forskellige protokoller til forskellige applikationer?
Lige netop med spil er der en buffer (på GPU'en) der gemmes i, men det er fra bufferen HDMI'en får data'en. Når først HDMI'en har fået data'en er der intet at stille op hvis bitmønstret bliver ødelagt på vej til skærmen.
Så det er vel samme måde DVD/Blu-Ray afspilning foregår på.
hmm.... ærgerligt de ikke bruger forskellige protokoller til de forskellige applikationer. Er ellers ikke voldsom svært at lave sådan en asynkron protokol, hvis båndbredden ellers er der.
EDIT: Bufferen, bliver kun brugt hvis spillet understøtter post-processing, og der gøres brug heraf.
Redigeret af Hessi - 15-November-2011 kl. 12:49
|
|
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 12:58 |
Hessi skrev:
Nårh ja, men de kunne vel bruge forskellige protokoller til forskellige applikationer?
Lige netop med spil er der en buffer (på GPU'en) der gemmes i, men det er fra bufferen HDMI'en får data'en. Når først HDMI'en har fået data'en er der intet at stille op hvis bitmønstret bliver ødelagt på vej til skærmen.
Så det er vel samme måde DVD/Blu-Ray afspilning foregår på. |
Præcis.
Hessi skrev:
hmm.... ærgerligt de ikke bruger forskellige protokoller til de forskellige applikationer. Er ellers ikke voldsom svært at lave sådan en asynkron protokol, hvis båndbredden ellers er der. |
Jeg har svært ved at se behovet. HDMI er en AV protokol, det andet giver kun mening hvis du vil bruge det til data, og det har HDMI with Ethernet en helt separat protokol til. Det giver ikke mening at have en asynkron protokol til AV overførsel (asynkron i denne sammenhæng ikke at forveksle med f.eks. asynkron USB audio...)
|
|
Otto J
Platin medlem
Branchemedlem
Oprettet: 04-Marts-2007
Sted: Denmark
Status: Offline
Point: 11218
|
Sendt: 15-November-2011 kl. 13:08 |
Otto J skrev:
Bemærk at det kun er HDMI overførslen vi taler om her. Hvis vi nu taler om f.eks. aflæsningen af en DVD eller BD skive, så læses der muligvis til en buffer, med mulighed for genlæsning (det sker ikke normalt for CD, men jeg ved ikke på rygraden om det sker ved DVD - den skal jeg lige slå op...). Men der er også den meget væsentlige forskel på de to typer data, at data fra en DVD/BD skive til decoderen er komprimerede og skal viderebehandles, mens data via HDMI er ukomprimerede.
|
Jeg slog iøvrigt lige DVD's fejlkorrektion op (jeg har DVD Demystified af Jim Taylor stående på hylden, så jeg kan ikke lige citere), og nej der er ingen mulighed for at læse sectors igen. Der er en ret kraftig fejlkorrektion, der indebærer at op til 2800 bytes i træk kan være væk (hvilket svarer til 6 milimeter på skiven), uden tab af data efter fejlkorrektion, men herefter træder decoderens fejlkorrektion i kraft, og du får pixelleringer.
|
|
Hessi
Guld medlem
Oprettet: 24-December-2006
Sted: Århus N, DK
Status: Offline
Point: 1528
|
Sendt: 15-November-2011 kl. 13:28 |
Otto J skrev:
Jeg har svært ved at se behovet. HDMI er en AV protokol, det andet giver kun mening hvis du vil bruge det til data, og det har HDMI with Ethernet en helt separat protokol til. Det giver ikke mening at have en asynkron protokol til AV overførsel (asynkron i denne sammenhæng ikke at forveksle med f.eks. asynkron USB audio...) |
Hvis nu modtageren har en buffer den gemmer i, som har en kø-implementering hvor rækkefølgen kan ændres, så kunne man jo lave en asynkron protokol så de fejl som vi har snakket om kan rettes op netop ved at modtagerens buffer og senderens buffer kommunikere, og bufferen i modtageren kan ændre rækkefølge (indsætte et sted hvor der er "hul"). Dermed kan man minimere fejlraten drastisk og nærmest eliminere det. Og når det er bufferne der skal leveres fra og til bliver læsningen af skiven ikke påvirket.
Tilmed kan man ved at gemme i buffere lave drev der har meget lav omdrejningstal så de larmer mindre, og så bare lade den læse derudaf og lave asynkrone pakkesendinger (hvis nødvendigt).
Måske er det for meget for at rette op på en i forvejen lav fejlrate.
Drømmer jeg for meget?
Redigeret af Hessi - 15-November-2011 kl. 13:35
|
|
|