AVIDemux is blurring the video, can't be turned off :(

[Fenyő]

Hi.

I've noticed a strange behaviour of AVIDemux during testing.

I have an interlaced video, and i was trying to deinterlace it.
No matter what deinterlace filter i choose, the results are the same! Some "ghost image" appears on the picture where fast motion occurs.

To help you understand the problem, i show you some pictures.
This is the original interlaced frame:


And this is the yadif-deinterlaced in AVIDemux:

Do you see the pink "ghost" on the white wall?

But in Virtualdub: no problem, it seems as it has to be: (yadif-deinterlace)


This symptom can have only one explanation: AVIDemux is blurring/smoothing every frame once it decodes, before any further processing.

And i think this can be noticeable on this image, its AVIDemux natural, no filters selected at all:

If you zoom in (with paint forexample) you can see the white lines between the red, they're actually pink already.

I've searched the application for this option to turn it off, but i've did not find it.

Is it just me who didn't find this switch in AVIDemux, or is this software a real useless crap?

I was about to change VirtualDub-x264vfw to AVIDemux-x264, but now i think i'll stay with VirtualDub.

So you guys, what do you know about this blurring thing? Is it intentional or not?

(i used huffyuv for the examples because its lossless)


Fenyo

PS: Ouh, and i used Avidemux 2.5.3

[LoRd_MuldeR]

(1) Make you that you have disabled all post-processing (deblocking, deringing, etc) in Avidemux under "Video" -> "Postprocessing". Uncheck all filters and set "Filter strength" to 0.

(2) I suggest inspecting the original interlaced video using the "Stack Fields" filter. If there is "ghosting" (blending) already present in the individual fields, the deinterlacer can't magically fix it.

(3) When you converted the original interlaced video to HuffYUV, I hope you used the YUY2 colorspace and not YV12, as the chroma sub-sampling would have destroyed the interlace...

[Fenyő]

Originally Posted by LoRd_MuldeR

(1) Make you that you have disabled all post-processing (deblocking, deringing, etc) in Avidemux under "Video" -> "Postprocessing". Uncheck all filters and set "Filter strength" to 0.

Of course i've disabled them! That was the first thing i checked. (forgot to mention this, sorry)

Originally Posted by LoRd_MuldeR

(2) I suggest inspecting the original interlaced video using the "Stack Fields" filter. If there is "ghosting" (blending) already present in the individual fields, the deinterlacer can't magically fix it.

Good idea!
And yes, "ghosting" is already present in the individual fields, and of course the deinterlacer can't fix it.
But this "ghosting" is not encoded in the source video! That's the thing i'm talking about.

Originally Posted by LoRd_MuldeR

(3) When you converted the original interlaced video to HuffYUV, I hope you used the YUY2 colorspace and not YV12, as the chroma sub-sampling would have destroyed the interlace...

The original interlaced video is already in HuffYUV, because i created it, i recorded it with an analog TV tuner card with DScaler. I used YUY2 colorspace when recording. (if i remember correctly, or maybe RGB24)

You know what? Check it yourself! I've just created a 16 MByte sample, i've copied around 2 seconds from this recorded video (covering this picture above) with VirtualDub direct stream copy.
You can download it here: Sample HuffYUV Video
Open it with AVIDemux, use Stack Fields, and you can see the ghosting.
Then open it with VirtualDub, use deinterlace filter in "Unfold fields side-by-side" mode, and you can see there's no ghosting!!

[LoRd_MuldeR]

I checked your sample file, but I fail to see any obvious artifacts in Avidemux.

Also I can't see any obvious difference between Avidemux and VirtualDub when inspecting the individual fields:

[Fenyő]

Originally Posted by LoRd_MuldeR

I checked your sample file, but I fail to see any obvious artifacts in Avidemux.

Also I can't see any obvious difference between Avidemux and VirtualDub when inspecting the individual fields:

Aaah.... Its a bad example-frame!
Check frame 18 !!
Look at this:

[LoRd_MuldeR]

Your example clip only has 14 frames

[Fenyő]

Originally Posted by LoRd_MuldeR

Your example clip only has 14 frames

No, you're wrong! Its exactly 47 frames long!

And its obvious from your pictures, that you've opened some test1-FIXED file.

Check your file, here is its MD5: d6d4d260bf4e7db2e4a70e660bcb23dd
Exact file size is: 16 647 132 Bytes.
Maybe your download is corrupted.

[LoRd_MuldeR]

Originally Posted by Fenyő

And its obvious from your pictures, that you've opened some test1-FIXED file.

That's because your example file was broken (probably missing index) and Avidemux refused to open it.

VirtualDub showed a bunch of warnings but managed to re-construct the index. It got exactly 14 frames, the last (15th) frame in VirtualDub always is empty.

I had to "repair" your sample file with AVI Mux-GUI in order to open it in Avidemux for the comparison. Again only 14 frames

[Fenyő]

Originally Posted by LoRd_MuldeR

That's because your example file was broken (probably missing index) and Avidemux refused to open it.

VirtualDub showed a bunch of warnings but managed to re-construct the index. It got exactly 14 frames, the last (15th) frame in VirtualDub always is empty.

I had to "repair" your sample file with AVI Mux-GUI in order to open it in Avidemux for the comparison. Again only 14 frames

As i have said: Your download is corrupted.
Now i'm completely sure about this.
Check file size!!

[LoRd_MuldeR]

Originally Posted by Fenyő

As i have said: Your download is corrupted.
Now i'm completely sure about this.
Check file size!!

Okay, I re-downloaded the file and it seems the complete file is available now.

I indeed can see the issue on frame #18 and my assumption is that Avidemux, which uses YV12 as "internal" processing format, screwed up the YUY2 to YV12 conversion!

Avidemux probably assumed that the input is progressive, which of course is fatal when converting interlaced YUY2 to YV12

Workaround: Feed the input into Avidemux using the AVS Proxy with a simple script like this:

FFVideoSource("test1.2nd.avi")
ConvertToYV12(interlaced=true)

(For test you can change the last line in the script to "interlaced=false" and you'll see the problem returns, which confirms my theory)

[Fenyő]

Yes! Indeed, your theory is right!

With that script the ghosting is eliminated.

(BTW, its a shame for AVIDemux that it needs extra software to handle AviSynth AVS files, complicating the already not simple video editings with AviSynth. -VirtualDub handles AVS naturally, so one more good-point to good old VirtualDub)

So this is not a normal function after all. ...as i thought.

You know, if i haven't tested this video with AVIDemux, probably i would use AVIDemux now, including these glitches to my videos, and who knows when would i realize that why all my videos becoming ghosted...
And probably most of the users do not even realize this problem, and they're producing videos with this ghosting to the general public.

I think this problem is essential, and i think converting video to an internal format (especially if it is 4:2:0) is quite a bad idea! (not efficient, unnecessary conversions, and making the overall video quality worse)
It should have process the video in its original format, and by this it would avoided this problem. As you can see, VirtualDub don't has this problem at all. Why? (another good point to VirtualDub)
I don't know if the creators of AVIDemux reading this forum and this thread, but i think it's time to rewrite some code in AVIDemux...

So till its been fixed, i won't use AVIDemux, and i'll stay with VirtualDub.

[LoRd_MuldeR]

Originally Posted by Fenyő

Yes! Indeed, your theory is right!

With that script the ghosting is eliminated.

(BTW, its a shame for AVIDemux that it needs extra software to handle AviSynth AVS files, complicating the already not simple video editings with AviSynth. -VirtualDub handles AVS naturally, so one more good-point to good old VirtualDub)

So this is not a normal function after all. ...as i thought.

Nope, actually the AVS Proxy is an extremely smart utility

Avisynth 2.x and VirtualDub are Windows-only software and the development of Avisynth 3.x is dead. At the same time Avidemux is Cross-Platform (Windows, Linux, Mac OS X).

Thanks to the AVS Proxy, we can run Avidemux as a native Linux process, while AVS Proxy + Avisynth can run inside Wine. This allows AVS input on Windows and Linux

Moreover swapping out Avisynth into its ownprocess also has the advantage that both, Avidemux and Avisynth, can allocate up to 2 GB of memory each.

(If both would run inside the same process, they would have to share the 2 GB of memory that each 32-Bit process can allocate at maximum, which indeed can be problem!)

Originally Posted by Fenyő

You know, if i haven't tested this video with AVIDemux, probably i would use AVIDemux now, including these glitches to my videos, and who knows when would i realize that why all my videos becoming ghosted...
And probably most of the users do not even realize this problem, and they're producing videos with this ghosting to the general public.

I think this problem is essential, and i think converting video to an internal format (especially if it is 4:2:0) is quite a bad idea! (not efficient, unnecessary conversions, and making the overall video quality worse)
It should have process the video in its original format, and by this it would avoided this problem. As you can see, VirtualDub don't has this problem at all. Why? (another good point to VirtualDub)
I don't know if the creators of AVIDemux reading this forum and this thread, but i think it's time to rewrite some code in AVIDemux...

So till its been fixed, i won't use AVIDemux, and i'll stay with VirtualDub.

Well, you must agree on some "internal" color format, because it's practically impossible to write each video filter n-times, once for each color format.

VirtuaDub, for example, converts everything to RGB32 for internal processing!

However using YV12 as the "internal" format, as Avidemux does, makes a lot of sense, because the great majority of all sources are YV12 (4:2:0) and basically any video encoder takes YV12 as input.

Just a few examples: MPEG-2 video from Video-DVD or DVB-T/S/C uses YV12, interlaced or not! H.264/AVC from BluRay or DVB-S2 uses YV12. Both, x264 and Xvid, exclusively take YV12 input.

Consequently using YV12 as the "internal" format will avoid unnecessary color-space conversions in 99% of all cases, while RGB32 would enforce two conversions in 99% of all cases.

So I would suggest you stop grumbling, until you know all the facts that have lead to certain implementation decisions

[Fenyő]

Originally Posted by LoRd_MuldeR

...At the same time Avidemux is Cross-Platform (Windows, Linux, Mac OS X).

Okay, but the windows version could still use AviSynth naturally, without any proxies...

Originally Posted by LoRd_MuldeR

we can run Avidemux as a native Linux process, while the AVS Proxy + Avisynth can run inside Wine.

And you can also run AviDemux in Wine too.

Originally Posted by LoRd_MuldeR

because you can't write any video filter n-times, once for each color format.

Why not? I know its a little time consuming, but i think its worth it. At least the most widespread formats, like YUY2, RGB24 and YV12. It's just three!

Originally Posted by LoRd_MuldeR

Consequently using YV12 as the "internal" format will avoid unnecessary color-space conversions in 99% of all cases, while RGB32 would enforce such conversions in 99% of all cases...

I must admit its more than i thought, but i wouldn't say 99%...
I'm using HuffYUV which handles only YUY2 and RGB so YUY2 is mostly used at least here. (i think Divx accepts RGB too)

Anyway, i think a fix is still necessary for this problem.
At least a dialog box when AVIDemux sees that a color conversion is required for the input file, it could ask the user whether the input file is interlaced or not, and using the correct conversion depending the user answer instead of assuming it progressive.

[Gavino]

Originally Posted by Fenyő

It should have process the video in its original format, and by this it would avoided this problem. As you can see, VirtualDub don't has this problem at all.

As LoRd_MuldeR has said, VirtualDub converts to RGB for most internal filters.
As far as I know, it does not correctly process interlaced YV12 when doing this conversion to RGB.

[Fenyő]

Originally Posted by Gavino

As LoRd_MuldeR has said, VirtualDub converts to RGB for most internal filters.
As far as I know, it does not correctly process interlaced YV12 when doing this conversion to RGB.

I don't know that, but i'm using YUY2.

So. Is it possible that this dialog box feature will appear in the next version of AVIDemux?

[GodofaGap]

Originally Posted by LordMulder

VirtuaDub, for example, converts everything to RGB32 for internal processing!

This is pertinently not true. Since quite a while internal VirtualDub filters work in multiple color spaces. The deinterlacers also work in a 4:2:2 format.

And now you know why VirtualDub doesn't support the interlaced YV12 hack from e.g. Avisynth.

[LoRd_MuldeR]

Originally Posted by GodofaGap

This is pertinently not true. Since quite a while internal VirtualDub filters work in multiple color spaces. The deinterlacers also work in a 4:2:2 format.

And now you know why VirtualDub doesn't support the interlaced YV12 hack from e.g. Avisynth.

Well, VirtualDub certainly used RGB32 as "internal" processing format not too long ago. Maybe I didn't follow the development close enough.

Nonetheless, if VirtualDub now uses YV12 or even YUY2 for processing, then it's only the logical step into the right direction, as it will avoid unnecessary conversions.

And it also means that now VirtualDub and Avidemux actually do the same in 99% of all cases, as 99% of all sources available to customers are YV12 and all relevant encoder use YV12 input as well.

Moreover I wouldn't call "interlaced YV12" a hack, because that's what is used almost everywhere, including all the commercial broadcast (DVB-S/T/C) and discs (Video-DVD/BlueRay).

Remember: Both, H.264 and MPEG-2, don't even support 4:2:2 or 4:4:4, except for special profiles - and those profiles generally aren't support in consumer hardware

Originally Posted by Gavino

As LoRd_MuldeR has said, VirtualDub converts to RGB for most internal filters.
As far as I know, it does not correctly process interlaced YV12 when doing this conversion to RGB.

Well, taking GodofaGap's post into consideration, it seems VirtualDub nowadays won't necessarily do a conversion to RGB32.

...which only means it works more like Avisynth and Avidemux now

Originally Posted by Fenyő

Okay, but the windows version could still use AviSynth naturally, without any proxies...

Yes, we could re-write Avidemux from the scratch for each platform... Or we write proper Cross-Platform code once

Originally Posted by Fenyő

And you can also run AviDemux in Wine too.

Yes, we could run Avidemux under Wine, which is running under a Linux, which is running inside a VM, which is running on a Windows host, which is running inside yet another VM, which is...

Or we can run Avidemux as a native application, which still is the fastest and most robust and most simple way to run an application

Originally Posted by Fenyő

Why not? I know its a little time consuming, but i think its worth it. At least the most widespread formats, like YUY2, RGB24 and YV12. It's just three!

Well, when it's so easy to do, feel free to extend Avidemux' filter system to multiple color spaces and also feel free to re-write all filter for the missing color spaces.

We are waiting for your patch...

Originally Posted by Fenyő

I must admit its more than i thought, but i wouldn't say 99%...
I'm using HuffYUV which handles only YUY2 and RGB so YUY2 is mostly used at least here. (i think Divx accepts RGB too)

(1) Obviously you converted your original source to HuffYUV, which indeed handles YUY2. But the original source came via DVB-S/T/C, so it was (interlaced) YV12 before you converted it to YUY2 ...which means you didn't loose any information when you did the YV12 -> YUY2 conversion, but you certainly didn't gain any information either.

(2) DivX is an MPEG-4 ASP encoder. And as any modern video compression format, MPEG-4 ASP works in the YUV color space. If the DivX encoder software takes RGB data as input, then this only means that it will convert your input RGB data to YV12 internally. Nothing more, nothing less...

Originally Posted by Fenyő

Anyway, i think a fix is still necessary for this problem.
At least a dialog box when AVIDemux sees that a color conversion is required for the input file, it could ask the user whether the input file is interlaced or not, and using the correct conversion depending the user answer instead of assuming it progressive.

The "problem" is that when you feed YUY2 data into an application and that application converts the data to YV12 - and sooner or later it MUST be converted to YV12, as all the relevant encoders require YV12 input - it must assume either "interlaced" or "progressive" chroma layout. Whatever you pick might be wrong or correct. It depends solely on the source. There's no easy fix for all cases...

[Fenyő]

Originally Posted by LoRd_MuldeR

(1) Obviously you converted your original source to HuffYUV, which indeed handles YUY2. But the original source came via DVB-S/T/C, so it was (interlaced) YV12 before you converted it to YUY2 ...which means you didn't loose any information when you did the YV12 -> YUY2 conversion, but you certainly didn't gain any information either.

As i have said it before, i DID NOT CONVERT this material, i recorded it from an _ANALOG_ tv-tuner card, Pinnacle PCTV. It has nothing to do with any DVB standard. So it was an analog broadcast, and the tuner's native color output is YUY2.

Originally Posted by LoRd_MuldeR

The "problem" is that when you feed YUY2 data into an application and that application converts the data to YV12 - and sooner or later it MUST be converted to YV12, as all the relevant encoders require YV12 input - it must assume either "interlaced" or "progressive" chroma layout. Whatever you pick might be wrong or correct. It depends solely on the source. There's no easy fix for all cases...

What are you talking about??
If i use AVIDemux, the video will be converted to YV12 in the first step EVERY TIME! So AVIDemux has to know if it is interlaced or progressive to the correct conversion.
And as you well know, most of the encoders have a switch, so the user can tell the encoder that the source is interlaced or not. (but it does not solve this AVIDemux-problem)

[Fenyő]

I'm telling you some interesting:
The Cable network here is UPC, (of course they are providing digital tv along with the analog) and their DVB-C system uses Nagravision-3 which pairs their mediabox with their card, so i can't use dreambox or other cool things.
And of course i can not retrieve my recorded content in its original MPEG stream format from the mediabox. The only way to get the content is the HDMI output of the box. So i have an Avermedia AverTV CaptureHD card, which has an HDMI input, and i can capture the uncompressed video signal.
And it's native color output: YUY2 ...Surprise-surprise i can only select YUY2, YVYU, UYVY in the driver's properties. So all i capture from UPC's DVB-C system is coming in YUY2 format. (i don't know if the UPC-box is the one which converts the originaly YV12 to YUY2, or the Avermedia card, but i can not change the fact that i get it in YUY2)

[LoRd_MuldeR]

Originally Posted by Fenyő

As i have said it before, i DID NOT CONVERT this material, i recorded it from an _ANALOG_ tv-tuner card, Pinnacle PCTV. It has nothing to do with any DVB standard. So it was an analog broadcast, and the tuner's native color output is YUY2.

So you are capturing as YUY2 from your "mediabox" with a capture card. Still the original MPEG-2 streams that arrived at your "mediabox" via DVB-C was YV12 (4:2:0).

Consequently you don't have "true" YUY2 (4:2:2), you only have an upconverted YUY2, which was upconverted from 4:2:0 somewhere along the way - either by the capture card or by the "mediabox" itself.

This means that going form the upconverted YUY2 back to YV12 causes absolutely no loss, because you can't loose any information that never was there...

Originally Posted by Fenyő

What are you talking about??
If i use AVIDemux, the video will be converted to YV12 in the first step EVERY TIME! So AVIDemux has to know if it is interlaced or progressive to the correct conversion.
And as you well know, most of the encoders have a switch, so the user can tell the encoder that the source is interlaced or not. (but it does not solve this AVIDemux-problem)

I'm talking about the fact that practically any source available to customers is YV12, so in 99% of all cases NO conversion will happen at all!

Converting from YV12 to YV12 is a NOP

Moreover if you feed Avidemux with YUY2 data that was upconverted from an original YV12 source, then a conversion does happen, but NO information/detail is lost in that case (see above).

Last but not least, even if you had a "true" YUY2 source that actually uses the full 4:2:2 chroma resolution (NOT upconverted), you would still have to downconvert to YV12 at some point in the processing chain!

That's because, as mentioned several times before, all the relevant video encoders (x264, Xvid, etc.) exclusively support YV12 input. YUY2 is either reject by the encoder or downconverted "internally".

Conclusion: Using YV12 as "internal" processing format does NOT cause a conversion in the great majority of all cases. And in the rare cases where it does, the conversion would have been unavoidably anyway