-
Data: 2013-04-07 14:43:35
Temat: Re: laczenie scen MP4 w jedna calosc bez zadnych konwersji
Od: Krzysztof Halasa <k...@p...waw.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Janko Muzykant <j...@w...pl> writes:
> Dżizas, co za uparta menda i na dodatek ślepa...
Nie wiem co (kto?) to jest Dżizas, ale współczuję utraty wzroku.
Jeśli przeczytanie i zrozumienie całości jest dla Ciebie problemem, to
najważniejsze pytanie specjalnie zaznaczyłem.
> Tu mamy powyższy obrazek przekonwertowany do YV12 4:2:0. Teraz weź
> sobie próbnik barw z szopa, gimpa czy czegokolwiek i porównaj
> chrominancję każdej pary w poszczególnych kwadratach - _SĄ_IDENTYCZNE_
> (konkretnie kolejno: 59st, 181st i dwa razy po 300st). Cała informacja
> o kolorze poszczególnych pikseli przepadła.
> http://as.elte-s.com/temp/video/3/yv12_420.png
Bez próbnika to widać. Co chcesz w ten sposób pokazać? Przecież
dokładnie o tym pisałem, i jest to jeden z powodów, dla którego (jak sam
zauważyłeś) stop klatka z filmu H.264 ma gorszą jakość od analogicznego
zdjęcia. To teraz zastosuj tę wiedzę w praktyce:
> Sposób kodowania barw, jak sama nazwa wskazuje (4:2:0) zaniża
> rozdzielczość chrominancji dwukrotnie (liniowo), więc siatka o rastrze
> jednego piksela zostanie uśredniona kolorystycznie, co widać na
> przykładzie i czego podważyć się nie da.
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
VVVVVVVVVVVVVVV
No pewnie że tak. Dokładnie tak jak napisałem. To dlaczego w Twoim
obrazku, którego używasz jako dowodu na brak odpowiedniego pogorszenia
jakości (realnego obrazka, nie testowych faktur), tak _NIE_ _JEST_?
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
VVVVVVVVVVVVVVV
> Tu teoria napisana przez mądrzejszych ode mnie:
> http://en.wikipedia.org/wiki/YUV#Y.27UV422_to_RGB888
_conversion
^^^
Jak sam, mam nadzieję, widzisz ("422"), akurat ten akapit nie jest na
temat (podkreśliłem ze względu na Twoje problemy ze wzrokiem). Spróbuj
może tu:
http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y
.27V12_or_YV12.29_to_RGB888_conversion
^^^
BTW są aparaty/kamery video, które potrafią zrobić H.264 w YUV422.
Raczej nie tzw. "amatorskie".
> Może już czas podkulić ogon i zakończyć bezzasadne czepialstwo?
No pewnie Einsteinie, od dawna to sugerowałem.
Tak w ogóle, niekoniecznie osobiście dla Ciebie: utrata informacji przy
konwersji RGB->YUV420 (oraz podobnych, tzn. takich, które redukują
rozdzielczość chrominancji) jest zależna przede wszystkim od tego, ile
mamy i potrzebujemy tej informacji, oraz jaka jest docelowa
rozdzielczość. Jeśli informacji potrzebujemy dużo mniej niż docelowa
rozdzielczość, to utrata jakośći z tym związana jest mała (np. gdybyśmy
konwertowali typowy obrazek 36 MPix do druku na A4). Im mniejsza
rozdzielczość docelowa i im większe wymagania jakościowe, tym efekt jest
gorszy. Np. przy konwersji 1920x1080 z RGB (lub np. YUV444) do YUV420
efekt jest wredny "fotograficznie", ale nie jest wielkim problemem
w przypadku filmu oglądanego na monitorze/TV.
W przypadku PAL (720x576 lub 704x576, pomijam P/I) efekt zaczyna robić
się widoczny (a czasem tylko dość wredny) także w zastosowaniach
telewizyjnych. Typowo nie jest to jednak tragedia, natomiast jeśli
potraktujemy to jako zdjęcie, to już niestety jest źle.
W rozdzielczości mniejsze niż PAL nie wnikam, bo w praktyce nikt tego do
podobnych zastosowań od dawna nie używa.
Wiesz już dlaczego pytałem o rozdzielczość (1920x1200) i jak ją
uzyskałeś?
Jeśli to jest trudne, to może posłużę się analogią: Informacja o kolorze
ma swoją charakterystykę częstotliwościową podobnie jak dźwięk.
Zmniejszenie częstotliwości próbkowania dźwięku ze 192 kHz do 96 kHz nie
jest słyszalne (przynajmniej przeze mnie). Przy redukcji 48 kHz ->
24 kHz wytniesz część wysokich tonów, ale wciąż nawet jakaś tam muzyka
nie będzie brzmiała tragicznie (subiektywnie, ktoś może się nie
zgodzić). Zredukuj teraz z telefonicznych 8 kHz do 4 kHz i bedziesz miał
porażkę.
Tak samo jest także z rozdzielczością bitową (np. przetworników).
24 -> 12 bitów w audio - niewielka różnica (pod warunkiem sensownego
poziomu sygnału). 8 bitów (kiedyś robiliśmy do pecetów takie proste
DACe "Covox") -> 4 bity = porażka.
To są truizmy dla osób, które zajmują się zawodowo (zresztą nieco
bardziej na serio amatorsko także) dźwiękiem i obrazem cyfrowym, ale
zdaję sobie sprawę, że wiele innych osób może tego nie rozumieć.
--
Krzysztof Halasa
Następne wpisy z tego wątku
- 07.04.13 15:00 Janko Muzykant
- 07.04.13 16:03 Krzysztof Halasa
- 07.04.13 16:22 Janko Muzykant
- 07.04.13 17:32 Krzysztof Halasa
- 07.04.13 18:32 Janko Muzykant
- 07.04.13 21:47 Krzysztof Halasa
- 07.04.13 22:48 Janko Muzykant
- 09.04.13 23:37 Janko Muzykant
- 10.04.13 12:26 mt
- 10.04.13 18:27 Mikolaj Machowski
- 10.04.13 23:39 Krzysztof Halasa
- 11.04.13 20:50 Sylwester Zarębski
- 12.04.13 21:32 Krzysztof Halasa
- 13.04.13 00:51 Sylwester Zarębski
- 13.04.13 22:05 Krzysztof Halasa
Najnowsze wątki z tej grupy
- Nikon D5500 i wyzwalanie migawki
- Canon 550D
- EOS 600D i balans bieli w filmach
- EOS 90D i sentymenty
- Skanowanie: Canon MG2550S vs HP OfficeJet 6950
- czas exif a czas modyfikacji pliku
- karta SD po formacie odzyskiwanie zdjęć i filmów
- Chess
- Vitruvian Man - parts 7-11a
- Eltec nie zyje?
- Steve McCurry
- Light - lajkowe klasyki od Chinczykow
- Forum o Sony serii A (alfa)?
- obrobka RAW na konputerze
- Sklejanie bracketowanych JPGów
Najnowsze wątki
- 2024-11-25 Karty przedpłacone (podarunkowe) Google Play - pytanie do korzystających
- 2024-11-26 wina Tóska
- 2024-11-26 Rewolucja/Rewelacja!
- 2024-11-25 grupa ożyła ;)
- 2024-11-24 Być jak Clint
- 2024-11-24 Rura kanalizacja konceptu Franke = problem
- 2024-11-25 Wrocław => Lead Java EE Developer <=
- 2024-11-25 Warszawa => Business Development Manager - Network and Network Securit
- 2024-11-25 Kraków => Programista Full Stack (.Net Core) <=
- 2024-11-25 Lublin => Senior PHP Developer <=
- 2024-11-25 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=
- 2024-11-25 Warszawa => ECM Specialist / Consultant <=
- 2024-11-25 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-11-25 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2024-11-25 Lublin => Inżynier Serwisu Sprzętu Medycznego <=