W dniu 05.03.2019 o 21:10, Sh-rek pisze:
> Z całym szacunkiem, bądź przy jego braku - twoje słowa są nic nie warte
> - już nie raz pokazałeś, że jak walniesz bzdurę, to będziesz jej bronił
> jak niepodległości. Jak mam do wyboru, "że coś w życiu widziałeś" i na
> podstawie tego twierdzisz, że "większość profesjonalnych stystemów..."
> kontra standardy przemysłowe, to nie mam żadnej wątpliwości kto nie ma racji


szrek idzie w zaparte, nie potrafi dotrzymać raz danego słowa "EOT",

ale co się dziwić, szrek nie potrafi powiesić TV na ścianie:))))))))

--
George Orwell :

"If liberty means anything at all, it means the right to tell people
what they do not want to hear"

do góry

On 2019-03-05, J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Shrek" napisał w wiadomości grup
> Nawet jesli nie sa to zapisane JPG w osobnych plikach,
> to skoro obraz tak skacze, to znaczy, ze w strumieniu sa osobne
> obrazki.

Każda ramka jest de facto obrazkiem tyle, że mniej lub bardziej pełnym
bo brakuje w nim tego co jest w poprzedniej lub kolejnej ramce. Skakanie
wpływa na to ile się zmienia więc co prawda możesz argumentować, że
zmienia się wszystko ale wymaga to pewnych założeń - taka argumentacja
jest jedynie poprawna jeśli kompresja międzyklatkowa jest wyłącznie
pomiędzy pełnymi obszarami klatkek, co jest MZ nieprawdą. W sytuacji
dynamicznej zmiany pomiędzy klatkami są albo wynikiem zmian w statycznym
kadrze, albo w zmianą kadru (przesunięcia X-Y) albo obu. W tym pierwszym
wypadku nadal mamy statyczną część (poza ektremalnymi sytuacjami), w
drugim rowniez, ale nie zgadza się już X i Y nie? To przesunięcie XY
jest uwzględniane, a dalej już leci normalnie. Zarzuć goglu "Motion
search" video codec. ZCWidze, to algorytmy nawet nie rozróżniają tych
2ch scenariuszy, a starają się wykrywać zmiany (ruch).

> No i ciekawe - zapisali to jako obrazki, czy zrobili kompresje typu
> H.264 dla np co 10-tego obrazka z kamery.

Zapisali strumień, czyli np. jeden pełny obrazek co 28 niepełnych.

> Ale jak widac - sa rejestratory, w ktorych obraz nie skacze, i sie
> chwala 25 kl/s.

Kompletnie nie rozumiem, jak możesz nadal nie rozumieć, że ilość klatek
na sekundę ma tu dokładnie zerowe znaczenie. I nie wiem już jak Ci to
wytłumaczyć skoro poprzedie tłumaczenia nic nie dały :)

--
Marcin

do góry

Dnia Tue, 05 Mar 2019 23:01:47 GMT, Marcin Debowski napisał(a):
> On 2019-03-05, J.F. <j...@p...onet.pl> wrote:
>> Użytkownik "Shrek" napisał w wiadomości grup
>> Nawet jesli nie sa to zapisane JPG w osobnych plikach,
>> to skoro obraz tak skacze, to znaczy, ze w strumieniu sa osobne
>> obrazki.
>
> Każda ramka jest de facto obrazkiem tyle, że mniej lub bardziej pełnym
> bo brakuje w nim tego co jest w poprzedniej lub kolejnej ramce. Skakanie
> wpływa na to ile się zmienia więc co prawda możesz argumentować, że
> zmienia się wszystko ale wymaga to pewnych założeń - taka argumentacja
> jest jedynie poprawna jeśli kompresja międzyklatkowa jest wyłącznie
> pomiędzy pełnymi obszarami klatkek, co jest MZ nieprawdą.

W monitoringu istotnie moga dominowac dosc stale obrazy.

> W sytuacji
> dynamicznej zmiany pomiędzy klatkami są albo wynikiem zmian w statycznym
> kadrze, albo w zmianą kadru (przesunięcia X-Y) albo obu. W tym pierwszym
> wypadku nadal mamy statyczną część (poza ektremalnymi sytuacjami), w
> drugim rowniez, ale nie zgadza się już X i Y nie? To przesunięcie XY
> jest uwzględniane, a dalej już leci normalnie. Zarzuć goglu "Motion
> search" video codec. ZCWidze, to algorytmy nawet nie rozróżniają tych
> 2ch scenariuszy, a starają się wykrywać zmiany (ruch).

No i tu jest kolejna sprawa - male przesuniecia szuka sie szybko, duze
... to jest kosztowne.

Choc akurat ... kamera nadal dostarcza klatki czesto - mozna sledzic
jak sie cos przesuwa, a tylko zrzucac co 10 klatek.


>> No i ciekawe - zapisali to jako obrazki, czy zrobili kompresje typu
>> H.264 dla np co 10-tego obrazka z kamery.
>
> Zapisali strumień, czyli np. jeden pełny obrazek co 28 niepełnych.

Byc moze ... czyli np jeden pelny obrazek co 14s, a co pol sekundy
niepelny ...

>> Ale jak widac - sa rejestratory, w ktorych obraz nie skacze, i sie
>> chwala 25 kl/s.
> Kompletnie nie rozumiem, jak możesz nadal nie rozumieć, że ilość klatek
> na sekundę ma tu dokładnie zerowe znaczenie. I nie wiem już jak Ci to
> wytłumaczyć skoro poprzedie tłumaczenia nic nie dały :)

Ja to rozumiem, tylko
-duze zmiany obrazu, ktore zachodza w czasie dluzszego czasu,
powoduja, ze metody kompresji miedzyramkowej sa mniej efektywne,

-co moze powodowac, ze nawet nie starali sie ich wdrozyc.

Nawet masz stosowny standard M-JPEG.

J.

do góry

W dniu 06.03.2019 o 00:01, Marcin Deb-owski pisze:
> Kompletnie nie rozumiem, jak możesz nadal nie rozumieć, że ilość klatek
> na sekundę ma tu dokładnie zerowe znaczenie. I nie wiem już jak Ci to
> wytłumaczyć skoro poprzedie tłumaczenia nic nie dały

im dalej w las tym więcej deb-ów:))))))
--
George Orwell :

"If liberty means anything at all, it means the right to tell people
what they do not want to hear"

do góry

On 2019-03-05, J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Shrek" napisał w wiadomości grup
> dyskusyjnych:q5m3ri$9mg$...@n...news.atman.pl...
> W dniu 05.03.2019 o 13:30, J.F. pisze:
>>> Nawet jesli nie sa to zapisane JPG w osobnych plikach,
>>> to skoro obraz tak skacze, to znaczy, ze w strumieniu sa osobne
>>> obrazki.
>
>>Nie - nie znaczy. EOT.
>
> https://www.youtube.com/watch?v=-A8-uStnLL4
>
> Ten samochod nie jedzie, tylko przeskakuje.
>
> Myslisz, rejestrator wybral co 10-ta klatke z kamery, po czym zrobil z
> nich film, skompresowany na ogolnych zasadach np H.264 czy MPEG ?

Kamera zarejestrowała pierwszą pełną klatkę, umieściła w buforze
(pamięci). Po 1s pobrała następną, dodała do bufora. I tak dalej n-razy
dla n=<GOP (group of pictures). Gdy n>GOP, kamera zakrzyknęła, hej, mój
sprzetowy enkoderze h264, masz tu robotę! Enkoder się obudził,
przeciągnał, przeciścił gardło (od kiedy po piętach deptał mu h265, pił
więcej) po czym zakasał rękawy i zaczął pobierać obrazki z bufora
analizując różnice pomiędzy nimi (motion search) i usuwając z ramek
innych niż pierwsza, wszystko co uznał za takie same w sąsiadujących
ramkach. Po skonczonej odetchnął. Należy dodać, że kamera mądrą kobietą
była i potrafiła zaznaczyć w strumieniu, że oto idzie film, który nalezy
odtwarzać z częstotliwością 1k/s.

--
Marcin

do góry

Użytkownik Robert Tomasik r...@g...pl ...

>> Serio istotą i problemem do roztrząsania jest różnica w
>> sformułowaniach między "działaniem", a "interwencją"?
>
> Tak. Istotą. Bo to nieostre. Prościej jak już pisałem rejestrować
> wszystko z wyjątkiem przerw i tyle. Bo zawsze będzie problem, w
> którym momencie włączyć, czy wyłączyć kamerę.

No po prostu mega problem... wow...

--
Pozdrawia... Budzik
b_ud_zi_k_6_1 na poczta kropka onet kropka pl (adres antyspamowy, usuń także "_")
"Życie jest cierpieniem, pieniądze morfiną"

do góry

On 2019-03-05, J.F. <j...@p...onet.pl> wrote:
> Dnia Tue, 05 Mar 2019 23:01:47 GMT, Marcin Debowski napisał(a):
>> W sytuacji
>> dynamicznej zmiany pomiędzy klatkami są albo wynikiem zmian w statycznym
>> kadrze, albo w zmianą kadru (przesunięcia X-Y) albo obu. W tym pierwszym
>> wypadku nadal mamy statyczną część (poza ektremalnymi sytuacjami), w
>> drugim rowniez, ale nie zgadza się już X i Y nie? To przesunięcie XY
>> jest uwzględniane, a dalej już leci normalnie. Zarzuć goglu "Motion
>> search" video codec. ZCWidze, to algorytmy nawet nie rozróżniają tych
>> 2ch scenariuszy, a starają się wykrywać zmiany (ruch).
>
> No i tu jest kolejna sprawa - male przesuniecia szuka sie szybko, duze
> ... to jest kosztowne.

To się zgadza i nikt nie twierdzi, że takie skoki sprzyjają kompresji,
ale jednak jest ona MZ nadal znacząca. Częściowo może to też wynikać z
faktu, że przed tą międzyklatkową kompresją idzie też zapewne kompresja
typu jpeg (odwróconych kosinusów czy jak jej tam). Efektem tej kompresji
jest to, że całe obszary się ujednolicają - gdzieś były 64 różne
piksele, teraz wszystkie są takie same. Nie na darmo te dekodery mają
ustawialną jakość wynikową gdzie na jednym końcu jest masakra (duża
kompresja) a na drugim placebo (brak kompresji).

Jak Ci bardzo zalezy to mogę zrobić prosty eksperyment i wziąć jakąś
dynamiczną scenę, (ro)złożyć ją na obrazki i zapisać z różnym kodowanie.
Albo lepiej powiedzieć Ci jak to zrobić? :) Masz jakiegoś Linuksa na
chodzie?

> Choc akurat ... kamera nadal dostarcza klatki czesto - mozna sledzic
> jak sie cos przesuwa, a tylko zrzucac co 10 klatek.

Można, bo to w sumie bez znaczenia czy robi 1 zdjecie na s. czy 25 a
wybieramy co 25.

> Byc moze ... czyli np jeden pelny obrazek co 14s, a co pol sekundy
> niepelny ...

Np.

> Ja to rozumiem, tylko
> -duze zmiany obrazu, ktore zachodza w czasie dluzszego czasu,
> powoduja, ze metody kompresji miedzyramkowej sa mniej efektywne,

Mniej relatywnie do własnych możliwości, ale niekoniecznie do braku
kompresji międzyklatkowej w ogóle.

> -co moze powodowac, ze nawet nie starali sie ich wdrozyc.
>
> Nawet masz stosowny standard M-JPEG.

Dosyć historyczny. Natomiast jak czyimś celem jest perfekcyjnej jakości
zdjęc to w drugą stronę też się tak łatwo faktycznie nie da. Mam kilka
kamer poklatkowych, które sobie rejestrują chmurki i inne podobne
rzeczy. Krajobraz, sceny generalnie statyczne. Taka kamera robi jedno
zdjęcie co 10s i zapisuje do pliku. 6:30 do 19:00, ca 4500 zjęć na dobę
na kamerę i zżera ca 10-12GB miejsca na dysku. Pomyślałem sobie, że będę
te zdjęcia przechowywał jako film. Złożę je h265 a potem jak będzie
potrzeba rozłożę. No i nie da się. Jakakolwiek sensowna kompresja
(powiedzmy do 3-5GB) widać wyraźnie utratę jakości w porównaniu z
oryginałami. W szczegółach, ale zawsze.

--
Marcin

do góry

On 2019-03-05, J.F. <j...@p...onet.pl> wrote:
> byc moze jeden scalak 16 kamer kompresuje.
> Albo jak piszesz - przeniesli do kamery ... ale BNC ciagle jest w
> uzyciu.

Są modele NVR, że wszystko kompresuje NVR, są hybrydowe, są takie co nic
nie kompresują. 16 kamer po BNC to nie jest w sumie takie duże wyzwanie,
bo to raz, to jest maks D1 (stare TV pal/ntsc) czyli mała klatka, dwa,
że w tych tańszych NVR, z którymi miałem do czynienia, na ogół tylko
część kanałow mogła nagrywać w pełnej rozdzielczości, więc np. trzeba
było wybrać 8ch D1 a 8 połówka D1.

--
Marcin

do góry

On 2019-03-05, Budzik <b...@p...o.n.e.t.pl.nie.spam.oj> wrote:
> Użytkownik Robert Tomasik r...@g...pl ...
>
>>> Serio istotą i problemem do roztrząsania jest różnica w
>>> sformułowaniach między "działaniem", a "interwencją"?
>>
>> Tak. Istotą. Bo to nieostre. Prościej jak już pisałem rejestrować
>> wszystko z wyjątkiem przerw i tyle. Bo zawsze będzie problem, w
>> którym momencie włączyć, czy wyłączyć kamerę.
>
> No po prostu mega problem... wow...

Jak widac tak :) Ja bym prawde mówiąc rejestrował wszystko, bo później
się okaże, ze ktoś cos przetworzył literalnie i uznał, że nie trzeba.

--
Marcin

do góry

W dniu 06.03.2019 o 00:30, J.F. pisze:

> Ja to rozumiem, tylko
> -duze zmiany obrazu, ktore zachodza w czasie dluzszego czasu,
> powoduja, ze metody kompresji miedzyramkowej sa mniej efektywne,
>
> -co moze powodowac, ze nawet nie starali sie ich wdrozyc.

Ale one są defaltowo na pokładzie zarówno kamery jak i rejestratora.
Więc nie ma co nawet5 implementować - gotowe rozwiązanie już jest.

Shrek

do góry