I know it's possible to encode video from various codecs to .h264 with Quick Sync.
My questions is, is it possible to use Quick Sync hardware to decode h264 video and save the output to an intermediate format like Cineform, ProRes, etc.?
If it is possible could someone explain how to do it?
Thanx in advance...
+ Reply to Thread
Results 1 to 23 of 23
You need to have ffmpeg build supporting QSV, you need explicitly call QSV decoder before your input file, it may be necessary to explicitly load hardware assisted decoder trough -load_plugin (for sure it need to be used with HW encoder), side to this it may be necessary to add before '-i' (input) from https://www.ffmpeg.org/ffmpeg-all.html#Advanced-Video-options '-hwaccel:v qsv --hwaccel_device:v hw_any' however read about qsv HW decoding limitations:
Use the Intel QuickSync Video acceleration for video transcoding.
Unlike most other values, this option does not enable accelerated decoding (that is used automatically whenever a qsv decoder is selected), but accelerated transcoding, without copying the frames into the system memory.
For it to work, both the decoder and the encoder must support QSV acceleration and no filters must be used.
This option has no effect if the selected hwaccel is not available or not supported by the chosen decoder.
Note that most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs. Additionally, ffmpeg will usually need to copy the decoded frames from the GPU memory into the system memory, resulting in further performance loss. This option is thus mainly useful for testing.
Thanks for the info. How is the quality of the decoded video with QSV compared to the original or other decoders? If the quality would be worse than using the ffms2.dll, then I'd rather not use it.
Currently, I use something like this:
SetMTMode(5, 10) FFVideoSource("H:\My Videos - Originals\Season 2\S02-E03 - WIDMND.mkv")
My CPU usage is less than 25%
My source video is on one HDD and the destination is on another, one drive is reading while the other writes.
Any suggestions on speeding this up? Threading, different decoder, etc.
How are you measuring the 65-95 fps ? That can't be decoding only (measured with something like avsmeter), because you'd typically get maybe 150-300 FPS for decoding even with vanilla avisynth with libav (ffms2 or lsmash for 1080p) on a quad core. It must be encoding to prores or cineform (and how, exactly what are you doing) etc... or another bottleneck. Possibly decoding isn't a bottleneck in your actual process. Also using MT avisynth and something like ffmpeg, you must add distributor() to the script . But you shouldn't even need MT avisynth for just decoding (vanilla avisynth on a quad core should get 150-300FPS)
Technically, all decoders should give the same output (quality wise) , but in reality, there can be issues such as image corruption, mixed up frames. Even with ffms2 (higher risk when using MT and threads not equal to 1), and especially with PAFF AVC transport streams
QS won't work for you in ffmpeg , because you are encoding to prores or cineform (but not ENcoding cineform in ffmpeg). QS in ffmpeg requires both encoder/decoder support, but another way to use QS as decoder is directshowsource with lav filters configured to use QS, and/or graphstudio with lav configured to use QS as decoder
Measuring the fps is, as I mentioned above, was by watching the progress of VirtualDub, yeah, I know, not the best.
However, upon calculating elapsed time of the last 10 videos I've done (all between 52 & 61 minutes each), I'm actually getting between 84-98 fps. (Yeah, I keep records of encodes for various reasons like testing different codecs, settings, quality, time, etc.)
I had avisynth.dll 18.104.22.168 and AVSMeter 2.2.1 wouldn't run. So, I simply copied avisynth.dll 22.214.171.124 to C:\Windows\SysWOW64 folder (nothing in the C:\Windows\System32 folder)
This is a screenshot of AVSMeter 2.2.1 of one video:
Obviously, a very different average fps.
Yes, I am encoding to CineForm on the Medium quality setting for editing/cutting clips, etc.
Any suggestions to speed it up?
I was thinking of running multiple simultaneous instances of vdub, but I'm not that familiar with the capabilities of the various parts (ffms2.dll, VirtualDub, CineForm, etc.) I don't know how many instances of each can be run at the same time without having any conflict issues.
As soon as I get a chance, I'll give it a run and see how the numbers differ from running individual files.
As for the MT, I commented out that line and ran the test again, this time the average fps jumped to 368.2 fps, so I guess you're right about not needing it for this type of file. (I think the video is vc1, not h/x264, I don't know how to tell the difference in an .mkv file)
So cineform is your bottleneck.
I guess so. Any suggestions on speeding CineForm up? Another codec perhaps? What do you use jagabo?
If you want to speed it up, use several instances. You can effectively get 4x speed if 1 instance uses ~25% CPU usage if you have no other bottlenecks like storage I/O.
Why are you doing this in the first place ? (well I guess if it's VC-1 that could be a reason, you can use mediainfo to check), but the most common reason is if some extra processing steps were used, otherwise many people choose to edit original sources natively. Several streams/layers of 1080p AVC is very managable on modern hardware with decent software NLE. Cineform is known for it's DEcoding speed not encoding speed. Same with UT video. The timeline performance in another application like a NLE. That's why it's know as an "editing codec"
Which setting do you use with UT Video Codec. I see there are several different variations.
I'm thinking that maybe I should stick with CineForm, even though I may not be able to speed it up in VirtualDub.
One of the benefits is when I'm done editing the video in Sony Vegas 11, it only renders or recompresses the parts that were modified, ie. fades, or any other video effects. The sections/clips that have no changes don't get recompressed, just copied over. For instance, simply cutting out commercials in an hour long video can be rendered to a new clip in about 5 minutes (that's at 1080p @ 23.976 fps), ready for x264 encoding. Obviously, more edits/effects = longer render times, but it does save time where it needs to.
I know I could frameserve the video directly out of Vegas to MeGui, but that means my PC is occupied for the duration of the x264 encode.
Alternately, I render the intermediate file to another drive and allow another PC to do the x264 encoding.
Sure, trimming the clips could be done with Avisynth as well as many of the effects added, but writing those scripts can be daunting.
If you could get me the setting you use with the UT Video Codec, I'll run some tests using the same videos I did with CineForm so I can compare them.
Nonetheless, thanks for helping out.
Normally for UT you would use the same settings as the source. (e.g if the source was YUV 4:2:0, you would use one of the YUV 4:2:0 variants of UT)
UT will be slower than cineform, both encode and decode. It's a truly mathematically lossless codec. Cineform isn't. There is quality loss with cineform, however minor. Filesizes will also be larger for UT since it's lossless
But vegas doesn't handle YUV variants of UT video as YUV (ie. it's not lossless in vegas due to colorspace conversions), but it does smart render UT RGB if the settings are matched correctly
Not sure if I can post this, but here goes (let me know if it's not allowed and I'll remove the link):
My apologies if my questions seem tedious or ill-informed, the web is full of misleading information. So, to better understand, one must ask, right?
Here is what mediainfo displays for this video:
Format/Info: Advanced Video Codec
Format profile: High@L4.1
Format settings, CABAC: Yes
Format settings, ReFrames: 4 frames
Codec ID V_MPEG4/ISO/AVC
Duration: 52mn 37s
Bit rate mode: Variable
Bit rate: 29.3 Mbps
Maximum bit rate: 35.0 Mbps
Width: 1 920 pixels
Height: 1 080 pixels
Display aspect ratio: 16:9
Frame rate mode: Constant
Frame rate: 23.976 fps
Color space: YUV
Chroma subsampling: 4:2:0
Bit depth: 8 bits
Scan type: Progressive
Stream size: 10.8 GiB (93%)
I meant what were your reasons using cineform (or prores, or whatever) as an intermediate, since it's an extra few steps
vegas should open that source file up as-is , so depending on what you were actually doing in vegas (what types of maniuplations and edits, what the project particulars were) , I'd assess whether or not the extra time / hdd space of using cineform (or other intermediate) is actually worth it
Some editors (i'm referring to people here, not software) hate editing long GOP, regardless , and will automatically encode everything to some I frame intermediate if it wasn't already . On very large projects, lots of long GOP footage can sometimes cause problems and cause some software to "act up"