Stránka 2 z 2
Napsal: 16 čer 2024, 13:18
od matahari
To bys musel projet aspoň tím FFmpeg (to co je výše), ale klidně bez audia, protože to je zbytečné
Kód: Vybrat vše
ffmpeg -i input_file.h264 -c:v copy output_file.mp4
Vyhodí to hromadu chyb, ale nakonec to soubor vyplivne. Ten zdrojový soubor můžeš potom smazat.
Když si uděláš .bat soubor, tak to udělá v dávce se všemi soubory .h264. Soubor
ffmpeg.exe musí být ve stejném adresáři.
Kód: Vybrat vše
for %%a in ("*.h264") do ffmpeg -i "%%a" -codec copy "%%~na.mp4"
pause
Napsal: 16 čer 2024, 14:11
od robo
Složka ffmep v C. do dložky jsem hodil videa a k tome ten exe. spustil cmd přepl se do složky ffmep a zadal druhy řádek. Mám to asi blbě protože to hlásí chybu" is not recognized as an internal or external command,
operable program or batch file."
Napsal: 16 čer 2024, 14:40
od matahari
Tak jak to je, to musí být v .bat souboru, jinak to děláš dobře
Napsal: 16 čer 2024, 15:55
od masar
Tomu převodu stále něco "chybí". Výsledný soubor, který udává 10fps, má ve skutečnosti mnohem více framů, než by odpovídalo časovému údaji na videu, navíc se chaoticky jejich počet různí ve značném rozsahu a obsahuje skupiny prázdných/šedých framů...
Převod do .avi ze ZPlayeru také není ideální ale rozkolísanost je "zprůměrována", aby odpovídala reálně uplynulému času. Žádné "prázdné framy" neobsahuje.
Napsal: 16 čer 2024, 17:50
od robo
matahari bat zabral, díky. Ten postup si uložím pro příště.
Napsal: 16 čer 2024, 20:05
od matahari
Nemáš zač, kdybys chtěl rovnou smazat soubory .h264, tak nakonec přidej viz.
Kód: Vybrat vše
for %%a in ("*.h264") do ffmpeg -i "%%a" -codec copy "%%~na.mp4" && del /A /F "%%a"
pause
@masar: Asi jde jen o soubory, které zaznamenala kamera díky detekci pohybu a pro rychlou kontrolu, co se stalo, to bohatě stačí. Nemá cenu to znovu rekompresovat, což je jen další zbytečná ztráta obrazových dat a času.
Jestli by byl ovšem zájem o rekompresi a byla k dispozici slušnější GPU, tak FFmpeg umí využít takového výkonu, který je násobně rychlejší než u CPU. Potom je potřeba stáhnout správnou verzi, kdy sám používám NVENC verzi pro nVidia karty.
Napsal: 16 čer 2024, 22:54
od masar
Nejde o to, jak moc (bez)cenná jsou videa. Jde o to, že ten převod pomocí ffmpeg neposkytuje vyhovující výsledek. Výsledkem je video, které m.j. neběží rovnoměrně a trvá dvakrát tak dlouho...rekomprese zde není to podstatné.
1 sekunda převedeného videa představuje jednou 16, podruhé 34 framů (nepravidelně) s rychlostí 10FPS. Je otázka, v čem spočívá příčina tohoto stavu. I prosté přehrátí staženého vzorku v ZPlayeru vykazuje znatelné kolísání FPS.
Konkrétně - dané video má po převodu 5888 framů při 10FPS. Tzn. že je 9'49" dlouhé.
Napsal: 16 čer 2024, 23:44
od rnbw
Cinan si vyrobil vlastny format skriplenim standardneho formatu.
Napsal: 17 čer 2024, 00:08
od matahari
@masar: Tak to oprav, aby seděl čas + počet framů a zaznamenej si, jak dlouho to trvalo. Pro ukázku to opět ulož na edisk a sděl nám laskavě postup.
Potom ten prodrbaný čas můžeme vynásobit těmi dalšími videi, které trvají 9 hodin.
Napsal: 17 čer 2024, 08:39
od masar
Ale tím nedostanu odpověď na tu hlavní otázku - čím je to způsobeno.
Je to chyba/vlastnost enkodéru na straně kamery? Nesprávně nastavený/zastaralý/vybraný dekodér?. Takto "zmršené" video je přece neakceptovatelné a nevěřím, že by to výrobce toleroval. Na druhou stranu - kdyby tomu tak bylo, asi by to bylo téma pro specializovaná diskusní fóra.
Ale kde nic tu nic. Firmwarů pro tuto kameru je vícero, možná je to chyba některého z nich?
---
edit: V reakci
matahari vidím jistou podrážděnost, ale moje kritika nesměřuje k němu.
Tady je na stránce StarCamu ke stažení malý přehrávač ZPlayer, umožňující převod do avi. Přitom ale svévolně změní FPS na 30 za použití rekomprese. Kolísání rychlosti zaznamenaného videa je i tak dobře patrné.
Napsal: 17 čer 2024, 09:31
od matahari
Taky nesmíme zapomenout na tu úplně nejvíc hlavní otázku, jak takový výrobce vznikl, kde se vyskytuje, jaktože jeho výstupní kontrola nefunguje, proč takové výrobky prodává na globálním trhu, kam až to může zajít?
Bláboly můžeme psát donekonečna.
Napsal: 17 čer 2024, 10:38
od masar
Pokud se opíráme o nějakou logiku věcí, nejsou to bláboly. Výrobce můžeme vinit až po té, co budeme s jistotou
vědět, že je záznam vadný a je to způsobeno jeho firmwarem. Víme to?
Napsal: 17 čer 2024, 10:49
od matahari
Žádný návod tu od tebe nepadl, tak budiž. FFprobe hlásí 25 FPS, u tbr je 20 a přehrávače informují o 10 FPS, takže podle celkového počtu snímků a času je to nejspíš 2x 10 (opravdově Yx 10).
Kód: Vybrat vše
Stream #0:0: Video: h264 (High), yuv420p(progressive), 1280x720, 25 fps, 20 tbr, 1200k tbn
Ohnout se to dá např. takhle
Kód: Vybrat vše
ffmpeg -i "205139 100 008046844 0281.h264" -codec:v h264_nvenc -filter:v select="mod(n-1\,2)",setpts="N/(10*TB)" -r 10 "205139 100 008046844 0281.mp4"
ale chce si to dál pohrát s dalším nastavením, jako bitrate apod., kvůli výsledné velikosti. Do kodeku je potřeba dosadit, co kdo používá. Výsledek je
Kód: Vybrat vše
frame= 2847 fps=1103 q=10.0 Lsize=25002KiB time=00:04:44.40 bitrate=720.2kbits/s speed=110x
takže bez nuceného vložení celkového počtu snímků nebo času je tento 4:44.40, což jakž takž sedí od 20:51:35 do 20:56:20.
Celé to je zbytečná procedura, protože pohybovat se po časové ose lze i s předchozím nastavením.