Log in

View Full Version : Oddities with LOTR extended version


Xayd
15th September 2003, 05:29
I picked this movie up and wanna fit it on one DVD-R and have run into some odd things while trying to transcode it with CCE 2.50

1) DVD2AVI and BitrateViewer both identify the original stream as film, progressive frames. Pretty standard for an NTSC movie. So, in my first attempt with this movie I set force film in DVD2AVI and encoded it with a single pass, max 8000 min 1400 q factor of 5. The result was an average bitrate around 2350 for the first disk. I ran pulldown on the result and fired it up in WMP to take a look at the results, and...

The odd thing is, the original had some motion artifacts during camera panning, and actually the artifacts from the original were gone after the movie was transcoded, which is obviously a good thing, the copy is better than the original, woohoo!

BUT (there's always a 'but' when someone posts here ;)), there are other artifacts present now, odd white specks that show up in those camera panning scenes that weren't there on the original. To be honest I've never seen such artifacts so I have no idea what they are.

2) I started retracing my steps and noticed that although the movie is identified as film, the framerate of the original isn't 23.97, it's 29.97. This I've also never encountered. Could this movie be interlaced possibly? Being in R1 I don't see interlaced material, so besides the descriptions I see around forums I've never actually seen what it might look like on a DVD. I tried another 1 pass encode with CCE, only this time I set DVD2AVI's field order to "none". The result this time were the opposite of the first encode I did. The white specks are gone, but there are more motion artifacts in those camera panning scenes than there were with the original. If anything the transcoded copy in this case has the same jerky artifacts in high motion scenes as the original does, just more pronounced.

3)I've also never played with CCE's anti-noise filter but this seemed to be as good a test of it as any, so I'm running a second and third pass on the original forced-film encode right now to see if it catches and eliminates the strange white specks that showed up in that round. It's got about an hour left to go right now so we'll see how it turns out.

In the meantime I've got two encodes, neither of which is acceptable.

Anyone have any ideas about what I'm dealing with here?

RB
15th September 2003, 09:07
Originally posted by Xayd
2) I started retracing my steps and noticed that although the movie is identified as film, the framerate of the original isn't 23.97, it's 29.97. This I've also never encountered.
I'm in PAL land, but AFAIK, NTSC DVDs are always 29.97 fps. You can encode at "forced film" (23.97) to have better quality, but when you run pulldown, it will insert "repeat field" flags to make the video 29.97 fps effectively. Someone please correct me if I'm wrong.

As for the effects you are seeing, I'm not sure what could cause this. Maybe make sure that "Upper field first" is not checked in CCE.

Xayd
15th September 2003, 11:25
I've been under the assumption that those repeat flags associated with 3:2 pulldown are just that, only flags and not actual frames. Every NTSC film movie I've seen so far has shown a framerate in Bitrate Viewer of 23.97, not 29.97 natively.

Someone correct me if I'm wrong there.

The resulting mpeg stream after the two passes with the anti-noise filter and a pulldown looks ok, maybe it was in fact just a really crappy encode to begin with.

manono
15th September 2003, 11:32
Hi-

NTSC DVDs are always 29.97 fps

Yes, they always output 29.97fps, but a well mastered DVD such as LOTR will actually store the video on the DVD as 24fps with those same flags set to output 29.97fps.

There's a pretty decent explanation of the process right here on Doom9's site in robshot's article (http://www.doom9.org/synch.htm). In it he says:
A good thing about Mpeg-2 Video is that it can contain some FLAGS or PROGRAMMING, that would tell a SOFTWARE or HARDWARE to perform a TELECINE when playing the Video. Since the INTERLACED FRAMES that made-up the 29.97fps is a REPEATED field(s), it is REDUNDANT, and TRASHABLE. Just let the FLAGS tells the player to perform the TELECINE. Really, it CAN do that ;). The benefit of this that the movie CAN be stored in its original 24 FRAME per second, and thus SAVE 20% of total filesize!And there's a really detailed explanation of the process, and how it's often not done properly, so that Force Film can't be used many times, here. (http://www.hometheaterhifi.com/volume_7_4/dvd-benchmark-part-5-progressive-10-2000.html)

DDogg
21st September 2003, 21:48
manono, I wonder if the new 3:2 pulldown detection in CCE 2.67 would do a better job than forced in dvd2avi? I noticed CCE 2.67 has an 3:2 pulldown automode that seems to analyze the pattern frame by frame. There is also several seemingly complex manual setting methods. Do you use CCE 2.67? If so, I would appreciate your opinion. I don't know much about hybrid stuff as I don't do complex anims and such. Generally FF works just fine for me. If not, telecide and decimate normally handle it, but doing it in the actual encoding process makes a lot of sense to me. Has anybody else out there worked with this CCE internal pulldown detection?

From CCE manual:
3:2 pulldown is a method of converting 24 frames (24 fps) of film
into 60 fields (30 fps) of NTSC video. By this conversion, 12
(= 60 -24 X 2) fields of copy fields per second will be created.

If 3:2 pulldown detection is selected, these copy fields are
detected and treated as repeated field of MPEG-2 See 4.

If 3:2 pulldown detection is selected, progressive frame flag
is automatically raised.

Do not use this option to originally video material, otherwise,
movement of decoded images will be jerky.

Footnote 4 - 4The 3:2 pulldowned material has only 48/60 = 4/5 of information compared to those that are not 3:2 pulldowned. By applying inverse 3:2 pulldown, 1/5 of redundant information can be reduced, thus effective encoding can be achieved.

manono
21st September 2003, 22:36
Hi DDogg-

I'm sorry, but I only have and use CCE 2.50, so I can't try it out.

However, I'm having a little problem understanding the quotes. Is it written by native English speakers? :) I may be wrong, but it seems to be implying that it can only detect material that has been encoded as progressive in the first place. If that's true, then you might as well use Force Film in DVD2AVI before sending it to the encoder. It does say not to use it with video material. That may imply that you shouldn't use it with film material encoded as Interlaced or true hybrid material. But I'm not really sure. Sorry, not much help.

DDogg
22nd September 2003, 00:29
Yeah, I was just looking for something to play with today and thought I would delve into the innards of CCE some more.

I fed it a straight non FF D2V and at first was pleasantly surprised to see (I thought) a properly flagged mpv file. Mplayer showed 29.97 as frame rate and 23.976 as actual so I thought wow, even if it only worked on straight progressive and not hybrid this would still save the pulldown.exe step and save a massive amount of HD space as a second copy of the mpv would not have to be created.

Unfortunately I could not get a synced mux although I tried several times with BBmpeg which is the standard I normally use. Sound was way off. Then I tried tmpg and the sound was synced but playback was weird and I just don't trust TMPG to mux anything except VCD.

Maybe I just don't understand exactly what it is supposed to do or maybe it is just broken (using 2.67.00.11). Either way, I am back to dvd2avi Forced Film, but it was interesting to try. Maybe somebody else can figure it out better.

manono
22nd September 2003, 11:26
Hi-

When I wrote, I realized that it might save you running Pulldown afterwards. But I was thinking SVCD and saving only a few minutes time, so I didn't think that was significant. But after you replied, I realized that you were thinking DVD and GB's of space. Yes, that could be really important. Maybe they'll iron out the kinks in a future release.