quote="Aktan"]Another proof that x264 doesn't have 4:4:4 yet is this:
http://x264dev.multimedia.cx/?p=332
One of the projects is to add that support![/quote]
Sounds good to me! But for now, I'll just work with what I have until it becomes supported.
Okay, to get back on track with the thread topic, I've been studying the options for the deldup function. From what I can understand, Flygon's implementation would be minfps=0.1:lthresh=0.1:mbthresh=100:mbmax=1:cthresh=0.1.
minfps is simple enough. 0.1fps would be one frame per 10 seconds. This is most likely the culprit of the strange tracking Flygon experienced in VLC, but I don't think that that in itself should be that big of an issue..if it is 1 should work perfectly fine.
Lthresh..would be the threshold of the luma (Y) channel. If I'm understanding correctly, the addition of every pixel's SAD will be up to this value. Its defined by X*Y*Lthresh, so, if the value is 0.1 that would mean its 10% of the total amount of pixels. I ran some tests on this, from 100 jumping all the way down to 0.00001, and to be honest I don't think this value means a whole lot. MBthresh has a greater factor in terms of what frames gets dropped.
MBthresh and MBmax..if the number of 8x8 blocks in the image with SAD larger than MBthresh (100) exceeds MBmax (1), then the next frame is a unique image and is kept. In the documentation I'd like to point out that it specifically says it has to "exceed" MBmax (technically says MBThresh, but I'm sure that's a typo), so I think an MBmax value of 0 would be better, since the current values would dictate that you'd need two blocks to be different. Here I'll say that only when I set LThresh to 0.00001, with MBThresh at 100, that the encoder kept an excessive amount of frames. (0.00002 still seemed to still work properly) I think it had to do with SAD being under 1 total as to why it wasn't working.
CThresh is the threshold of the chroma (U & V) channel. Works mostly the same way as LThresh, only when I tried disabling Lthresh to test Cthresh only, it wouldn't encode. I was considering maybe you wouldn't really need this value and you can assign it a negative in order to disable it and increase encoding speeds, but since SAD calculation appears to be very fast with vast implementation, the benefit would be very minimal. There's also the chance of two colors having the same Luma value, so it wouldn't be the wisest thing.
Anyway, I think adequate values for C & LThresh would be 1, since it'd equal the amount of available pixels..anyway because of MBThresh being so low the number doesn't have to be excessively large to begin with...assuming I understand how SAD works (is it just, for CThresh as example, one pixel's chroma minus other pixel's chroma value and stored as an absolute?). MBThresh..it all depends on how sensitive you want the filter to be in keeping non-duplicate frames. Since I work with FFV1 (lossless RGB32 compression), assigning it to 1 would make it the most sensitive to any changes in the video, but I could very well see it keeping all the frames in an already compressed video. More tests would need to be run for this, but I think the current value of 100 works fine.
