1080i to 480i

[jagabo]

So this means any m2v you import into Virtualdub 1.9.8 will have messed up chroma if the video is interlaced.

Yes.

If the video is progressive YV12, I suppose there is no problem.

Yes, progressive YV12 is not a problem.

I wonder how many people know about this problem...

The author of VirtualDub is aware of the problem. His stance is that the fourcc YV12 is never interlaced. Interlaced YUV 4:2:0 should use a different fourcc. So he refuses to fix the problem.

[Anonymous344]

The author of VirtualDub is aware of the problem. His stance is that the fourcc YV12 is never interlaced. Interlaced YUV 4:2:0 should use a different fourcc. So he refuses to fix the problem.

That's a shame. The "messed up" chroma would then would be what is referred to as the chroma upsampling error (CUE) described here would it?

http://avisynth.org/mediawiki/Sampling

This source seems to think the output is unaffected, which it apparently isn't. There should be a thread on this somewhere. It sounds like a problem that must affect many people who might not even be aware of it. Virtualdub is often used in guides for basic conversions and the like, as it is relatively easy for people to use.

[jagabo]

The "messed up" chroma would then would be what is referred to as the chroma upsampling error (CUE) described here would it?

http://avisynth.org/mediawiki/Sampling

Yes.

[Anonymous344]

Oh well! In future, for NTSC material, I can get round the problem by using Dgpulldown to make a progressive NTSC file and importing that.

For PAL material, I'll have to use Virtualdubmod rather than Virtualdub. I'm just glad that at the moment I do not have to resize or recrop any PAL files. I assume if I were importing progressive material and resizing to PAL 720*576 dimensions, interlacing it and exporting it I wouldn't have a problem.

[Anonymous344]

I have the exact same situation - 1080i to 480p - as I had before, so I might as well re-open this thread. The transport stream with which I am working is very strange. I showed a sample to Manono, and he quite rightly gave this script as a solution.

AssumeTFF()
SeparateFields()
SelectEven()
LanczosResize(720,480)

SelectEven() was necessary because one field in two was full of strange blocky pixelation. I have solved the problem of the pixelation by demuxing the original transport stream with eac3to, which apparently clears the full range flag. Now that the pixelation is gone I am thinking of properly deinterlacing again, but dare not trespass further on Manono's time.

How else can I deinterlace this in Avisynth? Tempgaussmc_beta1 is too slow on my PC, so I need another way.

As the original is a movie, it might be progressive but encoded as interlaced, like a PAL DVD. I understand that movies are progressive by nature; however, I understood that all 50HZ HDTV broadcasts have to be interlaced. If the original is truly progressive, I do not understand how I can separate fields and step through them, because if the original is progressive, surely there are no fields to separate.

[poisondeathray]

I have solved the problem of the pixelation by demuxing the original transport stream with eac3to, which apparently clears the full range flag.

full range flag ? that has to do with luminance range, not interlacing . Maybe you're referring to something else ?

what do you have now ? you wouldn't deinterlace if it was progressive content, encoded as interlaced.

if you want a procedure/guideline for determining this:
http://neuron2.net/faq.html#analysis

if you are still not sure, post a sample.

[Anonymous344]

If you see a repeating field sequence like this:
... a a b b c c ...

then it is progressive video.

This is what I see, so it must be progressive after all. Before I demuxed with eac3to, there was heavy blockiness visible in the image, every other field/frame when I separated fields. Someone on another forum said that I had to demux with eac3to to remove the full range flag, and the blockiness disappeared. I did not really know what the full range flag was; I was just repeating what I had been told. The person who advised me was only interested in remuxing for playback and could not advise on conversion.

Thanks!

[poisondeathray]

So you did that on the original file (before eac3to) ? and it was progressive ?

Do you see "blockiness" with the script previewed normally ? without separating the fields ?

e.g.
MPEG2Source("video.d2v")

[jagabo]

Before I demuxed with eac3to, there was heavy blockiness visible in the image, every other field/frame when I separated fields. Someone on another forum said that I had to demux with eac3to to remove the full range flag, and the blockiness disappeared.

I suspect what happened is the different file extension means a different reader/splitter was used and maybe a different decompressor. And those different components decoded the video without errors.

[Anonymous344]

So you did that on the original file (before eac3to) ? and it was progressive ?

I did that on the post-eac3to file. On the original file it seems to be progressive too, though the blockiness makes it harder to tell.

Do you see "blockiness" with the script previewed normally ? without separating the fields ?("video.d2v")

Yes; although the blocks seem to be composed more of lines than blocks. I know I am not being very descriptive here ....

[Anonymous344]

I suspect what happened is the different file extension means a different reader/splitter was used and maybe a different decompressor. And those different components decoded the video without errors.

The new file extension for the video is .mkv, so that is probably why. I can open the mkv in Virtualdubmod. I can then render out a lagarith encoded AVI and write avisynth scripts pointing to the AVI to separate fields and look at the video.

[videopoo]

Why would you deinterlace footage that needs to go onto DVD?

[Anonymous344]

Why would you deinterlace footage that needs to go onto DVD?

Resizing interlaced footage is not a good idea, and I need to do some precise resizing and cropping.

[videopoo]

Resizing interlaced footage is not a good idea, and I need to do some precise resizing and cropping.

But why not? Deinterlacing interlaced footage destined for DVD isnt the best idea either?

[Anonymous344]

You cannot resize deinterlaced footage without leaving a mess. I need to ensure I have a progressive source and do not really want to argue about it.

[jagabo]

A smart bob from 1080i30 to 1080p60, resizing to 720x480, and reinterlacing will work best. For example:

(1080i TFF source)
AssumeTFF()
Yadif(mode=1, order=1)
BilinearResize(720,480)
SeparateFields()
SelectEvery(4,0,3)
Weave()

A quick/dirty alternative:

(1080i TFF source)
AssumeTFF()
SeparateFields()
BilinearResize(720,240)
Weave()

I would avoid the latter if you care about quality.

[Anonymous344]

Thank you, Jagabo. If I can decide once and for all that this is interlaced, I shall use the first method.

[jagabo]

If you want a sharper 480i image use a sharper resizing filter like BiCubic or Lanczos. Using TempGaussMC_beta1mod() will usually give better results than Yadif() but will be very very slow.

[Anonymous344]

Thank you. I really like Spline16, actually. TempGaussMC-beta1mod is far too slow on my PC...

[videopoo]

You cannot resize deinterlaced footage without leaving a mess. I need to ensure I have a progressive source and do not really want to argue about it.

Argue? Its your thread dude! What mess are you refering to? I've always kept interlaced footage interlaced if its for DVD. Im working on a Blu ray right now that requires me to convert form 1080i to p. Im not very happy about doing that so it interests me to know the technical reason behind all this.

[manono]

Here's his sample so you can understand what's going on:

http://rapidshare.com/files/410749919/Sample.demuxed.rar

It's the usual PAL progressive source encoded as interlaced. But, when separating the fields every other field is nasty looking. I tried both DGAVC and FFMPEGSource on it with the same results. So I suggested tossing out every other field and then resizing for DVD. Anything wrong with that? Or is there a way to decode it without nastiness every other field (sample needed for you to play around with)? It's a TV cap and my guess is that it was broadcast like that (or at least capped like that), although I could easily be wrong. The nastiness takes the form of little blocks, some seemingly interlaced.

And since it's already progressive, I have no idea why he's talking about deinterlacing it. It's a movie.

[jagabo]

Is that a PAFF/MBAFF problem?

[poisondeathray]

Not your AVC typical stream . This is a stream with gaps

If you run it through eac3to to mux it into a mkv container, it will attempt the repair the gaps

Once it's done, you can use dss2() , haali splitter, with ffdshow to decode, and it works fine

If you don't repair the gaps (e.g. just use mkvmerge without eac3to) , you will get frame repeats with dss2() + ffdshow, and other decoders will show combing

[manono]

Yeah, but if his end result is to be NTSC DVD is there any advantage to doing all that before resizing over just resizing every other good field to 720x480? I have a sneaking suspicion it's better to resize full frames rather than fields, but the result using my script looked good.

[jagabo]

DgAvcDec shows many problems with that clip. But ffdshow decodes it correctly (just a few black spots here and there). I think this means it uses PAFF and/or MBAFF. Meaning it's encoded progressively but some frames (PAFF) and some macroblocks (MBAFF) are encoded interlaced. DgAvcDec doesn't support that.

I muxed the elementary stream into a TS container with TsMuxer. Then ran DgAvcIndex on it. I opened the file with AvcSource() and DirectShowSource() -- so both were accessing the exact same file. AvcSource() uses DgAvcDecode to decode, DirectShow was using ffdshow. Sample crops:

AvcSource():


DirectShowSource() ffdshow decoding:


Does anyone know of a tool that can parse h.264 streams for PAFF/MBAFF?

[poisondeathray]

Yes DGAVCIndex is broken with PAFF streams , this has been documented extensively especially with AVCHD camcorder streams, AVC broadcast streams etc...

The difference with processing it though eac3to , is the frame repeats are gone. I guess you could use ffdshow and selecteven() or selectodd() , it would be faster

Does anyone know of a tool that can parse h.264 streams for PAFF/MBAFF?

You can use a stream analyser (eg. elecard streameye) . It will say :

mb_adaptive_frame_field_flag: 1

Even if MBAFF encoding is used, it can still be progressive content , and can be adaptive or non-adaptive. Same with PAFF; you can have adaptive or non adaptive . For example x264 uses MBAFF, but the adaptive nature hasn't been implemented yet.

DGAVCIndex can also tell you if MBAFF encoding is being used (when you preview, it will read MBAFF), and it can tell you if PAFF is really adaptive (it will flicker field/frame when you preview)

[Anonymous344]

So I suggested tossing out every other field and then resizing for DVD. Anything wrong with that? Or is there a way to decode it without nastiness every other field (sample needed for you to play around with)?

Manono, after I was advised to demux with eac3to it seemed to me that the problem with every other field had been solved. I wondered if there might be another way to handle the video but did not want to trouble you further. I was not trying to imply that anything in your advice was wrong.

And since it's already progressive, I have no idea why he's talking about deinterlacing it. It's a movie.

I was not sure that it truly was progressive, but now I am. (The 1080i tag confused me, and I am really uncertain about broadcasts, as I know little about them.) Thank you for the discussion, guys. I am trying my best to follow it.

[manono]

I was not trying to imply that anything in your advice was wrong.

No problem. I think I mentioned that I hadn't had much experience with this kind of video. You probably should have asked here first anyway (along with posting your sample immediately), because some of these guys really know their stuff. Me, I know DVDs, not these new-fangled videos.

[Anonymous344]

Thank you, Manono. I shall do what you suggest in future.

If you run it through eac3to to mux it into a mkv container, it will attempt the repair the gaps
Once it's done, you can use dss2() , haali splitter, with ffdshow to decode, and it works fine

Right, so it is necessary to decode with ffdshow: I cannot just open the MKV in Virtualdudmod, as usual, so I do this:

LoadPlugin("Whatever\avss.dll")
DSS2("Whatever.mkv")

From here on, I assume I am save to render out a lossless AVI and do whatever I want?

[jagabo]

I cannot just open the MKV in Virtualdudmod, as usual

If VirtualDubMod will open the MKV file (its MKV support is way outdated) you should be able to use ffdshow to decode the video. Just enable the VFW h.264 decoder.