ffdshow tryouts project: Discussion & Development

[LotharZ]

Hi, I found 2 sub/idx (vobsub) files that seems ffdshow can't handle.

Track1 show the first line but then freezes and Track2 isnt showed. They were merged on a mkv file but no works in and out of the file.

They come from a Cromatine (anime) episode.
[a-s]_sakigaki!!_cromartie_high_school_-_23_-_stone_cold_crazy__ranmasaotome_[AC5956B4].mkv

Files: http://sharebee.com/ff3a1f10

At same time, I've a request, could you add a feature on the Subtitles section that discarts the SSA tangs on that kind of subs, It could be really useful to watch some subtitles that have annoying gothic fonts or extremely small sizes coded.

thx

[yesgrey]

Originally Posted by haruhiko_yamagata

Is it possible to auto-detect rec and pc?

I don't think so. The real question is that the conversion from YUV to RGB should translate the Y channel [0:255] to RGB [0:255]. The video black and white at YUV [16,16,16] and [235,235,235] should be converted to RGB [16,16,16] and [235,235,235], because it still exist video info bellow [16,16,16] and above [235,235,235]. If you use rec, the whites will be crushed, because all YUV values above [235,235,235] will be converted to RGB [255,255,255]. All dvd movies should be converted with pc values. This is the same thing between overlay mixer and VMR. Overlay mixer convert YUV to RGB using rec and VMR convert using pc, the way it should be. That's why we should prefer VMR for viewing instead of overlay mixer.

If you want to read more about this subject try this thread, which is very informative:
http://archive2.avsforum.com/avs-vb/...than+AND+black

[yesgrey]

haruhiko,
you have a PM.

[KoD]

yesgrey3, what you are saying and what the Microsoft engineers speak of in that article (it's Microsoft that asked of Nvidia and ATi too implement the VMR this way) is not the proper way. Don't trust what others say so much, read about color transforms from the specs yourself.

[haruhiko_yamagata]

Originally Posted by LotharZ

Hi, I found 2 sub/idx (vobsub) files that seems ffdshow can't handle.

Track1 show the first line but then freezes and Track2 isnt showed. They were merged on a mkv file but no works in and out of the file.

They come from a Cromatine (anime) episode.
[a-s]_sakigaki!!_cromartie_high_school_-_23_-_stone_cold_crazy__ranmasaotome_[AC5956B4].mkv

Files: http://sharebee.com/ff3a1f10

OK, confirmed. I can reproduce if I check "Obey positional settings from Subtitles page". If I uncheck it, I can watch the subtitles but its color is wrong.

At same time, I've a request, could you add a feature on the Subtitles section that discarts the SSA tangs on that kind of subs, It could be really useful to watch some subtitles that have annoying gothic fonts or extremely small sizes coded.

thx

It's not too hard to implement. The problem is that the dialog is too crowded.

[haruhiko_yamagata]

Originally Posted by yesgrey3

All dvd movies should be converted with pc values.

Is this correct? The color spaces are really confusing.

[Jeremy Duncan]

Originally Posted by haruhiko_yamagata

Is this correct? The color spaces are really confusing.

If you want to be sure. Post the question in this forum:
Link

[haruhiko_yamagata]

Originally Posted by yesgrey3

If we multiply the YUV->RGB matrix with the RGB->RGBdisplay matrix at the beggining, the YUV->RGBdisplay conversion could be done without any processing penalty.

Unfortunately it costs more CPU.

BT.709 color space conversion (please check if it is correct)

R=1.164(Y-16)+1.792(V-128)
G=1.164(Y-16)-0.2128(U-128)+0.5323(V-128)
B=1.164(Y-16)-2.111(U-128)

Here, to get R, we don't have to calculate x*(U-128).
If we want to support custom matrix, we have to calculate x*(U-128) for R and x*(V-128) for G. So it means we have to modify the asm code a lot.

[haruhiko_yamagata]

Originally Posted by Jeremy Duncan

If you want to be sure. Post the question in this forum:
Link

I have converted some DVD using pc601, which have resulted poor image. I think most DVD should not be converted with pc601. And yes, there are few DVD that should be converted with pc601. MPC seems to detect automatically and does a good job.

[yesgrey]

Originally Posted by KoD

yesgrey3, what you are saying and what the Microsoft engineers speak of in that article (it's Microsoft that asked of Nvidia and ATi too implement the VMR this way) is not the proper way. Don't trust what others say so much, read about color transforms from the specs yourself.

Where could I read about it?
I do not trusted them. What they said in that thread makes sense and is logical. I also have tryed to perform the conversion as they suggested and realized that it made sense to be that way. Maybe I am wrong and they are wrong, I don't know, but it's strange when the "wrong" way makes sense and the "correct" doesn't,
but maybe I am not seeing the whole picture...

[Wilbert]

@haruhiko_yamagata,

The correct formulas for YCbCr [16,235] <-> RGB [0,255] (Rec.709) are:

R=1.164*(Y-16)+1.792*(V-128)
G=1.164*(Y-16)-0.2129*(U-128)-0.5326*(V-128)
B=1.164*(Y-16)+2.113*(U-128)

as derived in http://avisynth.org/mediawiki/Color_conversions.

[yesgrey]

Originally Posted by haruhiko_yamagata

I have converted some DVD using pc601, which have resulted poor image.

Yes, I also agree that using pc601 the image is less appealling that using rec601, but it does not means that is the way it should be done. With rec601 the image has more contrast, which is more appealling, but you also get a crush in the whites. Very bright scenes became all white, instead of several shades of white. I have seen it in some movies.

[yesgrey]

Originally Posted by haruhiko_yamagata

Unfortunately it costs more CPU.Here, to get R, we don't have to calculate x*(U-128).
If we want to support custom matrix, we have to calculate x*(U-128) for R and x*(V-128) for G. So it means we have to modify the asm code a lot.

Yes, you are right. I forgot that without the custom matrix there are less two values to consider, which have to be considered when the matrices multiplication occur.

Maybe it's better the other option of using avisynth ConvertToRGB, since with it the code is already wrote to support the full matrix.

Thanks anyway!

[Wilbert]

Yes, I also agree that using pc601 the image is less appealling that using rec601, but it does not means that is the way it should be done. With rec601 the image has more contrast, which is more appealling, but you also get a crush in the whites.

Yes, but that's only a little crush. On DVDs black is centered around 16 and white is centered around 235. I say centered, because 16 is not the min and 235 not the max value, but those are averages. You can see this nicely with AviSynth and Limiter(show=true).

[yesgrey]

Originally Posted by Wilbert

Yes, but that's only a little crush. On DVDs black is centered around 16 and white is centered around 235. I say centered, because 16 is not the min and 235 not the max value, but those are averages. You can see this nicely with AviSynth and Limiter(show=true).

Yes, that's exactly the conclusion of the thread I have put the link. The more relevant is the data above 235, because the data bellow 16 is not supposed to be viewed, that's the reason for some people using a compromise solution, like: [14,245]->[0:255], and for this they use the filter levels. But if the conversion to RGB uses the rec mode, this cannot be done. That's why I suggest the conversion could also be done with the pc mode, so we can customize the output for our likings. ffdshow as it is now, is not very usefull for converting to RGB.

The use of the [0,255]->[0,255] is justified because they say it's a more smooth conversion from YUV to RGB which could cause less banding. For me, I think the best should be the compromise solution.

[Kado]

It looks like VMR9 uses the "set pixel aspect ratio in output media type" but evr and haali renderer don't.
with vmr9 video play wide but with evr and haali plays more 4:3 style with option enabled/intermediate and 4:3 for all with option disabled.
video info: size:704x480, sar:853/704, dar:853/480.
file is "[Hauu~].Higurashi.no.Naku.Koro.ni.Nekogoroshi-hen.(H264.Vorbis)[F654D046].mkv"

[thuan]

@Kado: I can play that file perfectly fine over here with Haali with everything is default.

EDIT: Which splitter are you using? Haali or Gabest?

[Kado]

I'm using haali splitter. in your system you get wide screen video with haali renderer for that file? in mine wide is only with vmr9...

[haruhiko_yamagata]

Originally Posted by chros

I tried to playback a dts-wav file (*.wav) with MPC and ffdshow v1381 , but no success ...
Filters: Wave Parser , ffdshow

in ffdshow codecs: DTS in wav is checked (nothing happens)
AC3filter can playback it (if I check PCM at system tab)

Anyone confirm it ? Or do I need something to set?
If it's a bug, can someone tell a working version number?

Thanks

I found the way.
* Enable "Uncompressed" and "Check for DTS in WAV" at the foot note of DTS.
* Raise the merit value.

[thuan]

Yeah, perfectly normal over here. Maybe you should try resetting your MPC settings for aspect ratio and related stuffs (settings under Video Frame and Pan&Scan).