eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plPrawoGrupypl.soc.prawoDura lex, sed lex › Re: Dura lex, sed lex
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
    e.net!feeder.erje.net!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.ne
    t!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-medi
    a.com!news.highwinds-media.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!f
    eeder.cambriumusenet.nl!feed.tweaknews.nl!posting.tweaknews.nl!fx11.ams1.POSTED
    !not-for-mail
    Newsgroups: pl.soc.prawo
    From: Marcin Debowski <a...@I...zoho.com>
    Subject: Re: Dura lex, sed lex
    References: <uhlkjm$3s24g$1@dont-email.me> <uhnt82$3ds$10$RTomasik@news.chmurka.net>
    <8SW%M.90299$pFl3.24237@fx05.ams1>
    <uhqtp6$2ui$11$RTomasik@news.chmurka.net>
    <%Lg0N.26806$2Dq2.5412@fx08.ams1>
    <uhsnqd$2ui$32$RTomasik@news.chmurka.net>
    <RRl0N.27795$pZKa.16091@fx04.ams1>
    <uhsq89$2uh$25$RTomasik@news.chmurka.net>
    <uhtiir$rkl$3$Shrek@news.chmurka.net> <MGA0N.73967$6L_4.56412@fx14.ams1>
    <ui0c58$ju8$1$Shrek@news.chmurka.net>
    <137fxbix0c90w$.gd40x47g5pb7$.dlg@40tude.net>
    <bnW0N.78478$3_a2.10970@fx12.ams1>
    <ui2hk2$2ui$58$RTomasik@news.chmurka.net>
    <BEf2N.79590$U4F3.28755@fx09.ams1>
    <uidn13$3a4$6$RTomasik@news.chmurka.net>
    <uidp71$2ak$4$Shrek@news.chmurka.net> <fPz2N.29133$dr77.6158@fx01.ams1>
    <uiejij$krl$2$RTomasik@news.chmurka.net>
    <WVA2N.29135$dr77.5271@fx01.ams1>
    <uig61m$krm$5$RTomasik@news.chmurka.net>
    <fuqz57i3pspw.lr7lwslbdkeo$.dlg@40tude.net>
    <uih2u1$krl$16$RTomasik@news.chmurka.net> <pgV2N.9$4Fc2.3@fx14.ams1>
    <uihb3a$krm$18$RTomasik@news.chmurka.net>
    User-Agent: slrn/1.0.3 (Linux)
    Mime-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit
    Lines: 30
    Message-ID: <og_2N.11$glg4.1@fx11.ams1>
    X-Complaints-To: a...@t...nl
    NNTP-Posting-Date: Thu, 09 Nov 2023 05:39:32 UTC
    Organization: Tweaknews
    Date: Thu, 09 Nov 2023 05:39:32 GMT
    X-Received-Bytes: 3286
    Xref: news-archive.icm.edu.pl pl.soc.prawo:843682
    [ ukryj nagłówki ]

    On 2023-11-09, Robert Tomasik <r...@g...pl> wrote:
    > W dniu 09.11.2023 o 00:58, Marcin Debowski pisze:
    >> Cudów nie ma, ze przy określonej kompresji nagle ma się więcej danych.
    >
    > To nie tak. Powiedzmy na dysku masz zdjęcia w rozdzielczości 1920 x 1080
    > pikseli. Rejestrator zrzuca to do rozdzielczości 640 x 480 pikseli. Jak
    > sobie zgrasz film, to z niego możesz wyciągnąć zdjęcie w rozdzielczości
    > 640 x 480 pikseli. Ale jak wyciągniesz fotkę z nośnika to dostaniesz
    > 1920 x 1080. I czasem to pozwala na odczytanie numeru rejestracyjnego,
    > podczas gdy z klatki 640 x 480 nie odczytasz. No już prościej nie potrafię.

    No ale do tego potrzebne są te zdjęcia albo 2 równoległe strumienie o
    2ch różnych rozdzielczościach. Takie strumienie są standardem, ale zapis
    wyłącznie zdjęciami, n-kanałów z rozsądną częstotliwością, to naprawdę
    trudno mi uwierzyć, że jest w powszechnym użyciu. Zwyczajnie zdjęcia
    zajmują od cholery miejsca, nawet takie 2MP.

    Taka klatka FHD:
    https://www.smartcity.co.nz/wp-content/uploads/2021/
    03/how-to-reduce-traffic-congestion-in-cities.jpg

    Przy jakości na poziomie 10%, rejestracji w drugim rzędzie juz się nie
    odczyta. Plik ma ca 60kb. 1 kanał, 25kl/s => 125MB na dobę. Da się
    jeszcze od biedy odczytać przy 20% => 200MB/kanał. Pod 1TB przy 8
    kanałach. Akcetowalna od biedy jakość jest dopiero przy 50% i jakiś
    340MB na kanał. Jaki sens zapisywać to w plikach obrazków gdy nawet
    h.264 da z 10-30x mniejszy plik wynikowy o lepszej jakości poszczególnych
    klatek przekonwertowanych na obrazki?

    --
    Marcin

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1