Appearence of hardcodded subs

[Mildragon]

Hello everyone. I use Megui 2050 (svn) for video conversion from .mkv to .avi with embedded subs.

The "problem" is that in my final .avi output the embedded subs look a bit blurry.I mean they look blurry in their outline and in the space between a two-line subtitle.
Maybe blurry is not the right word to use but I don't know how I can explain it differently.

This problem becomes bigger when I use .ass insted of .srt subs.

Here are some sample photos:

1. With embedded .ass subtitles


2. With embedded .srt subtitles



Can I apply a filter (or do sth else) in order to decrease as much as possible this blurriness?

[jagabo]

I don't see a difference in sharpness. But the SRT subs are rendered with a drop shadow with a greater displacement and a lighter shade. How SRT subs are rendered depends on the player. If you're using a software sub renderer you might be able to change the font, font size, drop shadow displacement, and drop shadow shade. For example, here are the sub controls from MPCHC:

[Mildragon]

What does the player have to do with my problem? The subs are not external but hardcodded. The matter has to do with the converted sample outputs.

[jagabo]

I was using that as an example of the controls commonly found in subtitle renderers. You need to figure out what's rendering your subtitles in MeGUI (ffdshow?) and change its settings.

[dragonkeeper]

best solution, learn Japanese then you won't need subtitles .
I agree with jagabo i not able to discern a difference in the quality of the subs, they just appear to be rendered differently. But as for the video itself there are distinct differences in the video. The video with ass subs has lot of mosquito noise and the edges are a little blurry, edges in the srt image are sharper and the image looks smoother. Are you using the same filters on both encodes?

[Mildragon]

That's exactly the problem. You put it right, the video with the .ass subs has more noise than the other and "most of the noise" appears in the subs area. The odd thing is that I have used exactly the same filters in both conversions. Same resize filter, same resolution, same crop, same video bitrate. So, what the @#$% is going on? Can anybody help?

[poisondeathray]

Your screenshots are probably of different types of frames. The srt screenshot is probably an I-frame, but the ssa screenshot is likely a P or B frame. Look at the differences in edge noise around the neck and ears . You should compare similar frametypes

[jagabo]

The DCT ringing and macroblocking are at all high contrast edges in the first image. The video needs more bitrate, or to use a matrix that is less susceptible to DCT ringing.

[Mildragon]

@poisondeathray:

I didn't understand whtat you mean by I-frame or P/B-frame but I assure you that the photos are form almost identical .avi outputs.
And to prove my point, I assure you that every time I embed an aegisub subtitle using megui, I always have this problem. I am making one last try by using undot() in the .avs script to see what's going to happen.

[jagabo]

Upload a small source sample, and samples of the same segment after burning in the subs. And your scripts.

[poisondeathray]

I'm just saying your single screenshot comparison method is flawed. You're comparing "apples and oranges"

Xvid uses long GOP compression or interframe compression. There are different types of frames, I, P, B. Some get more bitrate than others and are higher quality
http://en.wikipedia.org/wiki/Group_of_pictures

The proof is in your post. Look at edge noise in the SRT screenshot, macroblocking in the cheek - but it's virtually clean in the SSA screenshot. If you were to compare a b-frame in the SRT video, it would probably look just as bad

[Mildragon]

o.k.guys I'll post the source and video output samples.

[Mildragon]

.mkv source: http://www.sendspace.com/file/5sgoga

.avi sample with embedded .ass subs: http://www.sendspace.com/file/bywir1

.avi sample with embedded .srt subs: http://www.sendspace.com/file/c7kji4

avs script: http://www.sendspace.com/file/ipwi4m

[jagabo]

I haven't looked at the files yet but here's and nearest neighbor enlargement of the two sample image you provided earlier:



The difference you're concerned about is all the little dots and lines around the text in the lower part of that image, right? Not the difference in the drop shadows, and not the differences between thickness of the black outlines around the text, right?

[Mildragon]

Yes, that's right !!! And please don't tell me that this is because xvid is a NON-lossless codec e.t.c. I have seen releases with emmbedded subs in .avi in standard definition which look great..... I just don't know the "trick" if you like.

[jagabo]

I'm not seeing a big difference in DCT ringing between the two encodings. When there is a little more in the ASS video I think it's caused by the thinner black borders and smaller, darker drop shadow. That is creating more high frequency coefficients (which are being dropped) and end up giving more ringing artifacts when decompressed. I don't know if TextSub() (or the ASS content) will allow you to specify thicker borders and a lighter, larger drop shadows for the ASS subs.

[Mildragon]

You can do all these you mentioned about .ass subs with Aegisub but the problem keeps going... either I raise or I reduce the video bitrate. Man, this is frustrating.... thanks anyway for your time. Really appreciated it.

[jagabo]

What matrix are you using in Xvid? h.263? mpeg? A custom matrix? h.263 gives a little less DCT ringing than mpeg. There are custom matrices that will probably give less ringing but I don't keep track of that. The easiest solution is to use more bitrate.

[Mildragon]

I use H.263. Probably the solution lies in the use of a custom matrix or the appliance of special video filters in the .avs script of which I don't know much. And though I'm willing to learn, I can't find any good guide...

No, it's not the video bitrate. I just converted with 2000 kb/sec and the problem remained.

[poisondeathray]

Your encoded files are already using ~1850kb/s . The source was 500kb/s (LOL)

I think something else is going on

I think it's your xvid encraw settings

[Mildragon]

Yes, when you convert from .mkv to .avi in same resolution you have to increase about 2x-3x the video bitrate (depending on the source) to have good results.

xvid encraw settings? please be more specific.... where to go, what to do.

[poisondeathray]

translation : what settings did you use for xvid ?

There are 2 versions of xvid. xvidvfw.dll, and xvidencraw.exe

Megui uses xvidencraw.exe . Vdub uses xvidvfw.dll

I just did a default "HQ" xvid 2pass 1850kb/s encode with srt subs , and the megui one was noticably worse in terms of edge noise than the vdub one when comparing same frame types

[Mildragon]

From the log (I also use 2pass HQ profile):

Job commandline: "C:\Program Files\MeGUI\tools\xvid_encraw\xvid_encraw.exe" -i "D:\Downloads\gt Season 2\dbgt35.mkv.avs" -pass2 "C:\Users\Mildragon\Desktop\dbgt35.mkv.stats" -bitrate 1999 -kboost 100 -chigh 30 -clow 15 -max_key_interval 250 -nopacked -qpel -lumimasking -imin 1 -pmin 1 -max_bframes 4 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1 -threads 2 -avi "C:\Users\Mildragon\Desktop\dbgt35.mkv.avi"


Maybe if I installed xvid 1.3......? But I don't think so....

[jagabo]

-max_bframes 4
-bquant_ratio 162
-bquant_offset 0
-qpel

These strike me as unusual. 4 bframes will cause many standalone players to choke. It also means you have a lot more low quality frames (bframes are encoded with lower quality). The default for quantizer ratio is 1.5 in Xvid (I would guess the megui "162" means 1.62) and quantizer offset is 1. The end result of this is probably that the bframes in the megui encode are higher quality than the bframes in a "normal" Xvid encode. But that means the quality of the I and P frames must be lowered to keep the same bitrate. And since I and P frames are used as reference for the B frames the extra DCT ringing will carry over.

Qpel also increases the bitrate requirement (in exchange for slightly better motion precision of slow moving objects).

[poisondeathray]

You can see in this nearest neighbor zoom , that bottom one, xvidvfw.dll is noticably better. These are both 1850kb/s, same 1000 frame sample, unfiltered, both are taken from b-frames.

I used 2pass HQ home theater preset. This limits max consec b-frames to 1. The xvidvfw settings I used were 2 I think (also home theater preset)

[Mildragon]

these are the usual settings I use:





Using 4 b-frames was just for "experimental reasons".

[Mildragon]

-max_bframes 4
-bquant_ratio 162
-bquant_offset 0
-qpel

These strike me as unusual. 4 bframes will cause many standalone players to choke. It also means you have a lot more low quality frames (bframes are encoded with lower quality). The default for quantizer ratio is 1.5 in Xvid (I would guess the megui "162" means 1.62) and quantizer offset is 1. The end result of this is probably that the bframes in the megui encode are higher quality than the bframes in a "normal" Xvid encode. But that means the quality of the I and P frames must be lowered to keep the same bitrate. And since I and P frames are used as reference for the B frames the extra DCT ringing will carry over.

Qpel also increases the bitrate requirement (in exchange for slightly better motion precision of slow moving objects).

After many (and when I say many I mean it) trials, I managed to decrease DCT ringigng by disabling Qpel and setting quantizer ratio in 1.5 and quantizer offset to 1. A little noise stil remained though. Thanks jagabo for the idea.

[jagabo]

Try using Deen() to clean up some of the noise around edges in the source. The default settings are usually ok for animated material.

[Mildragon]

Nope, nothing changed. Any other ideas anyone?