Tuesday, October 6, 2009

Video basics

Video basics

When trying to understand how video is being stored and displayed we have to go back in time and look at a very outdated technology: The cathode ray tube television. Without giving a physics course a TV tube is a big piece of glass and no air inside. Inside we have a cathode emitting electrons when you heat it up (that's why it takes a while for the picture to show when you turn on your TV, the cathode first has to be heated up to the appropriate temperature to emit electrons). There also is a strong electromagnetic field which accelerates the electrons towards the front of the tube and the same electromagnetic field is also used to position the electron beam (there's a lot of electrons being fired towards the front of the tube). The front of the tube is phosphor-coated and when electrons hit it light will be emitted on the other side (that's the side where you're sitting on). Below you can see a schematic of a CRT.

At first TVs were only black and white so one electron beam was enough. Now, in order to display a picture you have to write it all over the screen so the electron beam has to sweep over the whole screen. The sweeping frequency is commonly known as refresh rate. The refresh rate was chosen according to the cycles of the electric systems being used: North America and part of Japan use 60 Hz, Europe, the middle East and parts of Asia use 50 Hz. This resulted in 2 competing TV systems:

NTSC: National Television Standard Committee. Also nicknamed Never the same color because no two NTSC pictures look the same. The NTSC system has 525 horizontal lines of which roughly 487 can be seen on screen and has a refresh ratio of 60 Hz interlaced (I'll get to that later on).

PAL: Phase Alternating Line. The PAL system has 625 horizontal lines of which roughly 540 can be seen on screen and a refresh ratio of 50 Hz interlaced.

Now, at the time when TVs first came to the market the technology to write 525 or 625 lines 60 respectively 50 times per second was prohibitively expensive and not suited for the mass market. Reducing the refresh ratio would have required more complicated circuits and wasn't an option either - plus the human mind has a lower limit as to what it accepts as fluent motion. But the TV engineers had an idea: What if we only wrote every second line of the picture during a sweep, and wrote the other half during the next sweep? Doing that we only need 25 respectively 30 pictures per second (meaning less bandwidth used meaning more TV stations in the same frequency band), and the human eye will still accept it as fluent motion. This idea of splitting up the image into two parts became known as interlacing and the splitted up pictures as fields. Graphically seen a field is basically a picture with every 2nd line black (or white, whatever you like better). But here's an image so that you can better imagine what's going on:

During the first sweep the upper field is written on screen. As you can see the first, 3rd, 5th, etc. line is written and after writing each line the electron beam moves to the left again before writing the next line.

As you can see on the left currently the picture exhibits a "combing" effect, it looks like you're watching it through a comb. When people refer to interlacing artifacts or say that their picture is interlaced this is what they commonly refer to.

Once all the odd lines have been written the electron beam travels back to the upper left of the screen and starts writing the even lines. As it takes a while before the phosphor stops emitting light and as the human brain is too slow instead of seeing two fields what we see is a combination of both fields - in other words the original picture.

When TVs finally got colored the interlacing technology stayed the same, but a more sophisticated cathode ray tube was required. Instead of emitting just one electron beam 3 electron beams in the colors red, green and blue are being emitted. When you place dots of different colors close enough together the human eye will no longer see individual dots but one single dot and will add the colors to create a new color. Below you can see the schema of a color CRT.

TVs use an additive color system to display all kinds of colors. For more information on additive color mixing please refer to the RGB World Color Info article.

In the NTSC world the switch to color required another change: The refresh rate had to be slightly lowered from 60 Hz to 59.97 Hz (resulting in 29.97 pictures per second) to accommodate the colors - that's why we have this strange framerates in the NTSC world today.

Now before we proceed to look how they shoot Hollywood movies let's have a look at PC monitors. The traditional PC CRT displays are fundamentally different from TV screens. When PC first came to the market it was finally possible to write a whole picture per sweep - also known as progressive scanning (scanning because the electron beam "scans" each line from left to right). Early PC monitors still supported interlaced modes but the higher contrast and bright backgrounds gave us such a headache that these days we are fortunate enough that most screens don't even support interlaced mode of operation anymore. Today all PC screens write a picture like this:

Recently there have been TV screens which support a progressive scanning mode. These models are very rare though and require that they are fed a different signal as the traditional ways of connect your VCRs, DVD players or cameras to the TV does not support progressive images. LCD and plasma displays can only write progressive images - when you feed them an interlaced image it requires some technical tricks to display a reasonable picture. These techniques are commonly referred to as deinterlacing.

A last word about TVs before we proceed: As you might recall older TVs had tubes that were far from being flat. As it gets more and more complicated to write a geometrically accurate and precise image the farther away you are from the center of the tube (the point where the electron beam would go straight to the phosphor layer without any deviation) even today you won't see the full tube, the last few inches are hidden behind the TV casing. That's the reason why both TV formats have more lines than you can see, the rest of the lines is and will always stay hidden. But these lines are still used: TV channels transmit text pages in these lines, they can contain signals that screws the automatic gain controller of your VCR (the Macrovision analogue copy protection system), etc.

Before we can go into deinterlacing there's a few things you should know about how movies are being shot.

Most movies destined for a movie theater audience are shot on a material similar to what we use for traditional photography. In a second 24 pictures are made from a scene. So, theoretically you can shoot a movie with your photo camera, except that you have to switch films every 1 or 1.5 seconds (and photo cameras usually don't support making 24 photos per second;). When we watch these movies in the movie theater we get to see 24 pictures (also known as frames) per second. But when we buy these movies on VHS tapes or DVDs to watch them on our crappy TV screens we have a problem. PAL screens require 25 pictures per second and each picture has to be split into 2 fields. But as 25 isn't so much higher than 24 what we commonly do in PAL countries is that we take the original 24 fps (frames per second) movie and speed it up to 25 fps. This means that voices and music has a higher pitch and that the movie is somewhat shorter but unless you do an one to one comparison hardly anybody notices.

Now enter NTSC. Here we need 29.97fps. Speeding up the movie is no option as the speed difference would be too large for people not to notice. So what's being done is that after splitting up frames into fields certain fields are being repeated to obtain the higher framerate. Basically 4 frames are turned into 10 fields as shown below:

So, as you can see from the image contrary to what you might think a higher framerate doesn't mean more fluent motion - quite to the contrary NTSC is a bit more jerky as some fields are being displayed twice (the first field of frame 2, and the 2nd field of of frame 4).

On the TV this isn't so much of a problem as crappy quality prevents us from noticing that something isn't quite right. But things change when we switch into the progressive world.

In order to display things progressively your display or playback device somehow has to turn the interlaced picture back into a progressive one. The easiest way to do that is to combine fields.

From the 10 fields you put the first two fields together to reconstruct frame 1, then the 3rd and 4th field to reconstruct frame 2. But then if you put the 5th and 6th field together you get neither frame 2 nor frame 3. This isn't so bad if there was no change from frame 2 to 3, but if the camera moves you'll be able to see some combing lines in the picture. And it can get even worse. Imagine there's a cut in between the two frames and frame 3 shows a completely different scene than frame 2. If you combine a field of one scene with a field of another scene what you have is a disaster. So, by simply combining fields back to frames not only would we get 2 out of 5 frames that are screwed with high probability, we also have a 29.97fps picture instead of the original framerate of the movie. Now, if we know how this process works we can undo it by simply discarding the duplicate fields. This process is called IVTC - InVerse TeleCine (thus the process of inserting duplicate fields is called Telecine). There are two good articles which explain telecine and IVTC in more detail: Video and Audio synching problems by Robshot which explains the creation of telecined content in more detail, and Force Film, IVTC, and Deinterlacing - what is DVD2AVI trying to tell you and what can you do about it by hakko504, manono and jiggimi. There's also my own guide on Decomb, the probably most popular IVTC utility.

Now that we have IVTC out of the way let's have a more detailed look at deinterlacing. First let me present the problem once again:

First we have two fields from an interlaced video scene:

As you can see - no interlacing artifacts visible. Now the corresponding frame:

Despite the low quality JPEG you can see that there are same interlacing lines visible, especially on the guy's clothes and arms.



And here's the even worse example where we have one field from one scene and the 2nd field from another scene:

And the corresponding frame:

As you can see that's not something we want to experience. What's also interesting is the size of these images. The one on the left is more than 3 times as large as the rest, and it still looks worse.

This also explains why storing interlaced pictures in progressive mode isn't a good idea. Lines take up a lot of space.

VCD and common MPEG-4 codecs (except XviD) support only progressive content. Thus storing something interlaced as shown on the left using such a compression technique isn't very efficient and we rather look for ways of turning interlaced material into progressive in a more efficient way than just combining the next 2 fields to a frame.

MPEG-2 and MPEG-4 advanced simple profile do have a special interlaced mode. In that mode all the lines from one field are taken together (leaving out the blanks) and compressed that way which saves a lot of bits that would otherwise be wasted to store the missing lines.

A last note on these screenshots: As this was taken from an interlaced DVD source and stored in interlaced mode the screenshots of the fields had to be stretched to their original size (remember that in interlaced mode we only encode the actual lines, and dump the blank ones) - in reality the fields would be half the vertical size of the frames.



Now that we have visually established our problem let's have a look at the possible solutions. As illustrated taking the first two fields and combine them to a frame isn't always possible. This is especially true when you're dealing with content that has been edited when it was already in interlaced mode (that's also problem number one when trying to IVTC, especially Anime content is cut after telecining the film parts which results in almost insolvable IVTC problems).

One simple and quick way to get rid of the interlacing problem would be to take the field based content, resize the fields to full frame size (remember that a field has half the vertical resolution of a frame) and then dump every second field. This method is for instance used when you select Separate Fields in GordianKnot. But as a field has only half the vertical resolution of a frame we give up half of the vertical resolution in the process.

Now let's have a look at different deinterlacing techniques:

Weave: Takes 2 consecutive fields and puts them into a frame. This reduces the framerate by two but doesn't solve the problems shown above, the frame which has fields of two scenes overlayed remains the same.

Then we have blending: Here we take two consecutive frames, resize them to frame size, then put them on each other. If we have no motion this looks perfect but as soon as there's movement it starts to look unnatural and unsharp and it can leave a "ghostly trail".

Bob: In bob you enlarge each field to frame size and display it twice. As the first and second field do not start at the exact same position (remember that when we start at line 1 for field 1 and line 2 for field 2) the picture slightly bobs up and down which can be seen as a slight shimmering in stationary scenes.

There are a few more methods, like area based deinterlacing, motion blur and adaptive deinterlacing. Each has its pros and cons. 100fps.com has a nice comparison on all methods including good samples that show you the effects each filter has and has a nice feature comparison matrix. The site also guides you to create true 50fps progressive material from interlaced sources. If the site is too much to read for you (I doubt any Doom9 reader could ever say that but be that as it may) Gunnar Thalin's area based deinterlacer and DeinterlacePALInterpolation which is based on Thalin's filter are pretty good solutions when you need 25fps output. Then there's also Decomb's field deinterlace which proves to be quite effective.

Though before you deinterlace try swapping the field order first. DVD2AVI has a function for it (Video - Field Operations - Swap Field order) and so does AviSynth (SwapFields). Quite often that can solve your interlacing issues, especially when the main movie appears to be interlaced.

Parting words: This is by no means a complete technical description and it was written trying to recall all the classes in physics and video compression I have taken in high school and college. I hope my memory hasn't failed me too miserably.


what is Telecine

1. Do NOT use Panasonic to individually encode .wav to .mp2. The resulting .mp2 will not sync with intended video. Using DVMPEG to encode .wav to .mp2 (albeit quality is not as good as Panasonic), will create .mp2 audio that sync with video. But, if you put .avi and .wav to panasonic together, resulting .mpg will sync. Strange, eh?

Video and Audio Syncing Problem: Why and How.

Since the first release of Powerip in mid-1999, people have been experiencing the problem of determining the correct speed of video and audio when converting an NTSC mpeg-2 video/audio stream to any other format possible (e.g. mpeg-1, avi, asf, or divx) to get a perfect video and audio syncing.

This video and audio syncing problem is the result of an incorrect conversion of the mpeg-2 video stream (either using Powerip, mpeg2avi or any other conversion utility out there). This document is not meant to discard Squeezer or Flask, but it is in fact can be considered as a support so PERHAPS, the explanation can be applied to perfect-ize both Squeezer or Flask -- or even the AGrabber plugin. To be of note, there have been a lot of successful "synced" conversion made using utilities such as "SQUEEZER" and "FLASK". But there are some cases, where none of the conversion utilities produce a total "synced" video and audio.

Why? Let's see the process of transferring a 35mm film format to an NTSC video format, to see the root of this evil.

35mm Film to NTSC Video Conversion

Movie is usually made on a 35mm Film Negative. This format has a 24 FRAME per second speed. A Frame is the smallest unit of a FILM format. NTSC Video is a "field-based" format of 59.94 FIELD per second. A Field is the smallest unit in Video format. 2 Fields made up into 1 FRAME. So, this 59.94 FIELD per second equals 29.97 FRAME per second. Now we can see the difference. 1 second in FILM (24 frame) is NOT equal to 1 second in NTSC Video (29.97 frame).

To be able to "match" the speed of an NTSC Video, conversion from a FILM format to an NTSC Video format undergone a process called "2:3 pulldown" or TELECINE. This process, in its simplest term, means "to add 6 frames so that a 24 fps becomes 30fps -- which is VERY close to 29.97fps". The problem that rises when doing this TELECINE transfer, is to decide WHICH 6 FRAMES to be added - or REPEATED?

Some kind of community of film/moviemaker/videomaker/engineers created a STANDARDIZATION of this TELECINE conversion. Since a Video FRAME consist of 2 Fields, why not make the FILM format into Field first, so that the smallest unit of both formats is the same? Let's see the process:

1. 24 FRAMES becomes 48 FIELDS

ABCD
AtopAbottomBtopBbottomCtopCbottomDtopDbottom

Frame A becomes 2 fields: Atopfield +Abottomfield. Thus, 4 Frames becomes 8 Fields, and 24 Frames becomes 48 Fields. This "field-based" material is then TELECINED into an NTSC Video signal. As TELECINE is a STANDARDIZED conversion, we have to follow the rules of engagement ;). The rule is to do a REPEAT_FIRST_FIELD in a 2:3 sequence.

2. 4 FRAMES (8 FIELDS) becomes 5 FRAMES (10 FIELDS)

ABCD
AtopAbottomAtopBbottomBtopCbottomCtopCbottomDtopDbottom

If we look closely, we can see a sequence of At Al At followed by Bl Bt then Cl Ct Cl then Dt Dl. But, since 1 FRAME consists of 2 FIELDS, then the sequence becomes AA ABBC CC DD. What we have now is a conversion from 4 SOLID frame into 5 FRAMES consisting of 3 SOLID FRAMES and 2 INTERLACED FRAMES. By INTERLACED I am referring to a FRAME that's made-up from 2 FIELDs of DIFFERENT FRAME source. The AB frame is the example.

So, 4 FRAMES becomes 5 FRAMES, thus 24 becomes..... 30, DONE! Done? Nope, not by a longshot. The NTSC Video is 29.97fps, so PLAYBACK of 30fps must be slow-down into 29.97fps, which brings us to the term DROP_FRAME.

Don't get a wrong concept of DROP_FRAME as "FRAMES being REMOVED or DROPPED". In a 30fps Video sequence, a DROP_FRAME time code counts video frames accurately in relationship to real time. DROP_FRAME time code counts each video frame, but, when that .03 finally adds up to a video frame, it skips (or drops) a number. It does not drop a film or video frame, it merely skips a number and continues counting. This allows it to keep accurate time. So if you're cutting a scene using drop frame time code, and the duration reads as, say, 30 minutes and 0 frames, then you can be assured the duration is really 30 minutes. Confusing? Well, to put it in simple term, DROP_FRAME here is in essence EQUAL a SLOWED_DOWN playback from a pure 30fps into the correct NTSC 29.97fps SPEED. In an MPEG-2 domain, this means that the 00 and 01 frames are dropped or SKIPPED from time code, at the start of each minute except minutes which are even multiples of 10.

NOW, it is DONE.

Telecine in MPEG-2 Video

In an Mpeg-2 Video, storing a 30fps frames in 1 second will create a much bigger files than storing a 24 frames. If you do your calculation, a 1 second of 24 frames is 20% SMALLER in SIZE than 1 second of 30fps. But, as we have already discussed, NTSC video should be 29.97fps. It would mean that ALL movies that's created from 35mm FILM should be TELECINED, then ENCODED to 29.97fps Mpeg-2 Video stream, right? ..... NO!

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!.

The FLAGS related to this are: REPEAT_FIRST_FIELD, TOP_FIELD_FIRST. The rules of applying these FLAGS follows the STANDARDIZATION. So you don't have to worry about the process not meeting the standard :). Let see some example:

3. Adding T_F_F and R_F_F Flags

Top Field First 1Top Field First 0Top Field First 0Top Field First 1
Repeat First Field 1Repeat First Field 0Repeat First Field 1Repeat First Field 0
ABCD
AtopAbottomAtopBbottomBtopCbottomCtopCbottomDtopDbottom

As the we can see, a Value of 1 for both T_F_F and R_F_F will ORDER the player to DISPLAY FRAME A in a sequence of Atop Abottom Atop, and the Value of 0 both T_F_F and R_F_F will ORDER the player to display FRAME B in a sequence of Bbottom Btop.

When T_F_F is 0 and R_F_F is 1 (FRAME C), the player will display FRAME C in a sequence of Bbottom Btop Bbottom and so forth. Since it is a STANDARDIZED conversion, we can see a repeating Value of T_F_F and R_F_F as the following:

T_F_F sequence: 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1

R_F_F sequence: 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

So, now we have an Mpeg-2 Video stream CONTAINING 24 FRAMES per second and TFF and RFF flags in action. This will create a CONFLICT between 24 fps versus 30fps and the VERBATIM 29.97fps NTSC Video standard. To solve this, there are 2 other advantages of Mpeg-2 Video stream than can be applied, the FPS flag and the DROP_FRAME flag.

When the FPS flag value is PROGRAMMED in the header of an Mpeg-2 Video stream, it will ORDER the player to PLAY this Video stream at an exact SPEED. So, if the FPS flag is set as 29.97fps, the Video stream will play at exactly 29.97 frames per second.

When the DROP_FRAME flag value is 1, it will ORDER the player to REMEMBER that the 00 and 01 frames are dropped at the start of each minute except minutes which are even multiples of 10. The result is much the same as applying the 29.97fps value.

So, THAT is how we make an Mpeg-2 NTSC video stream as 24 FRAME stored, but 29.97fps playback speed. Now that we understand the the process, we are ready to REVERSE it, in order to achieve total Video and Audio syncing when converting BACK from a 24-stored-29.97-fps Mpeg-2 Video stream into any video format we want.

How? Let start with "mpeg2avi", an utility that converts an Mpeg-2 Video stream into .avi format (with codecs of your choosing).

4. Mpeg2avi, VideoMatrix or Graphedit

After a careful reading to the readme.txt that comes with this utility, we can convert the Mpeg-2 Video stream into EXACTLY 24fps .avi. I am ASSUMING that mpeg2avi converts the FRAMES in DISPLAY_ORDER and not in CODED_ORDER. If the conversion is based on CODED_ORDER, then we are totally screwed.

Another way is to use VideoMatrix utility, that will convert an Mpeg-2 Video stream into .avi format BASED on the PLAYBACK of the Mpeg-2 Video stream. This utility ENSURES that the conversion is done in DISPLAY_ORDER.

Or, if you are quite familiar with Graphedit, you can use this utility to convert Mpeg-2 Video into .avi too. All of these three utilities MUST give you a full 720x480 .avi of 24 FRAMES per second. This 720x480 24fps is a REQUIREMENT.

5. M2VInfo

This utility is written to help analysing the FLAGS behaviour and values in an Mpeg-2 Video stream. It is a DOS command utility with usage as follow:

C:\M2VInfo filename.m2v > dump.txt

You can stop the process, because actually only the first GOP information is needed to determine the pattern of the FLAGS values and behaviour.

A sample of the dump.txt is as follow:Type 1 tff 1 rff 1 temp_reference 2
Type 3 tff 0 rff 1 temp_reference 0
Type 3 tff 1 rff 0 temp_reference 1
Type 2 tff 1 rff 0 temp_reference 5
Type 3 tff 0 rff 0 temp_reference 3
Type 3 tff 0 rff 1 temp_reference 4
Type 2 tff 0 rff 1 temp_reference 8
Type 3 tff 1 rff 1 temp_reference 6
Type 3 tff 0 rff 0 temp_reference 7
Type 2 tff 0 rff 0 temp_reference 11
Type 3 tff 1 rff 0 temp_reference 9
Type 3 tff 1 rff 1 temp_reference 10

Notes:

  • Type-1 = I Frame
  • Type-2 = P Frame
  • Type-3 = B Frame
  • temp_ref = DISPLAY ORDER
  • rff = Repeat_First_Field flag
  • tff = Top_Field_First flag

Now, what we need to do is to reconstruct the DISPLAY ORDER. I do this from the dump.txt above by rearranging the Frames according to the temp_ref. order
B B I B B P B B P B B P

Then, let's put the T_F_F and R_F_F in order too

0 1 1 0 0 1 1 0 0 1 1 0
1 0 1 0 1 0 1 0 1 0 1 0

Now we have the following sequence in DISPLAY_ORDER:

B B I B B P B B P B B P
0 1 1 0 0 1 1 0 0 1 1 0
1 0 1 0 1 0 1 0 1 0 1 0

Now, since we only want to know the CORRECT TELECINE sequence... just take the first 5 frames from the sequence above, and assume its an A B C D E sequence:


A B C D E

Apply the T_F_F and R_F_F values to the sequence above, and correctly follow the first T_F_F value, so we know which STARTING FIELD. I got this:

AlAu AlBu BlCu ClCu DlDu ElEu El

The STARTING_FIELD from above sequence is Al = Frame A lower field. Separate the sequence above into 1 frame (containing 2 fields), and we can calculate the TELECINE sequence within this .M2V as follow:


W S S W W W

So, the WSSWW sequence is the EXACT TELECINE sequence taking place in this particular .M2V

  • The rest of the flags are also included, like FPS, DROP_FRAME etc. These are the determining factors to calculate the correct TELECINE Sequence used in a particular Mpeg-2 Video. There are 5 valid TELECINE sequences: WSSWW, SSWWW, SWWWS, WWWSS, WWSSW.
  • W = Whole Frame
  • S = Separate Field

From the dump.txt, we can now determine the TELECINE sequence to reconstruct the 2:3 pulldown into the 24fps avi. By this we MIMIC the actual DISPLAY_ORDER of the Mpeg-2 Video PLAYBACK into the AVI domain. In short, we CONVERT the 24fps avi into 29.97fps NTSC avi. It is important to apply the specific TELECINE sequence AND the correct STARTING FIELD. When the reconstruction gives lower_field as the BEGINNING of the DISPLAY_ORDER, we have to conform the conversion AS IS. Both the SPECIFIC TELECINE sequence and STARTING FIELD is IMPORTANT to create a 100% video and audio sync.

At the time of writing this document, I can only use Adobe After Effects to correctly convert the 24fps into 29.97fps while at the same time apply both determining factors above. Yes, you can do this directly in any ENCODER, but the applied conversion DOES NOT conform to the STARDARD TELECINE transfer. Encoders will apply a "4th frame repeated" calculation to get from 24fps to 29.97fps (30fps drop frame). Such conversion will be like this:

Current Encoders TELECINE creates: AA BB CC DD DD EE FF GG HH HH

Correct TELECINE Tranfer would be: AA AB BC CC DD EE EF FG GG HH

As you can see, even the STARTING FIELD factor is nowhere to be applied (panasonic encoder has this option, though). If this error is added to the whole 1 hour of Video conversion, Audio syncing WILL be screwed. This stated, I prefer to use Adobe After Effects (albeit it's a difficult program), UNTIL a new method can be found.

6. Adobe After Effects

This is the stage where I really can't explain much. You have to KNOW how Adobe After Effects works. That's why I really want to find a way to simplify this stage, or to put simply, NOT USE THIS ADOBE AFTER EFFECTS. But, as a quick referrence, what I do in After Effects is like this:

  • Load the 24fps .avi
  • Make a new composition of 29.97fps
  • Import the 24fps .avi into the new composition.
  • Set the determining factor of STARTING FIELD (top or bottom - in Adobe its UPPER or LOWER), and the correct TELECINE sequence (one of the following sequences: WSSWW, SSWWW, SWWWS, WWWSS, WWSSW).
  • Render movie

All this steps are done in the 720x480 domain. The resulting rendered avi will be 29.97fps, accordingly conform to the SAME TELECINE transfer sequence that is programmed within the Mpeg-2 Video -- THE DISPLAY_ORDER. This avi will then become the source of the conversion to OTHER format, or if you choose DIVX codec from the start, you are now left with adding the Audio stream.

7. Converting the Audio

Use Graphedit to load any audio format. You have to edit the connection of the boxes in the Graphedit.

  • Delete the RENDERER box
  • Insert filters -- Audio Decompressor -- PCM
  • Insert filters -- Directshow filters -- WAVE DEST
  • Insert filters -- Directshow filters -- FILE WRITER (name it AUDIO.WAV)
  • Connect the existing boxes to --- PCM --- WAVE DEST --- FILE WRITER
  • Hit PLAY button

When it is finished, you now have 2 files: VIDEO.AVI and AUDIO.WAV. Now you decide what to do with it. You can:

8. Converting to Mpeg-1 with VideoCD compliant stream

  • Load Panasonic Mpeg-1 encoder
  • Input VIDEO.AVI and AUDIO.WAV
  • Set conversion to VCD NTSC standard/template
  • Set the MERGE/BLEND FIELD accordingly to the STARTING FIELD factor. If the original Mpeg-2 Video started with LOWER field, set the LOWER FIELD as the base of FIELD BLENDING in Panasonic. If the source Mpeg-2 Video is Anamorphic, add approriate BLACK BARS on TOP and BOTTOM of the VIDEO (66 and 67 is a good value).
  • Hit start encoding.

At the end of the conversion, you will have a 29.97fps Mpeg-1 VCD Compliant (352x240), and to be of note: the panning video sequence will pan smoothly!

The advantage of a 29.97fps Mpeg-1 Video/Audio stream is that I can edit it in IFilm Mpeg-1 editor, while a 23.976fps Mpeg-1 cannot.

By writing this document, I am describing the situation as closely as I could to help answer the questions of Video and Audio syncing problem, and hope that a coder can help SIMPLIFYING the process. I know that SQUEEZER or FLASK have been reported to be able to create a TOTAL SYNC. But since there are some reports that tells otherwise, PERHAPS this document could help pointing the reason, and thus we can come up with a solution or two for PERFECT A/V syncing for ANY conversion.

Some of the ideas to jot down are as follow:

  1. Re-write mpeg2avi (source available) to NOT ONLY convert the CODED FRAMES in an Mpeg-2 Video. Meaning, that it should also take into account the TFF and RFF and DISPLAY_ORDER Values, so the conversion from 24 FRAMES Mpeg-2 Video into 29.97 fps avi can be achieved in 1 STEP. This will ensures less quality degredation. With the current conversion method I presents in this Document, from an Mpeg-2 Video to Mpeg-1 Video needs to go through 24fps avi --- 29.97fps avi -- then Mpeg-1.
  2. If the above is not possible, a guy has informed me about Frameserver capability in latest VDUB (v. 1.3a). With this, perhaps someone can write a 2:3 pulldown re-construction filter for VDUB, which will do a correct TELECINE reconstruction in VDUB. Such filter should includes a STARTING FIELD and TELECINE SEQUENCE options to be used to reconstruct a 24fps .avi into 29.97fps .avi according to the calculation from M2VInfo. Add this filter with the RESIZE filter currently available in VDUB, we can then START FRAMESERVING the avi, and then RUN LSX Mpeg Encoder by opening the FRAMESERVED .avi. With this, we can make CBR Mpeg-1 VCD compliant or CBR (and VBR) Mpeg-2 SVCD compliant Video. Note: This frameserver capability of VDub resides only in Win2K and NT operating system. I failed on Win98
  3. Write a 2:3 pulldown re-construction directshow filter for Graphedit, so we can go 1 step from Mpeg-2 Video Audio to DIVX or AVI.

Anyone up for the task?

regards,

robshot

DVD Ripper comparison


DVD Ripper comparison
There's currently a lot of DVD decryption programs "on the market". One of the favorite questions of a newbie is "Which ripper should I use" and everybody has its own opinion about that. Everybody has its own explanation why his particular choice is best, but there was no comprehensive comparison between the various ripping programs till now.
I have contacted each of the authors of these programs if possible, to ensure that the info about their program is as accurate as possible. Furthermore I've suggested some improvements, many of which you can already see in the current releases of the respective programs.
Since my first test there have been many updates to the program involved so I decided it was about time to have another comparison. As you'll see, there's many issues which toady's rippers now can deal with.. but there's new problems to be solved as well.
The participants
cladDVD XP 1.1
DVD Decrypter 3.1.1.0
SmartRipper 2.41
vStrip 0.8e_css

Where's the rest of the pack? Both DeCSS and DOD Speed ripper can't be used for most of the reasonably new discs. In the case of DeCSS we also have legal considerations to consider. Then there's vobdec and decss_plus which still are available on my page, but only listed on the source code page because nobody uses them anymore. But, keysearch algorithms from these 2 programs can be found in almost any modern ripper. I wanted to include DVD Decoder 0.3 but the program will crash upon starting up every time I tried it.
Test Setup
I've chosen a particularly tough setup, designed to push the programs to their limits. I have tested the programs with the following 8 DVDs:
  • Death Row Uncut, R0, not encrypted
  • Raw Deal, R1, encrypted
  • The Blair Witch Project, R1, encrypted
  • Just Cause, R1, encrypted
  • The man with the golden gun, R1, encrypted
  • Scary Movie, R1, encrypted
  • Independence Day, R1, encrypted
  • Sneakers, R1, encrypted
  • Terminator 2 Ultimate Edition, R1, encrypted.
The regions have nothing to do with the results, but I've indicated it because certain R2 releases of the same movie don't have problems with ripping programs, or the other way round.
My choices are based on the following:
  • In order to correctly deal with unencrypted movies the ripping program should incorporate some sort of CSS detection in order not to search all VOBs for keys.
  • VobDec is unable to detect a key in vts_01_1.vob, vts_01_2.vob, vts_01_4.vob and vts_01_5.vob of Raw Deal
  • VobDec is unable to detect a key in vts_01_2.vob and vts_01_4.vob of Blair Witch Project. Furthermore DeCSS+ only finds 4 key occurrences in vts_01_2.vob and exactly 20 in vts_01_4.vob.
  • VobDec is unable to detect any key in Just Cause
  • The man with the golden gun has a mastering error: At the layer change the VOBs use a different CSS code. To make things worse the key changes not between VOBs but within a VOB file.
  • Most Disney titles have title and end credits in at least 2 languages interleaved with each other resulting in a few seconds English, then a few seconds of French/Spanish titles. Here I was looking to get the French end credits.
  • Independence Day is a seamless branching title and contains both the special edition and the theatrical version on the same disc. A good ripper allows you to select either of these versions.
  • Sneakers has one VOB file which is exactly 1.00GB large (Explorer shows it as 1.00GB, not 0.99GB like the others) and the Windows UDF parser can't read that kind of file.
  • Terminator 2 UE has 3 different versions of the movie on the disc. The goal is to be able to select the longest of the 3 cuts.
After each test I removed the DVD and inserted it again, in order to ensure that the drive was not authenticated. I also had no auto-run enabled for the DVD drive, in order to ensure that any auto-run DVD player would activate and authenticate the disc.
The results
Death Row uncut:
Here I basically expect that the program detects that there's no CSS and immediately starts ripping instead of searching for a key. All programs were able to do so.
Raw Deal:
Here I tried to rip only the VOBs where vobdec keysearch will fail in order to ensure that another keysearch has been implemented that's able to take care of the problem. All the programs tested were able to find a key in every VOB file.
However, cladDVD XP can only rip full PGCs or the whole set of main movie files.
The Blair Witch Project
Here I tried to rip VOB2 and VOB4. I expect a key to be found as soon as possible. SmartRipper and DVD Decrypter have been able to find a key immediately. cladDVD XP can only rip full PGCs or all the main movie VOBs so this couldn't be properly tested but since it uses vStrip I would assume that it works anyway. vStrip did crash in the GUI mode, but worked in the command line mode, though it took rather long to find the key in the 2nd VOB.
Just Cause
Basically the key should be found in every VOB file as fast as possible. All application could do that, but once again with cladDVD XP we have the problem that we can't rip single VOBs.
The man with a golden gun
All the tested rippers were able to handle this movie properly when using the correct options which differ from the default options. In the case of cladDVD XP this was activating the mastering error option and using intense keysearch, for DVD Decrypter it was checking mastering errors, for SmartRipper it was setting keysearch to occur on each VOB ID and forcing the file access mode to ASPI and for vStrip setting the keysearch to occur at every VOB ID change (-r1 on the commandline).
Some more info about that title: The main movie is contained in vts_03_1.vob - vts_03_5.vob. In title1, chapter 21, cell 2 the key changes from C1 87 79 74 EE to C1 87 79 74 ED. That position can also be seen as VOB ID15, Cell 1, LBA 521277. vts_03_4/5.vob use the new key. The key change occurs at the layer change and all PC based DVD players are unable to play discs with such mastering errors. At the moment only vStrip_css, DVD Decrypter and SmartRipper will properly decrypt that title and only if you enable keysearch by VOB / Cell id. I was even unable to play the disc on my standalone. Interestingly PowerDVD 3.0 can play the disc, even tough there will be a couple of seconds of scrambled picture but at the VOB change it'll descramble with the new key, the same applies to WinDVD 2.4 and later.
Scary Movie
All rippers were able to give me the French credits when selecting the 2nd angle.
Additional info: The title contains 4 VOBs: vts_01_1.vob - vts_01_4.vob. The movie consists of VOB IDs 1-20, where ID 17 are the English credits and ID 18 are the French credits.
ID4
All programs gave the right output in both cases. I even crosschecked with older tests and the file were identical to the last byte.
A bit of additional information on that title: The movie consists of 8 VOBs: vts_04_1.vob up to vts_04_8.vob. It contains 106 cells and 34 VOB IDs. The special edition contains VOB IDs: 1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23,24,26,27,29,30,32,33 and the regular edition VOB IDs: 1,3,4,6,7,9,10,12,13,15,16,18,19,21,22,23,25,26,28,29,31,32,33. I split up the output of each program into cell IDs and compared them cell by cell (for size and name).
Sneakers
The UDF parser in WindowsXP can handle 1.00GB files so the test results may not apply for everybody but XP is getting more and more popular... All rippers were able to read the first VOB file despite its size.
Additional information: The first VOB file on the disc (vts_01_1.vob) is slightly larger than a regular VOB (explorer shows it as 1.00GB instead of the regular 0.99GB). As the Windows UDF parser cannot read such large files every program that uses that parser will fail to read that file. All programs that have their own UDF parser will succeed (assuming that it has been properly implemented).
Terminator 2: Ultimate Edition
All programs managed to extract all the different cuts of this movie.
Additional information on this title: The movie has 60 VOB IDs. The theatrical release comprises VOB IDs 1, 2, 4, 5, 6, 7, 8, 10, 12, 13, 14, 16, 18, 19, 20, 22, 23, 24, 25, 27, 28, 31, 32, 33, 35, 36, 3, 39, 40, 41, 43, 44, 45, 46, 48, 49, 50, 52, 53, 54, 55, 57 and 59. The director's cut is contained in VOB IDs 1, 2, 3, 5, 6, 7, 9, 10, 11, 13, 14, 15, 18, 19, 20, 21, 23, 24, 25, 26, 28, 29, 30, 32, 33, 34, 36, 37, 38, 40, 41, 42, 44, 45, 46, 47, 49, 50, 51, 53, 54, 55, 57, 58, 59. Finally the third cut just has a different ending than the director's cut so it is contained in the same VOB IDs as the director's cut but it contains VOB ID 56 instead of 55 as the other two releases.
Or here's the short version of the test
cladDVD XPDVD DecrypterSmartRippervStrip
Death Row Uncutxxxx
Raw Deal(x)xxx
The Blair Witch Project(x)xxx
Just Cause(x)xxx
The man with a golden gunxxxx
Scary Moviexxxx
ID4xxxx
Sneakersxxxx
T2UExxxx

As we can see, the programs managed to handle my test discs admirably well. The only problem was that cladDVD XP didn't allow me to rip single files and screwed up the seamless branching titles.

Features overview
cladDVD XPDVD DecrypterSmartRippervStrip
detects CSSxxxx
VobDec keysearchxxxx
DeCSS+ keysearchxxxx
Demacroxxxx
Regionfreexxx-
adjustable keysearchxxxx
drive authenticationxxx-
selects main moviexxxx
copies ifo of main movie-xx-
multiangle processingxxxx
multiangle disablexxxx
one button movie ripxxx-
IFO parsingxxxx
standalone program-xxx
stream processing-xxx
UDF parser(x)xxx
ripping by chapter-xx(x)
calculate stream delays-xxx
And there are a few noteworthy special features:
DVD Decrypter can rip the whole movie to an ISO file that can be mounted in daemon tool or burned on a DVD using a DVD recorder. Furthermore it can burn such images to a recordable DVD disc. It can also be used to change the region of your DVD drive and display the region code of the drive.
SmartRipper furthermore creates a detailed info file about all your VOBs contain, audio streams, subtitle streams, chapter positions, etc. as well as a DVD2AVI project file (though that functionality is far from perfect).
cladDVD XP allows you to select if you want to keep all audio track, or select the one you want to keep.
So which program is best? Judging by the number of x'es you'd have to say SmartRipper and DVDDecrypter. SmartRipper has been tested for a long time and it works in most cases, but it has its problems and that's why it's currently being completely rewritten. DVDDecrypter has probably been the most stable ripper and pretty much the only thing you can hold against it is that its IFO parsing hasn't been as extensively tested as the one in SmartRipper and vStrip though so far no serious problems have been reported. vStrip doesn't look so good in the feature comparison but it manages to handle all the disc and it was in fact the first ripper to handle all my test disc. I've used it pretty much since I started out ripping and when in doubt about the results I get from other programs I will continue to cross-check with vStrip. But vStrip is definitely not as user-friendly and is more a program for the experienced user. cladDVD XP is a pretty good GUI for vStrip and can safely be used as vStrip replacement when DVDDecrypter/SmartRipper fails and vStrip itself scares you away. When you encode using FlaskMpeg or make a rip to be burned onto a recordable DVD there's just one choice: DVD Decrypter. Just run the exe and press the big button and wait, that's all there is to it.
Speed testing
Of course, speed is of essence. Hence I ran all rippers to a small speed test. I ripped the first VOB of the main movie of "The Matrix", R1 release (a DVD-9) to my harddisk. The drive used was a Toshiba SDM-1212 12x DVD-ROM in Ultra DMA mode.
cladDVD XP: 2:35
DVD Decrypter: 1:33
SmartRipper: 1:41
vStrip: 2:21

DVD Decrypter leaves them all behind. SmartRipper gets reasonable close and half a minute separate vStrip and SmartRipper. I must say, the last time I did that test it looked considerably different. For vStrip I tested both GUI and CLI version just to make sure I got the results right. cladDVD cannot rip single files so I just waited till I had a 0.99GB VOB on my HD which isn't entirely fair but what can you do...
Wishes for the future:
There's several things I'd like to see in future rippers:
DVD Decrypter: can't think of anything right now..
SmartRipper: a more stable codebase, many people are having problems with SmartRipper (see my forums for details)
vStrip: splitting the output in accordance with the input VOBs, authentication
cladDVD XP: allow people to select VOB files by themselves, smaller filesize.
This document was last updated on 06/21/00

Popular Posts