Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-2 Encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th February 2004, 14:22   #21  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
No, in this case I would use the exact same settings. I think it really comes down to that we should replicate the original encode settings in CCE.
RB is offline   Reply With Quote
Old 20th February 2004, 06:46   #22  |  Link
Matthew
jdgljlfljg
 
Join Date: Jan 2002
Location: Tony Abbott's electorate
Posts: 1,393
Thanks RB, that makes me feel better. Well, at least it did.

I (finally) replicated unplugged's experiment on an interlaced/zigzag PAL DVD and skipped to a red area. The results, to my eyes, appeared better with interlaced=false.

Specifically, in the top left corner of the picture where the red met the black border, there are clear lines showing in the transition area when interlaced=true is used. [This is with 300 percent zoom, obviously]. The same problem is there as the red moves along the top edge (it's a person's hat).

I have 2 psd screenshots (1.7 MB compressed) that I can provide on request (I have webspace). Just open in photoshop and zoom in :/

edit: just tried it with an interlaced/alternate source (Chicago R4), and noticed the same phenomenon, this time with blue against the black border, as well as red against the black border.

Also, noticed for the "main" picture that blue edges against a black background and red edges against black backround clearly looked better with interlaced=false.

Last edited by Matthew; 20th February 2004 at 07:26.
Matthew is offline   Reply With Quote
Old 20th February 2004, 12:44   #23  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Interesting... what did BitrateViewer report for DCT and frame type? "Frame" or "Field"?
RB is offline   Reply With Quote
Old 20th February 2004, 12:53   #24  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
The Scan order (ZigZag or Alternate) has nothing to do with the colors itself. It is only the methode, how to read the Data in an Block. Y- Cb- and Cr-Blocks are stored separated in a MPEG-File, so the Scan order can't have any influence of the Colors.
Kika is offline   Reply With Quote
Old 20th February 2004, 13:42   #25  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Hi Kika

So, is http://www.bretl.com/mpeghtml/zigzag.HTM wrong then?
Quote:
The zig-zag scanning pattern for run-length coding of the quantized DCT coefficients was established in the original MPEG standard. The same pattern is used for luminance and for chrominance.
RB is offline   Reply With Quote
Old 20th February 2004, 13:46   #26  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
No, that's correct. But the Blocks are separated. One Macroblock = 4 Luma- and 2 Chroma-Blocks.

Lu Lu Lu Lu
Cb Cr
Kika is offline   Reply With Quote
Old 20th February 2004, 14:31   #27  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Ok, I'm getting a little lost here, too...

Kika, I know you are good at this, so what's your opinion on the whole picture here? Is there any way to tell exactly whether the source should be converted to YUY2 with interlaced=false or true, whithout having to visually inspect the result beforehand every time? Logic suggests that when the source is encoded as interlaced/alternate, we really should be using ConvertToYUY2(interlaced=true), but Matthew obviously proved this wrong...

@Matthew:
What did you use to play the AVS and take the screenshots? Maybe to eliminate the influence of any external video codecs, it would be best to use AVISynth's ImageWriter() function to take the "screenshots".
RB is offline   Reply With Quote
Old 20th February 2004, 15:10   #28  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
@RB

I'm not good on explanations in english...

OK, let's try. Scan order and Macroblock are belonging to the Compression part itself. In YUV4:2:0, that's the Format for MPEG2, you have 4 Blocks of Y, one Block of Cb and one Block of Cr. The Scan order descripes only in which order the Datas should be readed. For each Block, the same Scan order is used, but the blocks are handled one after each other.
On a progressive Picture, the Scan order does not matter for reading the informations. Only if you try to use ZigZag to decode a Alternate encodet Video (or vice versa) you will have a big mess.

After decoding a Picture, things are changing. After that, you a Picture in YUV Colorspace, which must be handled the right way.
No mater, if a progressive Video is encodet in interlaced or progressive Mode, after Decoding to a Picture, it should be a progressive one and be handled as a progressive Picture.
So, in this special case, Interlace=true is the wrong way.
Kika is offline   Reply With Quote
Old 20th February 2004, 15:39   #29  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Your English is just fine But feel free to PM me in German any time, I'll post the translated reply.

OK, but have you read this post that I referenced earlier in this thread? This guy seems to know what he's talking about. What I get from this post is: assume the studio took the really progressive film material and for some reason (as on many DVDs) encoded it as interlaced/alternate. Now to quote FMalibu:
Quote:
... a progressive mode coded chroma sample contains information for 2 directly adjecent lines (e.g. C1,2) ... In the case of an interlaced mode coded sample, it will contain information for alternating lines (e.g. C1,3)
So in this case the croma is indeed stored differently, it doesn't matter that the original source was progressive. Ergo we should use interlaced=true, and we should also reencode as interlaced/alternate although progressive/zigzag probably wouldn't make much difference. Don't you agree with this?
RB is offline   Reply With Quote
Old 20th February 2004, 16:03   #30  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
Oops, you'r right and FMalibu too. Sorry, my fault, i messed up some things (this may have happend in german too ).

Although the source video was progressive, it will be handled as interlaced while decoding if you use interlaced Mode while encoding.
So my first statement is wrong. We have to use Interlace=true to get the correct decodet Video.

However, what i wrote about the Scan order was correct. It does not have a direct influence to the Colors.

If the source is an interlaced encodet progressive Video, you should use interlaced=true on any colorspace conversion.
Kika is offline   Reply With Quote
Old 20th February 2004, 23:36   #31  |  Link
Matthew
jdgljlfljg
 
Join Date: Jan 2002
Location: Tony Abbott's electorate
Posts: 1,393
Quote:
Originally posted by RB
Interesting... what did BitrateViewer report for DCT and frame type? "Frame" or "Field"?
interlaced/zizag:

Pic. structure: Frame
DCT type: Field
Quantscale: Nonlinear
Scan type: ZigZag
Frame type: Interlaced

interlaced/alternate:

Pic. structure: Frame
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced


Quote:
Originally posted by RB
@Matthew:
What did you use to play the AVS and take the screenshots? Maybe to eliminate the influence of any external video codecs, it would be best to use AVISynth's ImageWriter() function to take the "screenshots".
Here's my script for true:

LoadPlugin("H:\brit07\MPEG2Dec3dg.dll")
MPEG2source("E:\test\test.d2v")
ConvertToRGB(interlaced=true)

I used VirtulDubMod and its "copy source frame to clipboard" feature.

The theory seems to be against what I've noticed. Anyway, I don't understand all this technical stuff, all I can say is that perhaps the video is marked as interlaced but not encoded in an interlaced fashion (if that's possible).
Matthew is offline   Reply With Quote
Old 3rd March 2004, 08:34   #32  |  Link
U977
Registered User
 
Join Date: Oct 2002
Posts: 96
Gents,

I'm popping up in this discussion from nowhere, but your posts answere questions I had since a long time but never really took time to ask...

I have two computers, and the older one still uses VF-API instead of AVISYNTH for importing the video in CCE prior to encoding.

Now, you guessed mpy question already... What happens when we use VFAPI instead of AVISYNTH? What should I do, then? (except than switch in avisynth? :-) ). I know I would gain from using avisynth, but I'm too lazy to update or change anything on this older computer. Enough work with the new one already. Yet, I'm interested to know what happens with VFAPI.
U977 is offline   Reply With Quote
Old 3rd March 2004, 11:15   #33  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
@Matthew:
I looked at your screenshots and verified this in my own tests. The interlaced=true parameter seems to introduce a slight "gradient" effect. Interestingly enough, this gradient disappears in the CCE encoded video when encoding as progressive/zigzag and then using interlaced=false in the AVS for the CCE encoded video.

I think it comes down to this:

If original stream is DCT Type: Field and Frame Type: Interlaced, use interlaced=true.

Then to decide whether to reencode as interlaced or progressive, check the video for combing artifacts. If it really looks progressive, we can happily encode as such (Progressive Frames: on, Scan Order: ZigZag). This is because we are reencoding in YUY2 colorspace where chroma samples are stored the same way for both interlaced and progressive video. If CCE supported YV12 so we could leave out the ConvertToYUY2() in the AVS, we indeed should replicate the original stream settings in CCE because chroma is stored differently for interlaced video in YV12.

@U977:
VFAPI converts to RGB as you may know and I really don't know whether it does the conversion differently for interlaced/progressive. Upgrade to AVIsynth
RB is offline   Reply With Quote
Old 3rd March 2004, 12:21   #34  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
If a Video is progressive but encodet in interlaced mode, we have to treat the colors as interlaced. That's because the progressive Frame is splittet up into 2 Fields. All DVD-Players are treating such a Video as interlaced.
So the big Question is: What is MPEG2DEC doing in such a case?

Combing the Fields to a true progressive Picture with a continuos Color-Coding? I guess not.

SeparateFields().ConvertToRGB24().Weave()
ConvertToYV12()

Guees this Script-Snipplet is not a bad Idea to be sure to handle the colors correctly all the times.
Kika is offline   Reply With Quote
Old 4th March 2004, 12:02   #35  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Kika, I don't think MPEG2DEC3 (the AVISynth 2.5 version) does anything wrong with respect to the colors because it does no color conversion by itself, it decodes in YV12, you know.

Now I'm not sure whether you agree to my advice on progressive encoding or not. Again, I believe that once you converted interlaced YV12 to YUY2 correctly (interlaced=true) but the video really looks progressive, you can now also encode as such. Because unlike YV12, YUY2 doesn't store chroma differently for interlaced or progressive, no?

About your snippet, I'm not sure what this intended for .

SeparateFields().ConvertToRGB24().Weave()

will always upsample chroma incorrectly for YV12 input, this is why the interlaced=true/false parameter was introduced in AVISynth 2.5 after all.
RB is offline   Reply With Quote
Old 4th March 2004, 12:56   #36  |  Link
Kika
Registered User
 
Join Date: Jul 2002
Location: Germany
Posts: 819
@RB

That's why i wrote "i guess" - i don't know how MPEG2DEC3/AVIsynth exactly acts in this case.
If it is working like descriped by you, i agree: After a conversion to YUY2 all should be correct.

Quote:
About your snippet, I'm not sure what this intended for
It's just for beeing absolutly sure. But..., um..., OK, after thinking again about that..., let's forget it, OK?

YV12 in AVISynth still drives my crazy sometimes.
Kika is offline   Reply With Quote
Old 4th March 2004, 13:36   #37  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
OK
RB is offline   Reply With Quote
Old 8th March 2004, 07:08   #38  |  Link
Matthew
jdgljlfljg
 
Join Date: Jan 2002
Location: Tony Abbott's electorate
Posts: 1,393
Thanks for that RB, you've made me feel all warm and fuzzy =)

At least I've been doing the encoding half-right (the CCE side)
Matthew is offline   Reply With Quote
Old 9th March 2004, 23:11   #39  |  Link
biggy7
Registered User
 
Join Date: May 2003
Posts: 24
just doing a a NTSC film

bitrate veiwer reports:
Num. of picture read: 31
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*480
Aspect ratio: 16:9 Generic
Framerate: 29.97
Nom. bitrate: 7000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced

when i set the options in dvd2dvd-r, according to bitrate viewer, which is leaving the boxes unchecked (prog frames, linear quant etc), when the encoding has finished and when playing back, lines appear in the movie.

now what am i doing wrong?
biggy7 is offline   Reply With Quote
Old 7th April 2004, 07:36   #40  |  Link
U977
Registered User
 
Join Date: Oct 2002
Posts: 96
RB,

Continuing our discussion from the DVD Rebuilder topic, and K-19...

AS reminder, for ease, I copy the info here again:
-----------------------------------------
logfile for K-19:

T01=AC3 0x80 3_2 448 0
T02=AC3 0x81 3_2 448 0
T03=AC3 0x82 2_0 192 0
GOPWarn=0
MPVBytes=4623620882
MPVMegaBytes=4409
AudioTracks=3
D2VFrames=198628
FramePictures=198628
FrameRate=25000
Width=720
Height=576
Bitrate=4655
Progressive=191470
FrameDCT=191482
TFF=198628
ZigZag=191470
PercentFilm=0


As a test, I encoded this one as progressive, with ConvertToYUY2() (thus interlaced=false).

I examined the resulting stream closely, did not find any artifact nor colour problems.
-----------------------------------------

Regarding your question about the structure, all the main movie is in a single PGC, but it was multiangle (only for some cell-ids, not for all the content). The different angles correspond to text in the video stream, in different languages. So, depending on what audio stream you select in the menu, you also get that text in the video in the proper language.
So you were still right: those text parts are the interlaced parts (confirmed during preview using the DVD2AVI version you asked me to use yesterday)

As I was too lazy to fully handle with this (I don't feel a need to support such features in my back-ups), I just extracted the angle I wanted (using DVD Shrink, without any compression) and the result was what looks like the typicall movie, with a single angle. That's what I worked on further with CCE, then.
And honestly, even if that text part of the video was encoded as progressive, I could not notice any bad effect (should it be interlaced artifacts, or colour problems).


You have shown that picture to me, with effects of bad colour conversion when using ConvertToYUY2:
http://forum.gleitz.info/attachment....chmentid=66315

It was very very interesting!

As I told you, I encoded several PAL movies as Interlaced (but ConvertToYUY2(), hence interlaced=false !), thinking that since they were flagged as Interlaced, I should have done this way.
I guess that they were progressive though, like the usual cases, but looking at the results with VirtualDubMod, and zooming, I can't find any of such effect. I can't find interlaced artifacts either.
I wonder if it means that there is a problem in the video, but the effect is harder to notice than the picture you've shown to me.

The only artifacts I could spot were found in Spirited Away. But in this case, I first encoded as progressive by mistake (forgot to flag as interlaced...) and the result was clearly showing interlaced artifacts on a standalone player. So I re-encoded the whole as Interlaced, and got new artifacts, just to realize I also forgot to use the proper TFF setting... (blushing) At least, Alternate scan was right! HEnce, I was facing real interlaced content, and I encoded it so too.
I ended with something that plays really nicely on a standalone and on a computer, without any noticeable bad effect. But when watching it in VirtualDubMod, and zooming, I can distingish some "interlaced-like" artifacts. But on an "Anime", they looks different than expected, if I compare with with filmed video Well, at least to my own eyes. Now I wonder if they are really Interlaced artifacts, or colour problems due to bad setting in ConvertToYuY2. Those artifacts do not look like what I could see on the example you gave me. I could take a screenshot tonight.

To be honest, I can't tell if I was lucky, or if there is something bad in my encodes that can be automatically fixed on-the-fly by standalone players and software players on computers.

If you have an opinion on this, I'm very interested to hear it too. I'd like to understand what I did, and what happens.

RB, a last question: what's the best tool/way to examine video, if I want to check if there were any colour conversion problem like the one shown on that picture you mentionned to me?

Last edited by U977; 7th April 2004 at 15:32.
U977 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.