dbtv artefakti

[sali]

sa čisto softversko korisničke strane, kad zbog slabog digitalnog signala u sliku uleti niz žutih kvadratića, jel to može značit grešku implementacije protokola, ili grešku u samom protokolu? znači, do kvadratića dođe kad se signal zbog greške ne dekomptimira uredno

meni bi bilo logično kod greške, umjesto faličnog žutog kvadratića koji kvari sliku, na to mjestu prikatati ZADNJE uspjesno primljen frame za tu poziciji,, nije idealno, ali bi puno manje bolo oči, ono kad na zelenoj podlozi šume iskoči žuti kvadratić, pa radije bih prekopirao prethodni (prethodnog framea) zeleni kvadratić

zar ne?

[volatile]

sali kaže:

sa čisto softversko korisničke strane, kad zbog slabog digitalnog signala u sliku uleti niz žutih kvadratića, jel to može značit grešku implementacije protokola, ili grešku u samom protokolu? znači, do kvadratića dođe kad se signal zbog greške ne dekomptimira uredno

meni bi bilo logično kod greške, umjesto faličnog žutog kvadratića koji kvari sliku, na to mjestu prikatati ZADNJE uspjesno primljen frame za tu poziciji,, nije idealno, ali bi puno manje bolo oči, ono kad na zelenoj podlozi šume iskoči žuti kvadratić, pa radije bih prekopirao prethodni (prethodnog framea) zeleni kvadratić

zar ne?

Nema to nikakve veze sa "implementacijom protokola". Ne znam čak ni što bi to značilo u ovom kontekstu.
Odašiljač emitira transport stream (TS). Paketi su 188 ili 192 bajta, ovisno o verziji. Uslijed slabog signala na tvojoj lokaciji može doći do gubitka paketa. Izgubljeni paket se ne može vratiti nazad. Algoritam za dekompresiju slike u tom slučaju pokušava dekomprimirati frame sa krivim podacima. Rezultat su makroblokovi koji se satoje od krivih boja i zato vidiš kradratiće raznih boja.

Kopiranje prethodnog makrobloka nema nikakvog smisla, jer ne znaš je li prethodni bio dobar. A čak i ako je, to bi degradiralo performanse uz nikakvu korist, jer konačni frame ionako neće biti dobar.

To ti je maksimalno pojednostavljen odgovor.

[sali]

pa idej a je znati jeli dekompresija uspješna, ako nije , pametnije je uzeti bitmap prethodne uspješne dekompresije toga područja slike

to mi izgleda tako jednostavno za popravit kvalitet ugođaja kod lošeg signala

to se i golim okom vidi da je loš kvadratić upao, a da bi onaj iz prethodne slike bio bolje rješenje

[volatile]

Pročitaj još jednom prethodni odgovor, ali sa razumijevanjem ovaj put.

[MrBlc]

Postoji već rješenje za taj problem:
a.) Svaki paket ima checksum
b.) Svaki paket sadrži, uz vlastiti sadržaj, i sadržaj sljedećeg ili prethodnog paketa koji je kompresiran visokim stupnjem kompresije.

Prijemnik, ako detektira oštećen paket, odbacuje ga i reproducira prethodno / naknadno primljenu visokokompresiranu kopiju.

Ovakav sustav rada ima smisla prilikom prijenosa putem UDP/IP protokola jer se pojedinačni paketi mogu izgubiti, pogotovo kad se radi o VOIP pozivu ili videopozivu, kod kojeg nema buffera, pa kašnjenje paketa dođe na isto kao da nije ni primljen.

Međutim, kod TV-a bi takav sustav samo smanjivao propusnost jer je karakteristika sustava takva da rijetko dolazi do gubitka pojedinačnih paketa - ili je signal dobar ili gubiš više paketa u nizu.

[sali]

za prijenos video signala [tv] nebih radio višestruko slanje uz prethodni ili naredni paket

samo kod dekompresije paketa treba znati da nije bila uspješna
taj paket se odnosi na kvadratiće ekrana na koordinati (x,y)
ako paket nije uspješno dekomprimiran, prikazati prethodnu sliku iz kvadratića sa koordinate (x,y)

sveukupno, vizuelna greška bi VJEROVATNO bila manja nego da se prikaže felerični žuti kvadratić

to je ovako laičko razmišljanje kada gledam tv prijenos, a slab signal
ja bih kao gledalac bio sretniji da mu na mjestu žutog kvadratića televizor prikaže komadić prethodne slike koja je bila uredna, iz toga razloga sam pomislio da je to nedorečenost protokola, i da bi se mogla popraviti

drugo je pitanje, ako uređaj koji radi dekompresiju i zna da paket nije dobar, nema pristupa ranije komponiranoj prethodnoj slici, a takođe nemožer niti saznanje o greški dekompresije proslijediti van, gornjoj aplikaciji

[MrBlc]

Uređaj bi mogao spremati u buffer prethodni frame i raditi na takav načina, ali i dalje je to nepotrebna komplikacija. Ako se tebi ošteti jedan (brojkom 1) paket, mala je šansa da ćeš i primjetiti zbog tromosti oka. Ako je smetnja veća, onda imaš značajnih problema sa signalom i tu ti onda ovaj algoritam ne može pomoći.

[volatile]

MrBlc kaže:

Postoji već rješenje za taj problem:
a.) Svaki paket ima checksum
b.) Svaki paket sadrži, uz vlastiti sadržaj, i sadržaj sljedećeg ili prethodnog paketa koji je kompresiran visokim stupnjem kompresije.

a.) Checksum, odnosno CRC služi za provjeru pristiglog paketa. CRC ti ne može reći je li paket izgubljen. Tome služi continuity counter. Ali, counter je dužine 4 bita, pa nije apsolutno pouzdan.

b.) Paket sadrži isključivo vlastiti sadržaj. Za dekompresiju P i B frejmova su potrebni prethodni frejmovi, a kod B frejma i idući. Ali, trenutni paket i dalje NE sadrži te podatke.

MrBlc kaže:

Prijemnik, ako detektira oštećen paket, odbacuje ga i reproducira prethodno / naknadno primljenu visokokompresiranu kopiju.

To ovisi o implementaciji. Ako CRC nije dobar, vjerojatno će ga zanemariti, ali neće reproducirati ništa dok ne stignu novi paketi. Rezultat je smrznuti frejm na ekranu.

MrBlc kaže:

Ovakav sustav rada ima smisla prilikom prijenosa putem UDP/IP protokola jer se pojedinačni paketi mogu izgubiti, pogotovo kad se radi o VOIP pozivu ili videopozivu, kod kojeg nema buffera, pa kašnjenje paketa dođe na isto kao da nije ni primljen.

Međutim, kod TV-a bi takav sustav samo smanjivao propusnost jer je karakteristika sustava takva da rijetko dolazi do gubitka pojedinačnih paketa - ili je signal dobar ili gubiš više paketa u nizu.

UDP i DVB-T se ponašaju identično kod gubitka paketa. Jednostavno ih nema i gotovo. Nikakvi prethodni paketi i nikakvo ponavljanje ne pomaže, pa se zato ni ne koristi.

[MrBlc]

volatile kaže:

a.) Checksum, odnosno CRC služi za provjeru pristiglog paketa. CRC ti ne može reći je li paket izgubljen. Tome služi continuity counter. Ali, counter je dužine 4 bita, pa nije apsolutno pouzdan.

Točno, ali ipak nisam želio toliko ulaziti u detalje jer u kontekstu ove rasprave nije bitno.

volatile kaže:

b.) Paket sadrži isključivo vlastiti sadržaj. Za dekompresiju P i B frejmova su potrebni prethodni frejmovi, a kod B frejma i idući. Ali, trenutni paket i dalje NE sadrži te podatke.

Ok, ali moj komentar se referencirao na eventualnu mogućnost nadogradnje protokola koja bi mogla umanjiti artefakte kod lošeg singala.

volatile kaže:

To ovisi o implementaciji. Ako CRC nije dobar, vjerojatno će ga zanemariti, ali neće reproducirati ništa dok ne stignu novi paketi. Rezultat je smrznuti frejm na ekranu.

Pa pričamo o eventualnim alternativnim implementacijama koje bi smanjile primjetne greške, te o opravdanosti istih.

volatile kaže:

UDP i DVB-T se ponašaju identično kod gubitka paketa. Jednostavno ih nema i gotovo. Nikakvi prethodni paketi i nikakvo ponavljanje ne pomaže, pa se zato ni ne koristi.

Kod nekih implementacija kod kojih je bitno ublažiti gubitak informacije pri gubitku paketa se koristi ono što sam gore opisao. To nije na razini UDP-a, već na aplikacijskoj razini.