xvid to dvd at ntsc 23 fps

[bigly]

Thnx Claire. _______________ Why does DivXToDVD convert the usual 24fps progressive source (most DivX/XviDs) with frame duplication/dropping instead of flagging the stream (NTSC) or pitch-shifting the audio (PAL) for the player to 'naturally' rate-compensate An extract from DVD FAQ (Section 3.4): "Coded frame rates of 24 fps progressive from film, 25 fps interlaced from PAL video, and 29.97 fps interlaced from NTSC video are typical. MPEG-2 progressive_sequence is not allowed, but interlaced sequences can contain progressive pictures and progressive macroblocks. In the case of 24 fps source, the encoder embeds MPEG-2 repeat_first_field flags into the video stream to make the *decoder* either perform 2-3 pulldown for 60Hz NTSC displays (actually 59.94Hz) or 2-2 pulldown (with resulting 4% speedup) for 50Hz PAL/SECAM displays. When DivXToDVD converts frame-rates, according to the log window it does it by 'simple' frame duplicating/dropping. This causes significant 'jerkiness' in the output. This is a terrible shame as DivXToDVD must have a fantastic motion detect engine. If you convert using an identical source>output format (e.g. PAL>PAL), even fast motion scenes are really smooth which proves the motion searching is excellent BUT it is being completely ruined by the 'jerky' frame-rate compensation. Usually to encode a 24fps progressive source, an encoder sets the picture_structure (=frame) & progressive_frame (=true) flags and the repeat_first_field flag according to standard (PAL=false/NTSC=true) so that the player automatically compensates for the appropriate frame-rate/standard. In this case if you had chosen PAL output, the player(/decoder) would speed up the stream by 4% resulting in NO jerkiness. (A good encoder will have already pitched down the audio stream by 4% to compensate.) If you had chosen NTSC output, the player(/decoder) would use 3-2 pulldown . (This is still not perfectly smooth BUT much more smooth than simply repeating frames!) Any chance of asking the developer about using this method instead when the input file is progressive @~ 24FPS

[lapinou]

wahou.. I don't understand a single word of your post, but it sounds interesting and VERY technical. if you want to expose your point of view about all these topics, I will ask you to send your MSN ID and I will arrange a chat with the developer.

[bigly]

lapinou, sorry I didn't respond but I've been in Paris for a few days over my birthday. I appreciate you taking the time to offer that chat but... ...I am a developer myself and even though my corporate employer has nothing to do with these kinds of applications there could be a conflict in obligations there... AND... ...there isn't much more I can do other than point in the right direction which I already have done! A technically minded person (i.e. the developer I hope!!!) should 'get-it'. Why don't you just copy these posts to them? If the devloper/VSO really wants to sort this out they simply need to 'read-up' on DVD/MPEG2 theory in general which is all I did. Follow the previous DVD FAQ link to get started. A few focussed reading hours would bring them the "eureka" moment! If he/she wants a more 'hands-on' understanding just copy the following experiment for yourselves. _________________________________________________________ I have tested AND confirmed my theory with the following experiment: (All the software I used is available for FREE/on trial!) _________________________________________________________ 1. Find some commercially produced MPEG2 in NTSC format encoded from a progressive source. (E.G. An NTSC DVD of almost any movie!) 2. Create a progressive 'rip' of that source using your prefered DivX/XviD encoder. (E.G. Use "film" mode or similar to get the required 23.97FPS MPEG4.) 3. Now convert that DivX/XviD back to MPEG2 using; a/"DIKO", b/ "The FilmMachine", c/ "DivXToDVD". 4. Analyse the resultant MPEG2 stream in the output VOB files. (I used "VOB Edit" for this.) Attempt to find a matching/similar GOP in each output stream (the first few GOPs are usually the easiest to work with ) and for each frame in that GOP note down the flags for repeat_first_field, progressive_frame and top_field_first. Do this for each output stream (e.g. all the applications tested). It took me a looooong time to manually analyse the VOB structures (using VOB edit) but the results did confirm what I have said, "When dealing with a progressive source, 'all' the other encoders use 'pulldown' stream flagging to achieve NTSC frame-rates". An excellent comparison example is DIKO because it created exactly the same GOP structure as DivXToDVD in my test. (IBBPBBPBBPBBPBB I believe - don't have the data with me at the mo' to confirm tho'). After 1 GOP, DIKO shows a time-frame increased by 20 frames even though there are only 15 frames in the GOP!!! This is because it has an alternating pattern of repeat_first_field flags. This causes the 'physical' conversion to NTSC at the decode stage using the well documented and accepted method of 3-2 pulldown. (The pattern of top_field_first flags is also part of the 3-2 pulldown method but has more to do with 'fine-tuning' the output than the actual FPS compensation.) DivXToDVD however 'physically' creates extra frames (with 'simple' duplication) and encodes all of them (immediately losing 25% MPEG2 stream efficiency in this case!). After 1 GOP, DivXToDVD has only increased the time-frame by the 15 frames which are 'physically' present in the GOP. It is because of the 'simple' frame duplication method that the output is 'jerky/jumpy/jittery'/not smooth. I CAN'T GUIDE YOU ANY MORE CLEARLY ON THIS!!!!!! P.S. Don't copy the alternating progressive_frame pattern of DIKO. DivXToDVD already correctly sets this flag on all frames. DIKO has inherited(/copied!) a bug from 'another' encoder. (It should be set for all frames when the source is proressive.) P.P.S. DivXToDVD shouldn't set the progressive_sequence flag in the GOP which it does. Strict DVD standard does not support a progressive sequence - it only allows each frame to be coded progressively as detailed above.

[lapinou]

Hi, thanks, I don't understand a single word but I will take care the developer read it and answer to confirm if he can do something or why he is doing the way it is now... it will take a week I think.

[lapinou]

Hello I'm the author of DivxToDvd, I'm taking Lapinou account to answer (I don't have an account here...) Thanks Bigly for your very accurate report. "When DivXToDVD converts frame-rates, according to the log window it does it by 'simple' frame duplicating/dropping. This causes significant 'jerkiness' in the output. " Exact. I did this simple FR compensation for several reason: 3-2 pulldown is for film->ntsc - it is exact *only* if source is 23.96 FPS exactly. So far, I've seen many many frame rate in source divx, from 3 fps to 60 fps. On some film divx, for audio resync purpose the frame rate is slightly modified.... for all these issues and to be compatible with whatever input, then I had to provide a generic algorythm able to compensate any frame rate. So that's why I did a simple frame duplication/dropping stuff - based on the difference between source frame PTS/DTS and encoded frame PTS/DTS - adding or dropping frame everytime this difference is too big. I am aware it's definitively not giving smoot result and trust me I'm not happy with the current result. That was my best for a fast solution. I have to deal with so many sources - and the destination has only two possible frame rate (25 or 29.97) to match the DVD specs. However I plan to change this to have a better conversion using all the better techniques to have smooth playing (change video playback rate with audio resampling, Real pulldown based on interleaved frames, flag the output stream to trigger hardware pulldown...) This is only just a matter of time. Don't ask for release date, As you can understand I also have to deal with development priorities, and this is not one of these. Be sure it'll be done, that's all. Cheers - Jacques

[bigly]

That's is good to hear Jacques - thanks for taking the time to reply. I'll wait patiently now. Please update the version info when you start to include these enhancements.

[Neil305]

As a temporary measure, could the program try and make a guess as to which output standard (PAL/NTSC) is going to give the smoothest playback based on the input frame rate, and chose that if set to "automatic". At the moment from what I've seen, "automatic" just seems to always chose NTSC unless the input frame rate is exactly 25FPS. I'd guess most people have players and TVs that cope fine with either standard.

[JJ]

[bigly]

From a lot of testing with DivXToDVD it seems the 'smoothest' frame-rate compensation is from ~24FPS to 29.97FPS NTSC. ~24FPS to 25FPS PAL seems more 'jerky' IMHO.

[Neil305]

[JJ]

There should not be many rates - 25 is always PAL. 23.97 is film - always NTSC. 24 - non existant, 23.97 is real. 29.97 is NTSC TV. So - 25 FPS is PAL. If movie is PAL originally, it should be converted to PAL. Other rates are all NTSC and they should be converted to NTSC. If you have ANY other FPS rate, that is some special format and you never know what it is. So - how could DivXtoDVD better guess standard? There are two output standards, and ONLY ONE input that fits PAL output. Rest are NTSC.

[Neil305]

[JJ]

[Brando_T.]

A question: I found that DVD's burned from AVIs, where DIVXtoDVD converted frame rate to 29.97 fps, didn't play correctly in my Pioneer DV-535 player. The video would pause frequently, but would play again after I "unpaused" the player. This didn't happen on DVDs where the source AVI was 29.97 fps. So, I'd like to continue using DIVXtoDVD, but I guess I should convert fps first to 29.97, then run it through DIVXtoDVD. What would be the best utility (free!) to quickly perform this task? pulldown?

[CDR-Zone.COM]