इसलिए मैंने अपना जवाब बहुत लंबा कर दिया।
टीएल; डीआर सारांश: दोषरहित रूप से छवियों के एक क्रम को संग्रहीत करने के लिए, उपयोग libx264या libx264rgbसाथ -preset ultrafast -qp 0। यह लगभग कम बिटरेट के साथ ffvhuff जितना तेज़ है, और तेज़ी से डिकोड होता है। huffyuvअधिक व्यापक रूप से ffmpeg के बाहर समर्थित है, लेकिन कई पिक्सेल प्रारूपों का समर्थन नहीं करता है ffvhuff। इसलिए h.264 का उपयोग करने का एक और कारण है, यह मानते हुए कि आपके अन्य उपकरण h.264 High 4:4:4 Predictiveप्रोफ़ाइल को संभाल सकते हैं जो x264 दोषरहित मोड में उपयोग करता है। x264 इंट्रा-केवल तभी कर सकते हैं जब मनमाने ढंग से फ्रेम तक तेजी से यादृच्छिक पहुंच की आवश्यकता होती है।
छवियों की एक निर्देशिका से पढ़ते समय libx264rgb को प्रभावित करने वाले ffmpeg बग से सावधान रहें । (और कौन जानता है कि अन्य मामले क्या हैं।) उपयोग करने से पहले अपने सेटअप में दोषरहितता के लिए परीक्षण करें। ( ffmpeg -i in -pix_fmt rgb24 -f framemd5स्रोत और दोषरहित-संपीड़ित पर आसान )
संपादित करें: utvideoसांकेतिक शब्दों में बदलना और काफी तेजी से डिकोड, और h.264 की तुलना में बहुत सरल कोडेक है। यह मूल रूप से एक आधुनिक है huffyuv, जिसमें अधिक उपयोगी कलरस्पेस के लिए समर्थन है। यदि आपको कभी भी h.264 की समस्या है, तो अस्थायी फ़ाइलों के लिए utvideo को आज़माएँ।
edit2: एक RGB कोडेक के रूप में PNG अच्छा प्रदर्शन करता है, कम से कम सिंटेल ट्रेलर पर।
इसी तरह के सवाल के लिए मेरे समान जवाब भी देखें:
https://superuser.com/a/860335/20798
विभिन्न कच्चे स्वरूपों और कोडेक्स के बारे में वॉरेन यंग के जवाब में बहुत सी जानकारी है। मुझे लगता है कि यदि यह छोटा था तो उत्तर अधिक उपयोगी होगा, इसलिए मैं एक नया उत्तर दे रहा हूं। यदि आप ऐसे सॉफ़्टवेयर के साथ काम कर रहे हैं जो दोषरहित x264 या ffvhuff का समर्थन नहीं करता है, तो उस जानकारी में से कुछ शायद अभी भी उपयोगी है।
इस संदर्भ में "दोषरहित" की सबसे उपयोगी परिभाषा यह है कि आप इनपुट बिट-फॉर-बिट को पुनर्प्राप्त कर सकते हैं। वीडियो एन्कोडिंग से गुणवत्ता में गिरावट के बारे में शून्य चिंता, चाहे आप कुछ भी करें।
http://en.wikipedia.org/wiki/Chroma_subsampling
आदर्श रूप से, कई कलरस्पेस रूपांतरणों से बचें। गोलाई की त्रुटियां संभावित रूप से निर्मित हो सकती हैं। यदि आप RGB विडियोस्पेस में काम करने वाले फिल्टरों के साथ अपने वीडियो को संचालित करने जा रहे हैं, तो इसे RGB रखने से समझ में आता है, जब तक कि उच्च बिटरेट कोई समस्या नहीं है। आप शायद अंततः एक yuv 4:2:0वीडियो बनाने जा रहे हैं , लेकिन अतिरिक्त क्रोमा रिज़ॉल्यूशन रखना संभावित रूप से उपयोगी है, यह इस बात पर निर्भर करता है कि आप किस फ़िल्टर को लागू करने जा रहे हैं।
किसी भी तरह से, दोषरहित x264 और दोनों समर्थन आरजीबी और YUV ffvhuff 4:4:4, 4:2:2, और 4:2:0। मैं सुझाव दूंगा x264, क्योंकि यह तेजी से डिकोड है। यदि आप वास्तविक समय में RGB HD वीडियो को वापस चलाने की कोशिश कर रहे हैं, तो xv के बजाय opengl का प्रयास करें, क्योंकि मेरे सिस्टम पर xv केवल yuv इनपुट को स्वीकार करता है। एक रंग-स्थान रूपांतरण करने के लिए mplayer अतिरिक्त CPU समय ले रहा था।
निम्नलिखित एनकोडर परीक्षणों के लिए स्रोत: https://media.xiph.org/ । https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz वे Sintel ट्रेलर के लिए y4m फ़ाइलों gzip के लिए इतना png टारबॉल वास्तव में एक बहुत छोटा होता है भूल गया।
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv
जैसे
peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.100 / 56. 18.100
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 7.100 / 5. 7.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
Metadata:
encoder : Lavf56.18.100
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470
[libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787
[libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0%
[libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1%
[libx264rgb @ 0x2770760] kb/s:135693.94
ध्यान दें कि मैं -r 24एफपीएस निर्दिष्ट करना भूल गया , इसलिए यह ऑडियो के साथ एवी सिंक नहीं रखेगा। (और बिटरेट (लेकिन फ़ाइल का आकार नहीं) नंबर बंद हो जाएंगे, भी। इस मशीन में सीपीयू एक 1-जीन (कॉनरो) कोर 2 डी 2 ओ 2.4GHz (E6600) है।
परिणाम:
4.5M sintel_trailer-audio.flac # this is muxed in to every mkv
948M 1080 # the directory of PNGs
940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong?
2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize
2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt
1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way
946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast
824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M frompng.sintel.264rgb.mkv
735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though
626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc.
512M lossy.prores.mov # yuv422p10le, 12fps
341M sintel.yuv420.x264.lossless.mkv
21M lossy.rgb.crf26.preset=medium.mkv
13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio
ध्यान दें कि mediainfoRGB h.264 के बारे में पता नहीं है, यह अभी भी कहता है कि फाइलें YUV हैं।
जांचें कि यह वास्तव में दोषरहित था:
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical
तो आप उस तरह से मूल PNG इनपुट को पुनर्प्राप्त कर सकते हैं, यानी आप उनमें समान छवि डेटा के साथ PNG बना सकते हैं।
-pix_fmt rgb24X264 परीक्षण के लिए ध्यान दें । ffmpeg के h.264 डिकोडर आउटपुट gbrp (प्लानर, पैक्ड नहीं) आउटपुट देते हैं, इसलिए बिट्स समान हैं, लेकिन एक अलग क्रम में। Framemd5 "कंटेनर" किसी भी प्रकार के प्रारूप प्रतिबंध नहीं लगाता है, लेकिन यदि बिट्स समान तरीके से व्यवस्थित किए जाते हैं तो आपको केवल md5 मिलेगा। मैंने अभी देखा कि ffmpeg ने कहा कि यह पिक्स fmt के लिए उपयोग कर रहा था जब मैंने इसे PNGs खिलाया, तो उस -pix_fmtडीकोड के लिए arg के रूप में उपयोग किया । संयोग से, यही कारण है कि vlc RGB h.264 फ़ाइलें नहीं चलाएगा (जब तक कि अगली रिलीज़, या वर्तमान रात का निर्माण नहीं हो जाता): यह gbrp पिक्सेल प्रारूप का समर्थन नहीं करता है।
युव उपयोग के लिए libx264, नहीं libx264rgb। आपको x264 का RGB संस्करण स्थापित करने की आवश्यकता नहीं है, वास्तविक पुस्तकालय दोनों का समर्थन करता है। यह सिर्फ ffmpeg है जिसने इसे दो अलग-अलग नाम एन्कोडर के रूप में लागू किया है। मुझे लगता है कि अगर उन्होंने ऐसा नहीं किया होता, तो डिफ़ॉल्ट व्यवहार आरजीबी के रूप में आरजीबी इनपुट को छोड़ना होगा, और एक ही गुणवत्ता के लिए बहुत अधिक बिटरेट आउटपुट का उत्पादन करते हुए वास्तव में धीरे-धीरे चलना होगा। (आप अभी भी कभी-कभी उपयोग -pix_fmt yuv420pकरना चाहते हैं यदि आप h.264 आउटपुट के 420बजाय चाहते हैं 444।
जब तक आप लंबे समय तक भंडारण के लिए फाइल नहीं बना रहे हैं, हमेशा -preset ultrafastदोषरहित x264 के लिए उपयोग करें । अधिक संदर्भ फ्रेम और गति खोज मुश्किल से दोषरहित, गैर-एनिमेटेड सामग्री के लिए किसी भी शोर के साथ कोई फर्क नहीं पड़ता है। CABAC दोषरहित बिटरेट पर भारी मात्रा में सीपीयू लेता है, यहां तक कि डीकोड करने के लिए भी। केवल अभिलेखीय उद्देश्यों के लिए उपयोग करें, न कि फाइलों को खरोंचने के लिए। (ultrafast CABAC को निष्क्रिय करता है)। CABAC 10 से 15% बिटरेट बचत देता है।
यदि आपको कीफ़्रेम होने के लिए हर फ्रेम की आवश्यकता है, तो सेट करें -keyint 1। फिर वीडियो एडिटिंग सॉफ्टवेयर जो केवल कीफ्रेम या w / e पर कट करना चाहता है, आपको सीमित नहीं करेगा।
मूल प्रश्न का उत्तर देने के लिए: यह है कि आपको चरणों में चीजों की कोशिश करते समय अस्थायी फ़ाइलों को फेंकने के लिए क्या करना चाहिए (उदाहरण के लिए धीमी गति से काम करना, अन्य चीजों को आज़माने से पहले दोषरहित आउटपुट को सहेजना):
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv
यदि आपको वास्तव में छवि फ़ाइलों में अपने आउटपुट की आवश्यकता है जिसे आप अभी भी-छवि टूल के साथ संशोधित कर सकते हैं, तो सुनिश्चित करें, पीएनजी को डीकोड करें। आप शायद हर पिक्सेल के लिए Y, Cb और Cr मानों में से प्रत्येक के लिए 8 बिट्स के कम से कम महत्वपूर्ण से अधिक कुछ खोने नहीं जा रहे हैं।
x264 इसमें बहुत अच्छी तरह से निकलता है क्योंकि इसमें बहुत सारे काले फ्रेम होते हैं जिनमें कई टेक्स्ट होते हैं, एक फीका-इन और फीका-आउट, और कई फ़्रेमों के बड़े क्षेत्रों के बीच एक समान समानता होती है, जो इसके साथ भी फायदा उठाता है -preset ultrafast। लाइव-एक्शन पर, मैं अभी भी ffvhuff (yuv420) की आधी फाइलों पर x264 देखता हूं।
किसी के लिए भी उत्सुक: उच्च-सीपीयू-समय दोषरहित आरजीबी सांकेतिक शब्दों में बदलना (x264 कोर 144 r2525):
[libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367
[libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512
[libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0%
[libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66
भारित पी फ्रेम के वास्तव में उच्च अंश पर ध्यान दें, और स्किप मैक्रोबलाक्स का वास्तव में उच्च अंश। प्रत्येक दृश्य संक्रमण एक फीका है, कट नहीं है, और x264 लाभ उठाता है यदि आप इसे सीपीयू को यह पता लगाने का समय देते हैं कि कैसे।
आगे के नोट (संपादन के लिए हानिपूर्ण कोड):
क्लिप के माध्यम से आगे / पीछे की तरफ स्क्रबिंग के लिए, इंट्रा-ओनली कोडेक्स आमतौर पर इष्ट हैं (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra)। मैं छोटे GOPs (1/2 से 1 सेकंड) के साथ नियमित रूप से AVC की कल्पना करता हूं, बहुत अच्छी तरह से स्क्रब करेगा, जब तक कि सॉफ्टवेयर को पता था कि यह क्या कर रहा था (तेज आई स्क्रब करते समय निकटतम आई फ्रेम को डिकोड करें, पाने के लिए GOP के भीतर डिकोड करें। एक अंतर फ्रेम यदि आपको उस समय के लिए पर्याप्त समय में ज़ूम इन किया जाना चाहिए)।
मैंने इस पर कुछ नकारात्मक बातें पोस्ट की हैं और https://video.stackexchange.com/ के बारे में प्रो-रेस, जैसे "क्या बात है अगर यह धीमा है और दोषरहित कोडेक से भी बदतर संपीड़न है", लेकिन इसमें कुछ दिलचस्प विशेषताएं हैं। Apple का कहना है कि यह आधे रेजोल्यूशन में कम से कम 1/3 का उपयोग करके डीकोड कर सकता है।
ffmpeg का prores कार्यान्वयन संभवतः Apple के समान गति के लिए अनुकूलित नहीं है, यही वजह है कि ffmpeg के साथ मेरे परीक्षण ने इसे धीमा बना दिया है। यह शायद उपयोग करने लायक नहीं है यदि आपके पास ffmpeg पर आधारित उपकरणों के साथ एक मुफ्त सॉफ्टवेयर वर्कफ़्लो है, लेकिन यदि आप वाणिज्यिक सॉफ़्टवेयर का उपयोग कर रहे हैं तो यह कोशिश करने लायक हो सकता है।
मैं बहुत सारे वीडियो एडिटिंग नहीं करता, ज्यादातर सिर्फ एन्कोडिंग करता हूं, इसलिए मुझे इस बात का अंदाजा नहीं है कि कोडेक्स के लिए कौन सा टेस्ट उचित होगा। मुझे लगता है कि शायद mjpeg एक अच्छा तेज विकल्प होगा, अगर शॉर्ट-GOP x264 अच्छी तरह से काम नहीं करता है। लिनक्स डिस्ट्रोस में जेपीएम के एएसएम-त्वरित कार्यान्वयन हैं, और यह एक बहुत ही सरल कोडेक है। आप गुणवत्ता को बंद करने के लिए गुणवत्ता को ऊपर या नीचे मोड़ सकते हैं। यह प्राचीन है, लेकिन यदि आप एक इंट्रा-ओनली कोडेक चाहते हैं जो वास्तव में तेज है, तो यह x264 को हरा सकता है।
X264 के लिए, मैं कुछ ऐसा प्रयास करूँगा x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (इंट्रा-ओनली, बिना किसी अन्य सामान के जो --avcintra-classसेट होता है।) नोट superfast(बिना CABAC के), या fasterनहीं।ultrafast हानिपूर्ण संचालन के लिए शायद सबसे अच्छा है। मुझे लगता है कि अल्ट्राफास्ट बहुत अधिक गुणवत्ता के बिना बहुत तेजी से खो देता है। जितनी कम गुणवत्ता (उच्च crf) आप उपयोग करते हैं, उतना ही बेहतर एनकोड खोजने में थोड़ा अधिक सीपीयू समय बिताने के लायक है। यह बहुत कुछ संभवतः GOP आकार = 1 के साथ प्रासंगिक नहीं है, हालांकि।
GOP आकार> 1 के साथ, यदि आप एनकोड पर इतने सारे बिट्स फेंक रहे हैं कि अवशिष्टों को एन्कोडिंग करते समय बेहतर अंतर-भविष्यवाणी कई बिट्स को नहीं बचाएगी (क्योंकि फ्रेम के बीच शोर / अनाज / सूक्ष्म परिवर्तन बहुत सटीक रूप से संरक्षित हो रहे हैं), तो बस सुपरफास्ट शायद ठीक है। अन्यथा, --keyint=30कुछ या कुछ के साथ , शायद --preset veryfast --crf 12दिलचस्प होगा।
सिद्धांत रूप में, किसी निर्धारित सीआरएफ सेटिंग में गुणवत्ता प्रीसेट में स्थिर होनी चाहिए। यदि आप छोटी फ़ाइलों (तेज़ डिकोड्स) की तलाश कर रहे हैं, तो कुछ गुणवत्ता और कुछ एनकोड समय का व्यापार करना समझ में आता है।
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov।