|
|
| Exastify |
| Posted: Aug 26 2013, 02:00 AM |
 |
|
Newbie
Group: Members
Posts: 1
Member No.: 37030
Joined: 26-August 13
|
Hi, I'm trying to edit a video, about 7 minutes long and ~700mb. However, when I use the scrubber to jump to different points along the video, it lags and usually gets stuck on "Decoding frame xxxx" for several seconds. I'm running a fairly modern processor and an SSD so I don't think it's a computer issue. Is there a way to get VirtualDub to decode the entire video so there is no lag when scrubbing? Thanks! |
|
| raffriff42 |
| Posted: Aug 26 2013, 02:42 AM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
Every time you move to a new current frame, if it's not cached VirtualDub must seek to the previous keyframe, many frames earlier, and walk up to the selected frame, building up the image from all the stored incremental changes.
For editing, re-encode in a keyframe-only format. Huffyuv, Lagarith and UT Video all work and are lossless - the last is my new favorite. |
|
| dloneranger |
| Posted: Aug 26 2013, 01:23 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
If you have to scrub through non keyframe only avi's (xvid, h264 etc), you can hold down the shift key (or was it ctrl) as you move the position slider and it'll snap to keyframes only
That should get you close to the point you want faster
Just for information if you don't know how the codecs work....
Most codecs normally encode the images into the file as one complete image (called a keyframe) followed by a lot of 'what's changed in this image' (up to about 300 of them) before saving a complete image again
As raffriff42 said, when you want to go to a frame that's inbetween two complete images the pc has to go to the closest full image (keyframe) and then work it's way forward, making all the changes that are needed before you can get the frame you want
Unfortunately you can't cache all the frames in memory as eg 300 decoded frames of 1920x1080 is about 1.7Gb
@raffriff42
What is it about UTVideo that's caught your interest?
I normally use lagarith, and the only thing I can see about ut that's possibly better is rec709 specific fourcc's that might be usefull in some specific situations
Otherwise, on it's fastest setting it's slower than lagarith, and with it's best compression the files are larger that lagarith?
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| raffriff42 |
| Posted: Aug 26 2013, 09:06 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
You're right about Lagarith's file size. I just did a little testing and find that in YUV mode*, Lagarith is not only smaller but also looks better than Huffyuv or UT.
In RGB mode all 3 are perfect, as they should be, but there are subtle differences in YUV mode. Lagarith's chroma is filtered more smoothly. The other codecs look a little blocky on computer-generated, hard, diagonal, colored edges. UT Video also has a 1-pixel chroma offset, which could be a problem if multiple generation copies are needed. Here are some screen grabs to show you what I mean. The differences are quite subtle (as they should be for something that's supposed to be "lossless"), but enough to make me prefer Lagarith whenever YUV mode is required, or when file size is a concern.
My problem with Lagarith is just that it's not always compatible; sometimes it's sluggish in playback, and sometimes I get video glitches when rendering from Premiere with Lagarith.
OTOH, Huffyuv always seems to work - even if the file size *is* quite a bit larger. Huffyuv in RGB mode creates monstrously huge files, but it's the most universally compatible. After doing these tests, I don't think I will be using the UT codec in YUV mode - until the chroma filtering is improved.
* 'YUV mode' meaning: Lagarith 'YV12', Huffyuv 'Convert to YUY2', and UT Video 'YUV 420 Rec.601'
|
|
| dloneranger |
| Posted: Aug 26 2013, 10:12 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
@raffriff42
Thanks for the info
The guy who wrote lagarith is quite approachable, you could get in touch about problems
I don't use premiere, but haven't found any problems myself
If you're feeling a bit adventurous there's a slightly modified version I created for some testing https://dl.dropboxusercontent.com/u/1702491...ithmodified.zip
It works with values >1 in virtualdub's threading options, and has separate multithreading checkboxes for encoding/decoding (in multi threaded mode, lagarith uses 3 threads, 2 of which are low priority, so may bog on loaded systems)
[edit]
Hmm I wonder if disabling/enabling the null frame option would affect premiere
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| Malaksbane |
| Posted: Aug 27 2013, 07:13 PM |
|
|
Member
Group: Members
Posts: 13
Member No.: 32779
Joined: 24-August 11
|
You could try another high quality keyframe only codec. |
|
| raffriff42 |
| Posted: Aug 28 2013, 02:39 AM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
There's another, completely different way to speed up scrubbing. If you open the video (in VirtualDub) through an Avisynth script calling FFmpegSource, scrubbing is improved dramatically by FFmpegSource's indexing and Avisynth's frame caching. | CODE | #avisynth
## requires FFmpegSource
## http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html
FFmpegSource2("path to any video", atrack=1) ## (audio track may vary; try 0-2) |
Granted Avisynth has a steep-ish learning curve, and simply re-encoding a short video would be easier; but Avisynth is worth learning for its many other uses. For long videos with only simple editing requirements (for example, making 2 cuts in a 2-hour long video), Avisynth+FFmpegSource is a time-saver.
This post has been edited by raffriff42 on Aug 28 2013, 12:53 PM |
|
