Jaký bitrate pro převod 50i na50p z FH D kamery?
Kamerou (Panasonic HC V500)natočeno video 50i při 17Mb/s. Jaký bitrate nastavit pro převod do 50p? (Pro CRF 17 dostávám 34Mb/s pro CRF 19 pak 27Mb/s s VMAF 99.3 (mezi sebou)).
Zkoušel jsem ten převod dělat i v posledním TMPGENC a nevidím rozdíl na 4k TV mezi 12Mb/s a 35Mb/s (VMAF 92.7)
Zkoušel jsem ten převod dělat i v posledním TMPGENC a nevidím rozdíl na 4k TV mezi 12Mb/s a 35Mb/s (VMAF 92.7)
Ci vidis (respektive mozes vidiet) rozdiel medzi 12 a 35 zavisi od obsahu vo videu. Pre staticku scenu moze byt overkill aj tych 12mbit. K tomu prave sluzi urcovanie podla CRF, teda podla pozadovanej kvality, kde bitrate kolise podla toho, kolko je nutne pre dosiahnutie zvolenej ciselnej CRF kvality.
Pokial ma ist o archivnu kompresiu kludne tam nastav tych CRF 17, bitrate bude vysoky, ale o par rokov si nebudes nadavat, ze si nezmyselne setril miestom na ukor kvality.
Pokial ma ist o archivnu kompresiu kludne tam nastav tych CRF 17, bitrate bude vysoky, ale o par rokov si nebudes nadavat, ze si nezmyselne setril miestom na ukor kvality.
Naprostý souhlas s vivid.sk, pokud jde o archivaci, raději zachovat vyšší datový tok. Já mám v enkodéru x264 nastavený profil pro archivaci s CRF=16 s krátkými GOPy (keyint=30) a pro distribuci a přehrávání profil s CRF=22 s dlouhými GOPy (keyint=250).
Velkou důležitost má také zvolená metoda deinterlace 50i na 50p, protože se 50% dat dopočítává.
Velkou důležitost má také zvolená metoda deinterlace 50i na 50p, protože se 50% dat dopočítává.
FHD video(tančící a skákající předškolní děcka, točeno venku za dobrého světla) dlouhé 2:24 originál(17Mb/s 50i) ma 230MB při CRF17 v 50p je velikost 603MB(CRF19 470MB, v TMPGENC (High precision deinterlace filter) mám velikosti 205MB 50-kvalita a 470MB 62-kvalita). Kladu si otázku, jestli to není uměle nabobtnané při CRF17. Dle selské úvahy by to mělo být +- 2x vetší??
(TMPGENc deinterlacuje+enkoduje ca 4x rychleji než QTGMC+h264 v Staxripu. Také jsem zkoušel NVENC v TMPGENc full processing (dekodování+filtry+enkodování) a na GTX1080Ti to bylo 1.6x realtime; zde byla velikost 320MB 60-kvalita)
(TMPGENc deinterlacuje+enkoduje ca 4x rychleji než QTGMC+h264 v Staxripu. Také jsem zkoušel NVENC v TMPGENc full processing (dekodování+filtry+enkodování) a na GTX1080Ti to bylo 1.6x realtime; zde byla velikost 320MB 60-kvalita)
[QUOTE=LadaOva;538893]Dle selské úvahy by to mělo být +- 2x vetší??[/QUOTE]
Ano, to je jen selská úvaha. Velkou roli hraje co je obsahem a jak kvalitní je videozáznam. Jak je nastaven GOP. Pokud je nekvalitní obraz, mnoho šumu i okem neviděný, tak při nízkém datovém toku je obraz ještě horší.
Navíc originální video enkódováno "speciální zaznamenávacím HW" může výstup komprimovat účinněji při zachování visuální kvality.
Ano, to je jen selská úvaha. Velkou roli hraje co je obsahem a jak kvalitní je videozáznam. Jak je nastaven GOP. Pokud je nekvalitní obraz, mnoho šumu i okem neviděný, tak při nízkém datovém toku je obraz ještě horší.
Navíc originální video enkódováno "speciální zaznamenávacím HW" může výstup komprimovat účinněji při zachování visuální kvality.
[QUOTE=LadaOva;538893]TMPGENc deinterlacuje+enkoduje ca 4x rychleji než QTGMC+h264 v Staxripu.[/QUOTE]
Při volbě deinterlace by neměla být prioritou rychlost procesu, ale kvalita. Před časem jsem zkoušel různé metody a nejlepších výsledků dosahoval skript QTGMC - umí totiž pracovat s vektory pohybu v obraze a pro vytvoření chybějících řádků snímku umí použít data z předchozího a následujícího snímku. TMPGENc jsem ale nezkoušel a nevím jakou metodu deinterlace používá.
Při volbě deinterlace by neměla být prioritou rychlost procesu, ale kvalita. Před časem jsem zkoušel různé metody a nejlepších výsledků dosahoval skript QTGMC - umí totiž pracovat s vektory pohybu v obraze a pro vytvoření chybějících řádků snímku umí použít data z předchozího a následujícího snímku. TMPGENc jsem ale nezkoušel a nevím jakou metodu deinterlace používá.
