|
|
| Loadus |
| Posted: Apr 17 2010, 05:56 PM |
 |
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
| QUOTE (Gromozeka @ Apr 16 2010, 08:14 AM) | Loadus
its old bug, but Avery not fix him  |
It will be fixed due time, don't worry. Remember, Phaeron is doing this on his free time. ^^
I just wanted to report it, just so it was on record.
--------------------
deviantART behance |
|
| phaeron |
| Posted: Apr 18 2010, 04:35 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Indeed, it's now fixed in test-16.
I've synced the 1.9.X branch to fixes in the 1.9.9 stable release. In addition, this version has support for using 2+ threads for video compression when only key frames are in use. This includes key frame only codecs such as Huffyuv, and it also includes other codecs when the key frame interval is forced to one. (XviD does not work for this, because it ignores the key frame request flag.) I've also tweaked the IVTC filter a bit to better match older versions with the pre-filter algorithm.
|
|
| Loadus |
| Posted: Apr 18 2010, 04:41 AM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
| QUOTE (phaeron @ Apr 17 2010, 10:35 PM) | | Indeed, it's now fixed in test-16. |
You are zhe mastar. ^^
Well, I thought I'd go get some sleep tonight but *fubar* it, I'm gonna write some encoder sets.  :D
--------------------
deviantART behance |
|
| BugMaster |
| Posted: Apr 18 2010, 03:49 PM |
|
|
Advanced Member
Group: Members
Posts: 50
Member No.: 23001
Joined: 6-February 08
|
| QUOTE (phaeron @ Apr 18 2010, 07:35 AM) | | This includes key frame only codecs such as Huffyuv, and it also includes other codecs when the key frame interval is forced to one. (XviD does not work for this, because it ignores the key frame request flag.) |
About keyframe forcing. I tried to add it support to x264vfw but in result have to disable it due the VirtualDub bug (at least it is the bug in my opinion). The bug reveal itself that even without using keyframe forcing VirtualDub ask first frame to be keyframe and probably due the using of "VirtualDub hack" technique (return of 1-byte 0x7f frames with XVID fourcc to inform about delayed frames due buffering) it ask to make few next frames (depends on the number of delayed frames) also keyframes until first real frame is returned. |
|
| Barough |
| Posted: Apr 18 2010, 04:26 PM |
|
|
Advanced Member
Group: Members
Posts: 95
Member No.: 22677
Joined: 24-December 07
|
| QUOTE (phaeron @ Apr 18 2010, 05:35 AM) | Indeed, it's now fixed in test-16.
I've synced the 1.9.X branch to fixes in the 1.9.9 stable release. In addition, this version has support for using 2+ threads for video compression when only key frames are in use. This includes key frame only codecs such as Huffyuv, and it also includes other codecs when the key frame interval is forced to one. (XviD does not work for this, because it ignores the key frame request flag.) I've also tweaked the IVTC filter a bit to better match older versions with the pre-filter algorithm. |
Thnx a lot 4 the sync with the 1.9.9 stable Avery. 
--------------------
 |
|
| dloneranger |
| Posted: Apr 18 2010, 06:15 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Any chance of modifying the ivtc filter for duplicate removal of 1-in-6 frames as well as 1-in-5
[edit]
nevermind, f_itvc was pretty easy to fixup for the task
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| phaeron |
| Posted: Apr 18 2010, 09:43 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | About keyframe forcing. I tried to add it support to x264vfw but in result have to disable it due the VirtualDub bug (at least it is the bug in my opinion). The bug reveal itself that even without using keyframe forcing VirtualDub ask first frame to be keyframe and probably due the using of "VirtualDub hack" technique (return of 1-byte 0x7f frames with XVID fourcc to inform about delayed frames due buffering) it ask to make few next frames (depends on the number of delayed frames) also keyframes until first real frame is returned. |
Hmm. I don't think it's a bug, but it's an ugly ambiguity. The problem is that the introduction of the frame skew between input and output means that it is ambiguous as to whether the key frame request flag means to force a key frame for the input frame or for the output frame. VirtualDub's interpretation is that this affects the frame being output, i.e. setting the flag should cause the key frame flag to be set on the output. It would be pretty easy to change this to the other interpretation of having the flag apply to the input frame, but even backwards compatibility issues aside I'm not sure that makes more sense.
However, there is another piece of information the codec can use: ICM_COMPRESS_FRAMES_INFO will also be sent with a key rate interval of 1 when VirtualDub is trying to do this, so that would be another indicator that all frames should be made key frames.
Incidentally, even if this all did work out, the result would be an XviD or H.264 stream that contained all I-frames... not sure how interesting that is, given that there are decent codecs available designed for I-frame only operation.
|
|
| DanskDranker |
| Posted: Apr 18 2010, 10:27 PM |
|
|
Member
Group: Members
Posts: 18
Member No.: 26604
Joined: 12-December 09
|
Will the new version be 2.0??? |
|
| BugMaster |
| Posted: Apr 19 2010, 06:56 AM |
|
|
Advanced Member
Group: Members
Posts: 50
Member No.: 23001
Joined: 6-February 08
|
| QUOTE (phaeron @ Apr 19 2010, 12:43 AM) | | Hmm. I don't think it's a bug, but it's an ugly ambiguity. The problem is that the introduction of the frame skew between input and output means that it is ambiguous as to whether the key frame request flag means to force a key frame for the input frame or for the output frame. VirtualDub's interpretation is that this affects the frame being output, i.e. setting the flag should cause the key frame flag to be set on the output. It would be pretty easy to change this to the other interpretation of having the flag apply to the input frame, but even backwards compatibility issues aside I'm not sure that makes more sense. |
From MSDN
dwFlags
Flags used for compression. The following value is defined:
ICCOMPRESS_KEYFRAME - Input data should be treated as a key frame.
So from my point it must apply to input frame. But any way I also can't enable this feature even if you fix it in new versions (due the complitability with old VirtualDub versions). So you can don't bother with it. This was only information to you about doubtful behaviour. |
|
| phaeron |
| Posted: Apr 20 2010, 04:17 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | Will the new version be 2.0??? |
I haven't decided yet. Does it matter?
| QUOTE | | So from my point it must apply to input frame. But any way I also can't enable this feature even if you fix it in new versions (due the complitability with old VirtualDub versions). So you can don't bother with it. This was only information to you about doubtful behaviour. |
I'll agree with that, but note that the the documentation for ICCOMPRESS_KEYFRAME passed to the ICCompress() function is different, and the interface doesn't allow for any frame skew for which the distinction would matter. We're already dealing with an out-of-band mechanism in order to implement the frame delay.
I don't think it would be much of a problem to switch the behavior, because normally XviD and x264vfw are used with the key frame interval disabled, and anyone who tried to use otherwise would have discovered that it doesn't work. In any case, the worst error is that you get a few extra I-frames at the beginning of a sequence. However, I just realized that there is another problem with doing this, which is that it makes actually implementing a key frame delay difficult in that you may not be able to tell whether you need to reset the interval until several frames after you already needed to do it. For instance, if the codec has a delay of 3 and you are trying to hit a key frame interval of 2, it would be impossible to react quickly enough to manage the interval properly, because if the codec initiates a key frame on its own it's already 2-3 frames too late to change the incoming flags.
Given the circumstances, I'll change the error message in the multithreading code to just indicate an incompatibility, as it isn't fair to blame to codec for this. That having been said, if you could implement the specific case of lKeyRate=1 in the ICM_COMPRESS_FRAMES_INFO message and all frames marked as ICCOMPRESS_KEYFRAME, that would be an unambiguous case that would make this situation work.
Edit:
One other thing I forgot to mention -- the threaded compressor is fine with a drop frame (size=0, flags=!AVIIF_KEYFRAME) even in multithreaded mode.
|
|
| jpsdr |
| Posted: Apr 20 2010, 08:52 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
| QUOTE (phaeron @ Aug 3 2009, 12:49 AM) | Change list for this build:
- (test-16) 2+ thread support for key frame only video compression.
|
Does it mean in 'Threading -> Video compression threads', value can be 2 or more for Huffyuv and lagarith codec ?
I'm having an i7@980 (6 cores + HT), what value do you suggest i can use for video filter threading ?
I'm thinking 8 for video filter threading and 4 for Video compression threads (wich will make the maximum 12 avaible
on my CPU). Video process ahead, should it be left to auto, or is there an optimal value ? |
|
| phaeron |
| Posted: Apr 21 2010, 03:18 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Yes, it does. However, whether or not that is useful depends on whether the rest of the pipeline can feed all of those codecs. The decompression half is not currently multithreaded.
|
|
| jpsdr |
| Posted: Apr 28 2010, 07:38 AM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
I've made some work with this version, to discover a problem. (Now, i must redo everything... )
All my outpout videos were 1 frame shorter.
Settings was to 8 threads/frames for video filter, 4 for compression output. Audio was on none/direct stream copy.
My input files were avisynth scripts. Color was either YV12/YV12 or YV12/YUY2
Output was either lagarith or Huffyuv. Video were atround 32000 frames size.
I've not been able to reproduce the problem with a little (100) video test clip created by VDub. |
|
| fredgiblet |
| Posted: Apr 28 2010, 08:16 AM |
|
|
Advanced Member
Group: Members
Posts: 356
Member No.: 22601
Joined: 13-December 07
|
| QUOTE (phaeron @ Apr 20 2010, 04:17 AM) | | I haven't decided yet. Does it matter? |
We need to know if we need to start planning our 2.0 release party. |
|
| jpsdr |
| Posted: Apr 28 2010, 05:14 PM |
|
|
Advanced Member
Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06
|
I've redone half of my videos, with exactly the same processing, and no problem, so, it's realy related to this release. |
|
