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

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

Fenyő

24th October 2010, 04:07

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:
http://fenyo1.web.elte.hu/avidemux/VirtualDub+interlaced.png

And this is the yadif-deinterlaced in AVIDemux:
http://fenyo1.web.elte.hu/avidemux/AVIDemux+yadif.png
Do you see the pink "ghost" on the white wall?

But in Virtualdub: no problem, it seems as it has to be: (yadif-deinterlace)
http://fenyo1.web.elte.hu/avidemux/VirtualDub+yadif.png

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:
http://fenyo1.web.elte.hu/avidemux/AVIDemux+interlaced.png
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

24th October 2010, 13:03

(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ő

24th October 2010, 20:06

(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)

(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.

(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 (http://fenyo1.web.elte.hu/avidemux/test1.avi)
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

24th October 2010, 20:27

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:

http://img842.imageshack.us/img842/2084/test1vdub.th.png (http://img842.imageshack.us/img842/2084/test1vdub.png) http://img830.imageshack.us/img830/6049/test1adm2.th.png (http://img830.imageshack.us/img830/6049/test1adm2.png)

Fenyő

24th October 2010, 21:37

LoRd_MuldeR

24th October 2010, 21:39

Your example clip only has 14 frames :p

Fenyő

24th October 2010, 21:46

Your example clip only has 14 frames :p
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

24th October 2010, 22:03

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ő

24th October 2010, 22:05

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

24th October 2010, 22:15

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 :rolleyes:

Workaround: Feed the input into Avidemux using the AVS Proxy (http://avidemux.org/admForum/viewtopic.php?id=4397) 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ő

24th October 2010, 23:14

LoRd_MuldeR

24th October 2010, 23:27

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 :cool:

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!)

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 :rolleyes:

Fenyő

25th October 2010, 00:00

...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...

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. :)

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!

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

25th October 2010, 00:34

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ő

25th October 2010, 00:42

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

25th October 2010, 07:50

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

25th October 2010, 08:45

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 :rolleyes:

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 ;)

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 ;)

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 :p

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... :)

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...

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ő

25th October 2010, 20:34

(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.

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ő

25th October 2010, 20:52

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

25th October 2010, 21:25

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...

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 :p

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 ;)

Fenyő

25th October 2010, 22:20

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 somewhere along the way - either by the capture card or by the "mediabox" itself.
Would you just READ me before you write, please?
I have TWO capture cards:
1) Pinnacle PCTV pro - i capture ANALOG TV-signals with this, so I HAVE TRUE YUY2 this way, NOT UPCONVERTED. (i used this one for the example above)
2) AverMedia AverTV CaptureHD - i capture HDMI-signals with this (they're coming from the UPC DVB-C Set-Top-Box (they call it "mediabox"))

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).
Except when an interlaced YV12 is converted to YUY2 (converted knowing its interlaced). If you feed Avidemux with this stream it will make it "ghosty" (because Avidemux converts assuming progressive)

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!
Except when i use an encoder which uses YUY2, like HuffYUV. (imagine: i capture something in true YUY2, and i want to edit and make a short cut of it before the final encode, so input is YUY2, and output is also YUY2. (and i can not make this two pass in one pass))

LoRd_MuldeR

25th October 2010, 22:31

Would you just READ me before you write, please?
I have TWO capture cards:
1) Pinnacle PCTV pro - i capture ANALOG TV-signals with this, so I HAVE TRUE YUY2 this way, NOT UPCONVERTED. (i used this one for the example above)
2) AverMedia AverTV CaptureHD - i capture HDMI-signals with this (they're coming from the UPC DVB-C Set-Top-Box (they call it "mediabox"))

I'm getting tired of your aggressive tone. So would you please calm down or I'll close this thread :rolleyes:

Anyway, the actual chroma resolution of an analog capture probably is far below a native "digital" 4:2:0 source, not to speak about 4:2:2.

If you don't believe, you can check yourself with a script like this on your example file:

Original = FFVideoSource("test1.2nd.avi")
Downconverted = Original.ConvertToYV12(interlaced=true).ConvertToYUY2(interlaced=true)
Interleaved = Interleave(Original.Subtitle("Original"), Downconverted.Subtitle("Downconverted"))
Separated = Interleaved.SeparateFields()
StackVertical(Separated.SelectEven(), Separated.SelectOdd())

Except when an interlaced YV12 is converted to YUY2 (converted knowing its interlaced). If you feed Avidemux with this stream it will make it "ghosty" (because Avidemux converts assuming progressive)

It seems here you didn't read. Interlaced YV12 works perfectly fine - with the proper chroma layout.

So the problem is not caused by the YUY2 to YV12 conversion, but by the fact that the conversion was done wrongly in this particular case.

As has been proven by the suggested Avisynth script, doing the conversion correctly yields perfectly fine YV12 output...

Except when i use an encoder which uses YUY2, like HuffYUV. (imagine: i capture something in true YUY2, and i want to edit and make a short cut of it before the final encode, so input is YUY2, and output is also YUY2. (and i can not make this two pass in one pass))

Why would you keep YUY2 in your intermediate HuffYUV file? Once you do the final encode to MPEG-2/MPEG-4 ASP/H.264 you'll convert to YV12 anyway :p

And, to begin with, you will rarely (if at all) have a source that actually contains "true" 4:2:2 chroma information...

Fenyő

25th October 2010, 23:24

I'm getting tired of your aggressive tone. So would you please calm down or I'll close this thread :rolleyes:
Aggressive? Me? Why do you feel that? I think i have not used vulgar words, and characters like "?????" or "?!?!?".

It seems here you didn't read. Interlaced YV12 works perfectly fine - with the proper chroma layout.
No, it seems you are the one again, who didn't read. I'm talking about a YUY2 interlaced video (which was created from a YV12 interlaced before)
What is the difference between this YUY2 video and the video i presented on the first page? AVIDemux will make it ghosty just like my original YUY2 video.
Or if you want, i can capture you an 1080i sample video with my Avermedia HDMI card in YUY2, so you could see that AVIDemux make it ghosty when you open this vid.

So the problem is not caused by the YUY2 to YV12 conversion, but by the fact that the conversion was done wrongly in this particular case.
Exactly! This is why i say AVIDemux could ask the user whether the video is interlaced or not when opening a file. BUT just in the cases when AVIDemux has to use color conversion. (obviously no point to ask it in case when the input is YV12)

Why would you keep YUY2 in your intermediate HuffYUV file?
Because i want a lossless codec... ?
(i think you well know that LossLess->LossLess->Lossy conversion gives better overall quality than LossLess->Lossy->Lossy conversion)

And again, you will rarely (if at all) have a source that actually contains "true" 4:2:2 chroma information...
That's not the point. All the main problems we have is because of interlaced videos. Especially intelaced YUY2 videos in this case. (well, the real problem is that AVIDemux does not ask the user about the vid in these cases)

LoRd_MuldeR

25th October 2010, 23:28

As the original issue of this thread has been resolved and the further discussion is leading nowhere, I'll close this...

~closed~