Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:ht1fnh$g3$1@news.onet.pl...
> Marcin Wasilewski wrote:
>> Poczytaj sobie co robią dzisiejsze TV. Myślisz, że rendering ramki
>> pośredniej na podstawie dwóch ramek w 1920x1080, da się zrobić bez
>> zauważalnego opóźnienia?
> A czy przypadkiem nie jest tak, że obliczenia pośrednie wynikają wprost z
> hintów kodowania MPEG (obiekt przemiesza się o 4 piksele w prawo, więc na
> pośredniej ramce jest przemieszczony o 2 piksele itd). Jakoś nie chce mi
> się wierzyć że budowanie ramek pośrednich polega na analizie grafiki
> rastrowej dwóch pełnych obrazów, w końcu obraz jest zapisany "prawie"
> wektorowo w MPEGu a już na pewno wektorowo opisany jest ruch. To
> _znacznie_ upraszcza algorytmy.

No tylko tu mówimy o analogowym PAL-u, z którego będziesz miał MPEG, jak
sobie go zdigitalizujesz (to i tak trzeba zrobić), a później enkoderem na
ten MPEG zakodujesz. Natomiast jeśli masz na myśli sygnał cyfrowy z
zewnętrznego źródła w MPEG, to coś w tym jest. Tylko, że jeszcze i z
sygnałem postanalogowym coś trzeba zrobić. Czyli trzeba stworzyć albo dwa
różne bloki, albo jeden uniwersalny i znowu nam się sprawa komplikuje.
Zresztą to właśnie na analogowym obrazie jest największe opóźnienie, bo jak
TV LCD używasz jako monitora do kompa to te opóźnienia są niezauważalne.
Inna sprawa, że w tym trybie wiele "ulepszaczy" zwyczajnie się nie włączy.

do góry

Marcin Wasilewski wrote:
>>> Poczytaj sobie co robią dzisiejsze TV. Myślisz, że rendering ramki
>>> pośredniej na podstawie dwóch ramek w 1920x1080, da się zrobić bez
>>> zauważalnego opóźnienia?
>>
>> A czy przypadkiem nie jest tak, że obliczenia pośrednie wynikają
>> wprost z hintów kodowania MPEG (obiekt przemiesza się o 4 piksele w
>> prawo, więc na pośredniej ramce jest przemieszczony o 2 piksele itd).
>> Jakoś nie chce mi się wierzyć że budowanie ramek pośrednich polega na
>> analizie grafiki rastrowej dwóch pełnych obrazów, w końcu obraz jest
>> zapisany "prawie" wektorowo w MPEGu a już na pewno wektorowo opisany
>> jest ruch. To _znacznie_ upraszcza algorytmy.

> No tylko tu mówimy o analogowym PAL-u

Nie. Wyżej wsponiałeś o rodzielczości która nie jest PALowska.

> cyfrowy z zewnętrznego źródła w MPEG, to coś w tym jest. Tylko, że
> jeszcze i z sygnałem postanalogowym coś trzeba zrobić.

Przeciętny program do zrzucania obrazu z PAL dostaje dwa półobrazy i w
czasie rzeczywistym robi deinterlace (nie mam na myśli naiwnego
przelatania lini tylko coś ambitnego). Zakładając że wyrabia się z tym
najzwyklejszy procek 1GHz to wcale się nie zdziwie jak specjalizowany
hardware oprócz tego wyliczy dwie ramki pośrednie zjadając x10 mniej mocy.

do góry

W dniu 2010-05-19 23:09 Sebastian Biały napisał(a):

> Przeciętny program do zrzucania obrazu z PAL dostaje dwa półobrazy i w
> czasie rzeczywistym robi deinterlace (nie mam na myśli naiwnego
> przelatania lini tylko coś ambitnego). Zakładając że wyrabia się z tym
> najzwyklejszy procek 1GHz to wcale się nie zdziwie jak specjalizowany
> hardware oprócz tego wyliczy dwie ramki pośrednie zjadając x10 mniej mocy.

Z dwóch sąsiednich półobrazów ciężko zrobić sensowną klatkę. Zauważ że
półobrazy pochodzą prawie zawsze z różnych chwil czasowych (no chyba że
akurat w telewizji leci film kinowy) - i do zmontowania całej klatki
przydaje się też kolejny (trzeci) półobraz: łącznie z chwil t-1, t, t+1.
Wtedy można już starać się aproksymować ruch obiektów.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

Adam Dybkowski wrote:
>> Przeciętny program do zrzucania obrazu z PAL dostaje dwa półobrazy i w
>> czasie rzeczywistym robi deinterlace (nie mam na myśli naiwnego
>> przelatania lini tylko coś ambitnego). Zakładając że wyrabia się z tym
>> najzwyklejszy procek 1GHz to wcale się nie zdziwie jak specjalizowany
>> hardware oprócz tego wyliczy dwie ramki pośrednie zjadając x10 mniej
>> mocy.

> Z dwóch sąsiednich półobrazów ciężko zrobić sensowną klatkę.

Nie o to chodzi. Mam na mysli, ze skoro uniwersalny procesor za pare $
jest w stanie robić minimum tej czynności, to specjalizwoany układ za
pare $ zrobi znacznie więcej. W tym również detekcje ruchu na wielu
obrazach interlace złapanych również w przyszłości/przeszłości.

Tylko że jestem na stanowisku że taka technologia to jakas pomyłka.
Ideałem było by gdyby to stacja nadawcza decydowala co jest w obrazie
istotne a co nie i gdzie się przemieściło (oglądając mecz naprawdę mam
głęboko w poważaniu szczegóły trybuny, wole żeby mi _piłki_ nie
rozmywał). MPEG daje takie możliwości. W jego przypadku opóźnienie nie
będzie potrzebne, lub będzie potrzebne znacznie mniejsze (włacznie z
regulowanym) bo dane znacznie lepiej wyliczyć mając wektorowy opis ruchu
i wyswietlić z aproksymacją pomiedzy klatkami jesli telewizor jest
faktycznie w stanie tak szybko wyswietlać. No i oczywiście tryb
progressive tylko pomaga, żadnego zgadywania i półobrazów jak to teraz
się robi. Ciągle nie mogę pojąć dlaczego tryb interlace jest domyslnym
sposobem działania TV w czasach MPEG i LCD. Nawet mój dekoder N
kretyńsko podskakuje wyświetlając menu na LCD podpiety przez HDMI ...

> przydaje się też kolejny (trzeci) półobraz: łącznie z chwil t-1, t, t+1.
> Wtedy można już starać się aproksymować ruch obiektów.

To oczywiścte, dlatego algorytmy deinterlace bazujące na dwoch
półobrazach zawsze rozmywają go bo innego wyjścia raczej nie ma. Sens
mojej wypowiedzi jest jednak w tym, że taką czynność (bazującą na dwóch
półobrazach i _nietrywialnym_ rozmywaniu) robi z palcem w d...
najsłabszy uniwersalny procesor na rynku w czasie rzeczywistym
korzystając z BT878 którego cena jest chyba symboliczna. Dlatego nie
bałbym się o moc obliczeniową ukladow specjalizowanych do takich zadań,
potrafią więcej niż głupie dwa półobrazy poskładane do kupy.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:ht1k2e$gos$1@news.onet.pl...

>> No tylko tu mówimy o analogowym PAL-u

> Nie. Wyżej wsponiałeś o rodzielczości która nie jest PALowska.

Ale zauważ, że telewizor FullHD taką ma rozdzielczość natywną matrycy i
chciał, czy nie chciał MUSISZ mu tego biednego PALa do tej rozdzielczości
natywnej przeliczyć. Inaczej będziesz miał obraz na powierzchni 20% ekranu.

do góry

Marcin Wasilewski wrote:
>>> No tylko tu mówimy o analogowym PAL-u
>> Nie. Wyżej wsponiałeś o rodzielczości która nie jest PALowska.
> Ale zauważ, że telewizor FullHD taką ma rozdzielczość natywną matrycy
> i chciał, czy nie chciał MUSISZ mu tego biednego PALa do tej
> rozdzielczości natywnej przeliczyć.

Jednak pytanie brzmi czy przeliczanie ramek pośrednich odbywa się po
stronie PAL czy HD. Stawiam, że tam gdzie prościej ;)

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:ht1r22$56e$1@news.onet.pl...

>> Ale zauważ, że telewizor FullHD taką ma rozdzielczość natywną matrycy
>> i chciał, czy nie chciał MUSISZ mu tego biednego PALa do tej
>> rozdzielczości natywnej przeliczyć.

> Jednak pytanie brzmi czy przeliczanie ramek pośrednich odbywa się po
> stronie PAL czy HD. Stawiam, że tam gdzie prościej ;)

Zapewne producent robi to tak aby było bardziej jednolicie i jeśli
istnieje taki moduł dla sygnału FullHD, to nie ma sensu dublować go
prostszym dodatkowym układem (no chyba, że z uwagi na zużycie energii). A
prawda jest taka, że producenci bardzo chronią swoje "Know How"* i możemy
sobie tylko gdybać....

Ostatnio potrzebowałem odszukać specyfikację obsługi kart SDHC oraz SDXC
i niestety okazuje się, że bez 1000$, to zapomnij. :) Jak dla amatora, to
trochę drogo :)

do góry

Marcin Wasilewski wrote:
>> Jednak pytanie brzmi czy przeliczanie ramek pośrednich odbywa się po
>> stronie PAL czy HD. Stawiam, że tam gdzie prościej ;)

> Zapewne producent robi to tak aby było bardziej jednolicie i jeśli
> istnieje taki moduł dla sygnału FullHD

Po stronie FullHD istnieje zazwyczaj odmiana MPEG (wiec wyliczanie ramek
pośrednich jest kompletnie inne). Co ciekawe wyliczanie ramek pośrednich
PAL jest w zasadzie bardzo blisko znanego z MPEGa "motion compensation"
i nie można wykluczyć że jakiś fragment enkodera jest stosowany do tego
celu.

Cóż, gdybanie ;)

do góry

On Thu, 20 May 2010 01:08:43 +0200, Sebastian Biały wrote:
>Marcin Wasilewski wrote:
>> Ale zauważ, że telewizor FullHD taką ma rozdzielczość natywną matrycy
>> i chciał, czy nie chciał MUSISZ mu tego biednego PALa do tej
>> rozdzielczości natywnej przeliczyć.
>
>Jednak pytanie brzmi czy przeliczanie ramek pośrednich odbywa się po
>stronie PAL czy HD. Stawiam, że tam gdzie prościej ;)

Prosciej moze byc zrobic telewizor pod MPEG i dodac chipa kompresji
PAL, ale to bedzie drogo :-)

Zmiana rozdzielczosci nie wymaga wcale duzego opoznienia. Raptem o
pare linii.
Gorsze bedzie usuwanie przeplotu .. o ile w ogole potrzeba go usuwac,
chyba tylko na potrzeby stop-klatki.
No i praca w 100Hz itp

J.

do góry

On Wed, 19 May 2010 21:44:59 +0200, Marcin Wasilewski wrote:
>Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>> Ale Ty bys musial miec 100 stopni. Co one mialyby co robic ?
>
>A ty uważasz, że to taka nierealna liczba?

Od strony wykonawczej realna. Tylko troche kosztowna, chyba.

Od strony zapotrzebowania nie wiem czy realna.

>Chciałem ci
>uświadomić, że nawet 8-bitowy procesorek o niewielkiej mocy, z 4KB SRAM-u
>ciężko, dziś zrobić bez pipeline (no może powiedzmy, że z nim dużo prościej
>i taniej),

Odnosze wrazenie ze nie bardzo wiesz co piszesz :-)

>a taki TV to nie jest coś co posiada kilka kilo RAMU.
>Sama pamięć ekranu to coś około 6 MB (przy FullHD).

A wprowadzajac 4s opoznienia wprowadzasz zapotrzebowanie na kolejne
megabajty.

J.

do góry