Hi,
I was using the last stable staxrip (having problems muxing with the latest), and when i encoded something, i noticed it had deinterlace issues: it went horribly wrong during fast moving scenes.
So i looked at the script, and everything was fine with it, except that staxrip created a script where it cropped BEFORE deinterlace. Now, ive had read everywhere that you should FIRST deinterlace, then crop and resize. So i changed the script manually, and cut/paste the crop line after the deinterlace line. Then my encode look alright, NOTHING else was changed. So it was indeed a issue of crop before deinterlace.
Then i downloaded the latest staxrip, and thought this wouldve been fixed, but found out that staxrip STILL cropped before deinterlace.
Is this never mentioned before? I find it really weird, cause staxrip has been so long in development.
Below u can see what can happen if u crop BEFORE deinterlace:
Well, obviously, u can see something is wrong here.
Now, i will show a screenshot of crop AFTER deinterlace. NOTHING else from the script was changed!
As u can see, there is a big difference between the images. This only happens at high-motion scenes, which do happen a lot in sport encodes ;)
The deinterlace i used was Yadif, but i tested every other deinterlacer included with staxrip, but i got the same results with every deinterlacer i used....
So, isn't this a bug which should be fixed?
| Attachment | Size |
|---|---|
| StaxRip Diagnostic Files.7z | 6.58 KB |
| highlights_avisynth.txt | 233 bytes |
-
It seems you didn't notice the sticky 'How to post a bug report' and the support page, it explains posting the diagnostic file is mandatory, without this file, I have to ask a lot questions like this:
Did you disable the following option?:
Auto correct crop values (don't disable!)
Forces safe mod values for cropping. It's highly recommended not to change this option unless you know exactly what you are doing!
The filters dialog help explains that filters can be reordered using drag & drop.
Im sorry stax, i didnt knew a
Im sorry stax, i didnt knew a diagnostic file could be manually created. I thought it was something that only happens when staxrip crashes. Ive incuded it now in the opening thread (i cant include attachments in replies).
Im trying to give you as much info as possible, so u can sort this out :)
I also included the avs file staxrip created, as it seems it isnt FULLY included in the diagnostic file.
But as u pointed out already, i wasnt aware u could change the filter order. This way, the issue can be fixed by drag-and-droppping crop AFTER deinterlace.
And about the "Auto correct crop values (don't disable!)" option: i havent disabled it, im working with default settings (besides, it seems my weird aspect ratio problem is fixed in ur latest beta..).
So it seems to me, it has to do with the cropping before deinterlace. If you compare it with other mpeg4-gui tools, like megui, ull see that megui first deinterlaces, then crops :)
-
StaxRip is almost 8 years old and I don't remember having ever changed the crop/deinterlace order. If it's mod 4 then I suspect there is a bug in yadif.
-
It seems you use mod 16 to crop, still yadif fails. Please report this bug to the yadif author.
I also get this, when using
I also get this, when using another deinterlacer, like TomsMoComp.
So how can it be a yadif issue then?
Yes, im aware that staxrip is developed for so long, and i also find it very weird. Maybe it has to do with the source? Its a digital satellite capture btw.
-
Please upload a small sample, you can cut using DGIndex and upload using 2shared.com or mediafire.com.
Sample (25 MB):
Sample (25 MB): http://www.mediafire.com/?e1jg3jng3v1
-
Thanks for uploading the clip. It happens with Yadif and TomsMoComp but not with FieldDeinterlace and it happens only if top or bottom crop value is not mod 4. I'll have to research on this.
Ur right that it doesnt
Ur right that it doesnt happen with FieldDeinterlac, but for this source, FieldDeinterlace isnt a good option :)
I indeed just noticed then when cropped mod8, or not cropped at all, it gives a normal result
I know i mentioned this already, but has this nothing to do with the crop filter being BEFORE deinterlace? Cause having the crop filter after deinterlace seems to fix this issue :) MeGUI, another popular mpeg4 gui, also deinterlaces first, and then applies every filter. So it seems there is no harm in applying the deinterlace filter first?
-
Deinterlacing first is a bit slower but it's the best way to avoid the problem. The root of the problem is how the colors are stored.