eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plPrawoGrupypl.soc.prawoDura lex, sed lexRe: Dura lex, sed lex
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
    e.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.
    farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-m
    edia.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!feeder.cambriumusenet.n
    l!feed.tweaknews.nl!posting.tweaknews.nl!fx12.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> <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> <og_2N.11$glg4.1@fx11.ams1>
    <uihrc6$gmg$4$Shrek@news.chmurka.net>
    <p...@4...net>
    <uij6en$cdk$4$Shrek@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: 64
    Message-ID: <ZRe3N.35$bGkf.4@fx12.ams1>
    X-Complaints-To: a...@t...nl
    NNTP-Posting-Date: Fri, 10 Nov 2023 00:31:53 UTC
    Organization: Tweaknews
    Date: Fri, 10 Nov 2023 00:31:53 GMT
    X-Received-Bytes: 4283
    Xref: news-archive.icm.edu.pl pl.soc.prawo:843719
    [ ukryj nagłówki ]

    On 2023-11-09, Shrek <...@w...pl> wrote:
    > W dniu 09.11.2023 o 12:55, J.F pisze:
    >
    >>> Żaden - strumień wideo w tej samej kompresji będzie mniejszy niż
    >>> odpowiadający zbiór zdjęć. W skrajenie pesymistycznym przypadku taki sam.
    >>
    >> Ale jakosc moze byc całkiem inna.

    W praktyce jest inna, ale zdecydownie nie "całkiem". Bez powiekszania
    szczegółów, nie odróżnisz. Piszę to ponownie na podstawie doświadczenia
    z kamerami poklatkowymi, gdzie przez 2-3 lata pracy zebrało mi się
    sporo tych zdjęć i postanowiłem je "spakować" w x265.

    Jak ktoś ma czas i ochotę to popularny ffmpeg potrafi w obie strony. Tak
    się ekstrahuje ramki do obrazków w najprostszym podejściu:

    ffmpeg -i filmik out%03d.jpg

    %03d wprowadza cześć decymalną do nazwy pliku, tu 3 cyfry z dopełnieniem
    zerami.

    w drugą np. tak:

    ffmpeg -r 25 -i out%03d.jpg -c:v libx264 -pix_fmt yuv420p out.mp4

    Oczywiście tam jest kupa parametrów, która wpływa na jakoś i w jedna i w
    drugą stronę, więc trzeba to podopieszczać jak już sie ktos tym zacznie
    bawić.

    > Mówię o tej samej jakości. Minutowy strumień 1 kl/s będzie mniejszy lub
    > taki sam jak 60 zdjęć skompresowanych tym samym algorytmem kompresji.

    Zawsze będzie mniejszy bo nie będzie zawierał jakiś nagłowków i
    metadanych dla każdej pełnej ramki. To tez nie jest ten sam algorytm
    kompresji. Dobra, to jak się mamy doedukowywać to spróbujmy tak:

    Chyba wszystkie obecnie uzywane powszechniej standardy kodowania kodują
    obraz w segmentach. Taki segent nazywa się Group Of Pictures (GOP) i
    składa się z sekwencji indywidualnych ramek. Ramki są zasadniczo 2-ch
    rodzajów: (1) zawierajace pełny obraz (podobnie jak w izolowanym
    zdjęciu), to są tzw. I-ramki (I-frames); (2) ramki zawierajace tzw obraz
    "przewidziany" (predicted), to P-ramki i B-ramki.

    GOP może wyglądać tak: IPPPPPPPPI

    I zawiera pełen obraz. P zawiera informacje co się zmieniło od
    poprzedzającej ją ramki. W zalezności od kodeka, tam moga też być
    informacje o wektorze zmian, więc to nie jest tylko przestrzenny jpeg, a
    trochę więcej.

    Ramki typu B, są jak P (predicted) ale zarówno w stosunku do
    poprzedzającej jak i następującej. Umozliwia to, jak sie można domyślic
    jeszcze wyższą kompresję.

    No więc jak nam sie urwie zapis na IPPPP to nadal można odtworzyć pełen
    obraz z ostatniej klatki P. Dane do tego są zawarte w poprzedzającej
    ramce I i wszystkim poprzedzających P. Jak sie urwie na B, to zdaje się
    pełnego odtworzyć się nie da, ale częściowy zapewne tak.

    Idea takiego kodowania (GOP) jest stara i siegajaca mpeg2, więc nie
    tylko 264 i 265.

    --
    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