HQ Conversion Software

[ROBERT BLACK]

@ROBERT BLACK
If you had A/V sync issues then either the video encoding was done improperly OR the delay value of the audio file needs to be adjusted.

Depending on how you ripped the movie and how the movie was first authored to begin with can affect the audio in such a way so that you need to sometimes adjust the delay value of the audio file to get sync. Most of the time it is not an issue but when it is an issue it is as simple as correcting the delay value (the value that indicates if the audio should start slightly before or after the video) and once that is set correctly (and finding the correct value can be a bit hit or miss) it should be in sync from start to end.

It's probably best to rip with DVD Decrypter in IFO mode and if the movie has copy protection issues that keep you from using DVD Decrypter as is then you can try RipIt4Me in "movie only" mode. RipIt4Me is a "front end" to DVD Decrypter that gives DVD Decrypter the ability to beat newer forms of copy protection.

However some people do the video part wrong because many encoders (and CCE is one of them) have a special DVD COMPLIANCE mode (not a template per se) that will force full NTSC or PAL compliance i.e., it will not allow the creation of a hybrid video file but when doing PAL to NTSC the DGPulldown method you need to create a hybrid video file (one with NTSC resolution but PAL frame rate).

Anyways those are the two most common mistakes people run into when doing this kind of conversion.

My suggestion is to load the encoded video file into VirtualDubMod or GSpot etc. and double check that the file is indeed a proper hybrid before doing the DGPulldown step.

- John "FulciLives" Coleman

Thanks for the responding.


It is indeed an audio delay problem,as sync loss was gradual. Definitely not noticable at first. This occured in two files. The DVD option in CCE was unchecked therefore their was no forced compliance to a DVD template. I used video inspector to confirm the file was resized to NTSC specs with 25fps prior to DGPulldown. Playing with the delay value is incredibly time consuming as this requires you to re-encode a sufficient amount of the file to see if it stays in sync. But seems the only option other than the one click method of ConvertX.

[FulciLives]

Well if the sync goes off gradually then you probably encoded it incorrectly (the video that is).

If the sync is off by "x" amount and seems to be a constant then it is just a delay value that can be adjusted with delaycut or AC3 Delay Corrector.

Also it could be everything was done correctly but you screwed up somewhere else i.e., putting the files together.

For instance MPEG2VCR has a built-in multiplexer and if I use that to combine a M2V done via DGPulldown with the original audio they will be out-of-sync. But if I leave the video and audio separate and author them proper (as separate elements) then the sync works. I have used TMPGEnc DVD Author (1.6 and 2.x) as well as DVD-Lab Pro (current version).

It could be some programs have trouble muxing the files together.

Have you checked to see if the video and audio files are the same length before muxing and/or authoring them?

- John "FulciLives" Coleman

[FulciLives]

@deadrats

I'm not about to go into your silly challenge because we already pretty much went over that in another thread. It's ridicules.

However I offer you a real challenge.

I have uploaded a MPEG file. This comes straight from a PAL DVD release of a big budget movie. The MPEG file is 720x576 progressive 25fps with 5.1 AC-3 audio.

Here is the link ---> http://rapidshare.com/files/5550678/testclip.mpg

I ask you to download the file. Convert it to NTSC as per your method(s) then upload it for all to see. It is completely free to post a file up to 100MB onto that RAPIDSHARE website. If you re-encode to NTSC at a CBR of about 7500kbps (or less) then you should end up with a file size that is under 100MB.

As for my part I went ahead and converted the file to NTSC using two difference methods. I have uploaded these for anyone to download.

METHOD ONE
Here is the link ---> http://rapidshare.com/files/5553434/pal2ntsc1.mpg
This file was created using the DGPulldown method. In short I did the following:

1.) Created a D2V file and demuxed the audio using DGMPGDec aka DGIndex

2.) Created the following AviSynth script:
LoadPlugin("DGDecode.dll")
LoadPlugin("RemoveGrainSSE3.dll")
MPEG2Source("C:\test\testclip.d2v")
RemoveGrain(mode=1)
LanczosResize(720,480)
Crop(8,60,-8,-60)
AddBorders(8,60,8,60)

3.) Encode with HCenc using an AVG of 7500 and a MAX of 8000 with a VBR BIAS of 99 (which kinda sorta mimics a CBR encode but HCenc does a 2 pass VBR anyways).

4.) Ran the output through DGPulldown using the 25fps ---> 29.970fps option.

5.) Authored the video and audio (as demuxed with no change) with TMPGEnc DVD Author 2.x to get a VOB file.

6.) Extracted the VOB file to a MPEG file using VideoReDo.

METHOD TWO
Here is the link ---> http://rapidshare.com/files/5556438/pal2ntsc2.mpg
This file was created by slowing the FPS down to 23.976fps which also required that the audio be adjusted as well since this method changes the length of the video file.

1.) Created a D2V file and demuxed the audio using DGMPGDec aka DGIndex

2.) Created the following AviSynth script:
LoadPlugin("DGDecode.dll")
LoadPlugin("RemoveGrainSSE3.dll")
MPEG2Source("C:\test\testclip.d2v")
RemoveGrain(mode=1)
LanczosResize(720,480)
Crop(8,60,-8,-60)
AddBorders(8,60,8,60)
AssumeFPS(23,976, true)

3.) I used a combination of Soft Encode, GoldWave and SoundForge to create a new corrected 5.1 AC-3 audio file. This required decoding the 5.1 AC-3 to 6 mono wav files. Adjusting them for length (for 25fps to 23.976fps conversion). Then putting them all back together for a new corrected 5.1 AC-3 audio file.

4.) Encode with HCenc using an AVG of 7500 and a MAX of 8000 with a VBR BIAS of 99 (which kinda sorta mimics a CBR encode but HCenc does a 2 pass VBR anyways).

5.) Ran the output through DGPulldown using the 23.976fps ---> 29.970fps option.

6.) Authored the video and audio with TMPGEnc DVD Author 2.x to get a VOB file.

7.) Extracted the VOB file to a MPEG file using VideoReDo.

---------------------

Now let us see what you are capable of Mr. deadrats!

- John "FulciLives" Coleman

P.S.
All three files are of course DVD compliant so anyone interested feel free to download and author to a DVD-RW or DVD+RW and check them out on your TV. Please note that you should not mix PAL and NTSC on the same DVD Video disc.

[ROBERT BLACK]

It could be some programs have trouble muxing the files together.

Have you checked to see if the video and audio files are the same length before muxing and/or authoring them?

- John "FulciLives" Coleman

No user encoding screwups, I usually pay close attention to that shit. I'm infallable that way. :P Yes,the problem was in muxing the files together. I saved the audio as mpeg. Re-encoded it seperately with SUPER to AC3,(same bitrate) and then muxed the file with the TMPGec Xpress 3.3 Mpeg tool then authored using DVD Author. Re-encoding the audio was left unchecked. The file is finally in sync. Somewhere along the line I suspect in DVD Authors default re-encoding of the audio to AC3 the files just didn't sync up. I'll try it with the second project file tonight. It should work.

Thanks for you're suggestions. This method does work,just be aware you're progs may not be up to the task of muxing the files properly. Joy.

[FulciLives]

It could be some programs have trouble muxing the files together.

Have you checked to see if the video and audio files are the same length before muxing and/or authoring them?

- John "FulciLives" Coleman

No user encoding screwups, I usually pay close attention to that shit. I'm infallable that way. :P Yes,the problem was in muxing the files together. I saved the audio as mpeg. Re-encoded it seperately with SUPER to AC3,(same bitrate) and then muxed the file with the TMPGec Xpress 3.3 Mpeg tool then authored using DVD Author. Re-encoding the audio was left unchecked. The file is finally in sync. Somewhere along the line I suspect in DVD Authors default re-encoding of the audio to AC3 the files just didn't sync up. I'll try it with the second project file tonight. It should work.

Thanks for you're suggestions. This method does work,just be aware you're progs may not be up to the task of muxing the files properly. Joy.

Well I am glad you got it working

I only discovered the muxing issue myself recently. I never had a problem before because I always authored the files (audio and video) as separate elements since all the authoring programs I have played with never insisted on muxed files for input.

I don't really think it's a big deal other than to say do not mux before authoring. As I've said I never had a problem with any of the TMPGEnc DVD Author versions (1.5 - 2.x) nor DVD-Lab Pro. I know others have successfully used other DVD authoring programs without issues such as DVDAuthorgui and MuxMan etc.

- John "FulciLives" Coleman

P.S.
I think I also used the DGPulldown method successfully with DVD Maestro once as well although it has been a while since I've used DVD Maestro as I find it a bit difficult to use myself. DVD-Lab Pro has a similar interface but is easer-to-use in my opinion.

[deadrats]

Now let us see what you are capable of Mr. deadrats!

i accept your challenge. it is now friday 4:11 pm where i am and i am about to leave for a birthday party and tomorrow morning i have a few jobs i have to do. rest assured however that by late saterday afternoon i will have uploaded the converted files for everyones inspection and i may just do a couple of additional conversions to mpeg-1 and mpeg-4 just for laughs.

check back tomorrow for the continuation...

[FulciLives]

Now let us see what you are capable of Mr. deadrats!

i accept your challenge. it is now friday 4:11 pm where i am and i am about to leave for a birthday party and tomorrow morning i have a few jobs i have to do. rest assured however that by late saterday afternoon i will have uploaded the converted files for everyones inspection and i may just do a couple of additional conversions to mpeg-1 and mpeg-4 just for laughs.

check back tomorrow for the continuation...

Well to me the whole point of this is PAL DVD to NTSC DVD so I see no need for MPEG-1 but if you want to do MPEG-4 then go ahead. Maybe I will as well.

- John "FulciLives" Coleman

[FulciLives]

Well I went ahead and I made two different XviD MPEG-4 files. Again using the same source that I posted in my earlier post above.

XviD MPEG-4 Clip #1
Link ---> http://rapidshare.com/files/5670764/XVID640.avi
This file was created in the "traditional" method meaning that all black was cropped and the image was resized to a square pixel resolution of 640x272 (the aspect ratio is 2.35:1). I also adjusted the FPS from 25fps to 23.976fps which also required I adjust the audio as well. Audio is 5.1 AC-3 format as per the original.

XviD MPEG-4 Clip #2
Link ---> http://rapidshare.com/files/5673247/XVID720.avi
This file was created by resizing from 720x576 to 720x480 ... I then cropped the black but put it back to keep the same ratio and image size (720x480). It is common to replace already encoded black in such a manner. I also adjusted the FPS from 25fps to 23.976fps which also required I adjust the audio as well. Audio is 5.1 AC-3 format as per the original. I then ran the file through MPEG4Modifier to set the aspect ratio to 16x9 WS NTSC. Some software will not recognize the aspect ratio information and will play the file back incorrectly. I know that the VLC media player will play this file back correctly.

Please note that both files will play back correctly on MPEG-4 capable DVD players that use a MediaTek chipset (that includes many popular models such as the Philips DVP-5140, the Philips DVP-5960, the Pioneer DV-393, the Pioneer DV-490 and the Oppo Digital DV-970HD as well as the brand new Oppo Digital DV-981HD).

- John "FulciLives" Coleman

[Pinstripes23]

here's a simple question, what is the bitrate of the black borders? if they use up bitrate then you should be able to tell me how much bitrate is being used.

furthermore, assume you have a DVD encoded to 720x480 16:9, that is encoded to a constant video bitrate of 8500 Kb/s. if you play said dvd on a pc and display the output to your computer monitor, you will see black borders at the top and the bottom. are you telling me that the total bitrate of the image being displayed is now 8500 Kb/s + some additional bitrate for the black borders? of course not, noone would think such a thing. so then why do people believe that transcoding such a DVD to let's say H.264 at 720x480 16:9 would now cause the displayed black borders to take up bitrate? show me some proof, anything that makes you believe such a silly thing.

I should have made myself more clear. When you encode video as 16:9 for DVD and if the picture AR is greater than 1.78:1, then you must add black borders in order to display the AR correctly because of the non 1:1 pixel for display. Some of these common picture ar's are 2.35:1, which has bigger black borders than one that is 1.85:1. That is the black border I am talking about that uses bitrate when it is PART OF THE VIDEO RESOLUTION. When you view an encoded 16:9 video on a 4:3 display, there will be additional black borders added that is not part of the video resolution, in order to display the picture AR correctly.

Here is a sample pic of a 2.35:1 movie AR encoded to 16:9, without any filtering. This is for 4:3 display. You will see the borders are all black.



Now here cuz I filtered the video, the pic will display the black borders that is part of the 16:9 resolution. This is on a 4:3 display.



And to make things clear:



Of course you can make the black borders all black on the filtered pic, but that depends on how you arrange the filter chain and for another topic. When encoding your video the whole 16:9 frame gets passed to your encoder, and that uses bitrate which includes the picture plus black borders.

[Pinstripes23]

deadrats: upload a sample of a pal to ntsc conversion using procoder, and I will go through 30 consecutive frames at any point. The source must be progressive 720x576 with 25fps. So if I see duplicate frames, blended frames, then you are wasting bits this "expensive" encoder does when encoding.

first i don't have a PAL progressive DVD. second, if you convert PAL 25 fps to broadcast NTSC 29.97 fps, then by definition you must have duplicate frames. however, i was assuming (perhaps erroneously) that he intended to convert to true NTSC 23.97 fps. since PAL is 25 fps, international cinema rate is 24 fps and true NTSC is 23.97 fps, ProCoder can handle that conversion without breaking a sweat, without any blending, audio sync problems or the rest of the problems that can potentially happen with such a conversion.

maybe i should have been a bit clearer when i told him to use ProCoder and that he wouldn't have any problems. it never occurred to me that someone may actually be thinking of converting PAL to broadcast NTSC.

So you're telling me procoder can slow the movie down to 23.976fps, and stretch the audio to match the running time, while keeping it at AC3? I gotta see this. DGpulldown method of doing Pal-to-NTSC you don't touch the audio, so that's one step right there you can bypass, that procoder must do. So I look forward to showing us your skillz deadrats.

[manono]

first i don't have a PAL progressive DVD.

If you have any PAL DVDs of movies, then almost certainly you do have some progressive PAL DVDs.

second, if you convert PAL 25 fps to broadcast NTSC 29.97 fps, then by definition you must have duplicate frames.

Sorry, but that's not true. The encoded and stored frames will be all unique and unblended when done right, either progressive 23.976 or 25fps, depending on how you do the conversion. Sure, for NTSC display the applied pulldown causes duplicate fields to be output, but they were never encoded, they were never stored on the DVD, and they aren't frames anyway, but fields.

i was assuming (perhaps erroneously) that he intended to convert to true NTSC 23.97 fps.

It doesn't look to me that you assumed any such thing since you, not once but twice, showed the encoded output framerate to be 29.97fps. Anyway, as Pinstripes23 said, it doesn't really matter, as Procoder will also mess up 23.976fps by blending it.

true NTSC is 23.97 fps

True NTSC is 29.97fps, often encoded as 23.976fps progressive, with 2:3 pulldown applied to output 29.97fps interlaced. But the base encoded progressive framerate can be just about anything, 23.976fps, 25fps, 20fps, whatever (within certain constraints).

I won't even begin on that "black-borders-use-no-bits" silliness.

[FulciLives]

I just wanted to sum things up real quick before deadrats posts his PAL to NTSC work.

If you have read this entire thread then you know that I challenged deadrats to download a sample MPEG video that I extracted from a PAL DVD release and convert this to NTSC using his method(s) which he has indicated are superior to the method (DGPulldown) that I advocate.

He took the challenge saying that he would post his NTSC MPEG-2 sometime today and that he might also do MPEG-1 and/or MPEG-4 as well.

Here are all the links to my files:

1.) THE ORIGINAL PAL DVD sample clip
Link: http://rapidshare.com/files/5550678/testclip.mpg
File name: testclip.mpg
File size: 74.7 MB
This is the original PAL DVD sample clip extracted from the UK DVD release of THE DESCENT. This file has a resolution of 720x576 with progressive 25fps video. The file is 16x9 WS anamorphic with an aspect ratio of 2.35:1 and has 5.1 AC-3 audio.

2.) NTSC MPEG-2 DVD spec file using DGPulldown
Link: http://rapidshare.com/files/5553434/pal2ntsc1.mpg
File name: pal2ntsc1.mpg
File size: 86.8 MB
This is my NTSC conversion using the DGPulldown method. This file has a resolution of 720x480 with progressive 25fps video that has had pulldown applied for standard 29.970fps playback. The file is 16x9 WS anamorphic with an aspect ratio of 2.35:1 and has 5.1 AC-3 audio.

3.) NTSC MPEG2 DVD spec file using the "slow down" method
Link: http://rapidshare.com/files/5556438/pal2ntsc2.mpg
File name: pal2ntsc2.mpg
File size: 90.5 MB
This is my NTSC conversion using the "slow down" method. This means that I have changed the FPS from 25fps to 23.976fps. The file has a resolution of 720x480 with progressive 23.976fps video that has had 3:2 pulldown applied for standard 29.970fps playback. The file is 16x9 WS anamorphic with an aspect ratio of 2.35:1 and has 5.1 AC-3 audio.

4.) NTSC MPEG-4 at 640x272
Link: http://rapidshare.com/files/5670764/XVID640.avi
File name: XVID640.avi
File size: 27.0 MB
This is a XviD MPEG-4 file created in the "traditional" way meaning the image was cropped and resized to a square pixel resolution. The resolution is 640x272 with an aspect ratio of 2.35:1 and is progressive 23.976fps with 5.1 AC-3 audio.

5.) NTSC MPEG-4 at 720x480
Link: http://rapidshare.com/files/5673247/XVID720.avi
File Name: XVID720.avi
File size: 45.2 MB
This is a XviD MPEG-4 file created in a "non-traditional" way meaning I resized from the PAL resolution of 720x576 to a NTSC resolution of 720x480 thus creating a 16x9 WS anamorphic video with a 2.35:1 aspect ratio. The video is progressive 23.976fps with 5.1 AC-3 audio.


Please feel free to download these files and compare them for yourself and also to whatever deadrats will be posting.

Also please note that all of my MPEG files are DVD compliant so for the best effect burn to a DVD-RW or DVD+RW and watch on a TV instead of a computer monitor.

The two XviD MPEG-4 files will play on any computer with the proper software (I suggest the VLC media player). If you have a MPEG-4 capable DVD player that uses a MediaTek chipset then that is another option.

Again this post was just a summary. Thank you for your time.

- John "FulciLives" Coleman

P.S.
I have these files hosted on a free hosting service website. Files are guaranteed to be available for a minimum of 45 days. After that they get automatically deleted.

[deadrats]

I just wanted to sum things up real quick before deadrats posts his PAL to NTSC work.

sorry it took so long for me to get back, i know i promised i would post something by saturday, but the party i went to ended being a weekend affair, i just got back about an hour ago.

since i haven't had alot of time to really play around with the file, i did 2 really quick and dirty conversions, the first i did with ffmpeg from the command line (it took all of 90 seconds to convert the test file) and i did a quick 2 pass conversion (took about 2 minutes) using main concept's H.265 Encoder (don't worry, it's an mpeg-2 file). the target in both cases was 720x480, 16:9, 29.97 fps, but before i post the links there's a couple of things i noticed about the test sample you provided that i wish to discuss:

you claim that the sample was PAL, 16:9, 720x576, progressive, yet the file has a rather strange peculiarity that i find quite odd, to wit, the video isn't a true 16:9 is it? half the time the video played like a true 16:9 and half the time the video appeared as if it were 2.21:1, i.e. as if it were a 16:9 and black bars were added to the top and bottom of the image). the effect is exactly as was described (with pictures) by another poster in this thread, but this effect should not happen with a true 16:9, is 2.21:1 a common format for DVD's meant for certain markets?

what made this really odd is that i tried it with a number of different software players, such as GOM Player, Media Player Classic, MPlayer, Windows Media Player and VLC and each and every single time it was hit or miss, either it was played back as a proper 16:9 or it was played back as a 2.21:1, there was no way to predict what you would get.

the same holds true for the files you created, half the time they get played back in true 16:9 format, half the time they get played back in 2.21:1 and more importantly, on every player except VLC they have 2 additional thin black bars on the left and the right.

of the two files i created, the one created with ffmpeg has the exact same characteristics as described above, but the one i created with H.264 Encoder plays like a true 16:9 in EVERY player and EVERY single time, an outcome that i wasn't expecting. i plan on looking through the ffmpeg code to see if i can figure out what's going on.

lastly, for some strange reason, both Procoder and Procoder 2 refused to convert the file, the conversion would fail with an error, this is the first time i have ever seen Procoder fail to even attempt a conversion, i think i'm also going to have to sit and dissect that sample you provided and see if there's something funky going on (did you try and throw me a curve ball by altering its flag/header?).

anyway without further adue, here's the two quick and dirty conversions i did, please note i spent all of 4 minutes doing my conversions, you must have spent quite a bit more doing yours:

http://rapidshare.com/files/5919726/deadrats__testclip_1_main_encoder.mpg.html

http://rapidshare.com/files/5958009/deadrats__test_clip_2_ffmpeg.mpg.html

any criticism, angry insults or death threats are welcome.

-deadrats, for when your rats must absolutely, positively be dead.

[Pinstripes23]

Deadrats I downloaded your first clip and I viewed it, but to show some characteristics about your conversions here is a gspot screenshot:





Fist thing I noticed was the audio. 2 channel mp2 audio? You went from 6 channel ac3 to 2 channel. On the top right where it says pics/sec. If you converted to true ntsc-film, which is progressive, it should say 23.976fps. Frms/sec would still be 29.97fps cuz of pulldown. So I put it through vdubmod and went frame-by-frame and there are duplicate frames, so you waste bits encoding 6 extra frames (the dupe ones) for every 24. DGPulldown method you keep the 6 channel ac3 plus you don't waste bits encoding extra frames.

[FulciLives]

... there's a couple of things i noticed about the test sample you provided that i wish to discuss:

you claim that the sample was PAL, 16:9, 720x576, progressive, yet the file has a rather strange peculiarity that i find quite odd, to wit, the video isn't a true 16:9 is it? half the time the video played like a true 16:9 and half the time the video appeared as if it were 2.21:1, i.e. as if it were a 16:9 and black bars were added to the top and bottom of the image). the effect is exactly as was described (with pictures) by another poster in this thread, but this effect should not happen with a true 16:9, is 2.21:1 a common format for DVD's meant for certain markets?

what made this really odd is that i tried it with a number of different software players, such as GOM Player, Media Player Classic, MPlayer, Windows Media Player and VLC and each and every single time it was hit or miss, either it was played back as a proper 16:9 or it was played back as a 2.21:1, there was no way to predict what you would get.

the same holds true for the files you created, half the time they get played back in true 16:9 format, half the time they get played back in 2.21:1 and more importantly, on every player except VLC they have 2 additional thin black bars on the left and the right.

of the two files i created, the one created with ffmpeg has the exact same characteristics as described above, but the one i created with H.264 Encoder plays like a true 16:9 in EVERY player and EVERY single time, an outcome that i wasn't expecting. i plan on looking through the ffmpeg code to see if i can figure out what's going on.

lastly, for some strange reason, both Procoder and Procoder 2 refused to convert the file, the conversion would fail with an error, this is the first time i have ever seen Procoder fail to even attempt a conversion, i think i'm also going to have to sit and dissect that sample you provided and see if there's something funky going on (did you try and throw me a curve ball by altering its flag/header?).

The sample I provided (the file called, "testclip.mpg") is from an official UK PAL DVD release of the movie THE DESCENT. This is a 16x9 WS anamorphic PAL DVD with an aspect ratio of 2.35:1 and with 5.1 AC-3 audio. I ripped the movie with DVD Decrypter in IFO MODE into one large VOB file (I had file splitting set to none). I used DGIndex to demux the audio and the video then remuxed the video with the 5.1 AC-3 to get a MPEG file. I then cut the MPEG file with VideoRedo and the starting and ending edits were done on "I" frames.

The "testclip.mpg" file as well as my two MPEG files (my PAL to NTSC sample files) play back properly with PowerDVD. I didn't try to play them back in anything else because they are DVD compliant MPEG-2 files and I always use PowerDVD for anything MPEG-1/MPEG-2 or DVD related. I only use other media players (like VLC media player) for other formats like DivX or XviD or OGM etc.

So no I didn't try to throw you a curve ball nor do I think I did anything wrong "preparing" the MPEG file (i.e., the "testclip.mpg" file).

I cannot explain the issues you are having other than you should use a dedicated DVD media player for MPEG-2 DVD spec files. That pretty much means PowerDVD or WinDVD.

Also I think you will find that all three clips (the original and my two PAL to NTSC conversions) will play back properly once authored to a DVD Video disc and using a DVD player.

I'm downloading your files now ... haven't looked at them yet myself. I will comment once I take a look.

- John "FulciLives" Coleman

[deadrats]

pinstripes23: as i said, i spent less than 4 minutes creating both samples, so in all honesty i didn't pay much attention to what i was doing. after you pointed out the audio issue i went back and discovered something quite unexpected: main concept's H.264 Encoder doesn't encode to ac3 audio, the only options are LCPM, Layer 2 or Layer 1. i never noticed that before.

i'm a big fan of using open source, cross platform tools whenever i can (except for the times i find ProCoder to be indespensible), so i am experimenting with ffmpeg a bit more and will be uploading a few more test files before i go to bed tonight, but for right now, Family Guy is about to start and i love that show.

[vhelp]

Evening all.

Excuse me for budding in..

deadrats,

of the two files i created, the one created with ffmpeg has the exact same characteristics as described above, but the one i created with H.264 Encoder plays like a true 16:9 in EVERY player and EVERY single time, an outcome that i wasn't expecting. i plan on looking through the ffmpeg code to see if i can figure out what's going on.

It might help if you post your ffmpeg script, in finding the clue to your
positive experience. You may have had the Aspect Ratio param set correctly
in the ffmpeg script, while in the MPEG encoder you used (I'm assuming you did)
that you did not have the aspect ratio param set. I could be wrong, but I was
just budding in

-vhelp 4147

[FulciLives]

I took a look at your clip, deadrats__testclip_1_main_encoder.mpg

As pointed out by Pinstripes23 the MPEG is encoded at 29.970fps both "internally" and "externally". Approximately every 6th frame is a repeat.

Example:

1 - 2 - 3 - 4 - 5 - 5 - 6 - 7 - 8 - 9 - 10 - 10 - 11 - 12 - 13 - 14 - 15 - 15 - 16 - 17 - etc.

So you get 5 unique frames followed by a repeat then it starts over again.

Also the audio is 2 channel 224kbps MP2 ... what happened to the AC-3 audio?

Last but not least something very strange happens at frame number 2,125 ... Load the file into VirtualDubMod and go to that frame and then frame back a few and frame forward a few.

I'm not sure how to explain this but frame 2,125 is an "erroneous" frame that appears WELL before it should.

Frame-by-frame analysis will show clearly what I am poorly explaining but what I do know is that it should not be that way.

Because of the RAPIDSHARE.COM download rules I have to wait a bit before I can download your 2nd file, deadrats__test_clip_2_ffmpeg.mpg

Perhaps that one is better?

- John "FulciLives" Coleman

[deadrats]

FulciLives: you're right!!! i've never seen such a thing before. it might be related to the way H264 Encoder is threaded, it may be that it too uses the concept of "slices" and it "sliced" the video stream so that it could run the process in parallel but then "glued" the pieces back in the wrong order.

thus far this has proven to be a bit tougher than i initially thought, but i still have confidence in ffmpeg, so let me play around with it a bit more and let's see what can be done.

[manono]

I thought this was supposed to be a Procoder test on your part. Using encoders with which you are unfamiliar gives you an easy out for your gross incompetence. I'm sorry, but it was the first time I've used it.

If you had trouble getting it to encode in Procoder, maybe strip out the audio and encode the M2V. Load the Vob in DGIndex and File->Save Project and Demux Video. That will give you an M2V which should encode in Procoder using whatever inferior methods you usually use.

As Pinstripes23 said, the first one (I have to wait an hour to get the second one) shows one dupe frame in every 6 (or 5 in 30, not the 6 in 24 as he said). In my opinion, this disqualifies you from ever giving advice in this forum, and from any pretense that you have any idea what you're talking about. I didn't DL the FulciLives samples, but you will find only unique frames in them, I'm sure.

I'm not sure why you bothered to let the encoder convert the audio. Most people with any sense handle the audio separately, and mux it in at authoring time. Doing that would have kept the AC3 untouched.

Other things I would have done differently. Although progressive sources are normally encoded as progressive, you encoded this as interlaced. It's usually done that way for 29.97fps progressive sources, but as we know, you made it 29.97 by adding dupe frames, although the source is 25fps progressive. Retail DVDs when using a 25fps source (and when not blending the hell out of it for NTSC) will hard telecine it to 29.97fps. That's inferior to a soft telecine (using DGPulldown), but will still play much more smoothly than will your duplicate frames. You set a 6000 max bitrate, way too low, which will cause mosquito noise, color smearing, and macroblocking during complex scenes. Although this may be more controversial, DCT Precision should have been set for 10.

I know, you just did a quick 90 second encode of it using unfamiliar encoders. Why even bother?

[deadrats]

Evening all.

Excuse me for budding in..

deadrats,

of the two files i created, the one created with ffmpeg has the exact same characteristics as described above, but the one i created with H.264 Encoder plays like a true 16:9 in EVERY player and EVERY single time, an outcome that i wasn't expecting. i plan on looking through the ffmpeg code to see if i can figure out what's going on.

It might help if you post your ffmpeg script, in finding the clue to your
positive experience. You may have had the Aspect Ratio param set correctly
in the ffmpeg script, while in the MPEG encoder you used (I'm assuming you did)
that you did not have the aspect ratio param set. I could be wrong, but I was
just budding in

-vhelp 4147

perhaps you misunderstood, i initially said that main concept's encoder was the one that created a file i was happy with, ffmpeg's output had similar problems as i found with the test clip provided (though i'm starting to think it's not an ffmpeg issue but rather an issue with the way the general purpose media players are playing back the video, i may have to look through some of VLC's or MPplayers source and see what's going on).

however, after playing back ffmpeg's output with Blaze DVD i find that i like what it produced and it was a a piece of cake to do it. just so you know, i didn't use a script, i'm running win 2k and just downloaded a pre-built ffmpeg binary, opened a console window and launched ffmpeg with some basic parameters right from the command line.

i tend to be a big fan of ffmpeg as many "proprietary" encoders use it as a back end without acknowledging that it's being done.

i want to play around with it a bit more and see if i can improve the output further...

[Pinstripes23]

well here is a gspot screenshot of the 2nd one:



at least the multi channel ac3 is there. But the video is still encoded the same. Runnin thru vdubmod shows dupe frames.

[deadrats]

I thought this was supposed to be a Procoder test on your part. Using encoders with which you are unfamiliar gives you an easy out for your gross incompetence. I'm sorry, but it was the first time I've used it.

If you had trouble getting it to encode in Procoder, maybe strip out the audio and encode the M2V. Load the Vob in DGIndex and File->Save Project and Demux Video. That will give you an M2V which should encode in Procoder using whatever inferior methods you usually use.

As Pinstripes23 said, the first one (I have to wait an hour to get the second one) shows one dupe frame in every 6 (or 5 in 30, not the 6 in 24 as he said). In my opinion, this disqualifies you from ever giving advice in this forum, and from any pretense that you have any idea what you're talking about. I didn't DL the FulciLives samples, but you will find only unique frames in them, I'm sure.

I'm not sure why you bothered to let the encoder convert the audio. Most people with any sense handle the audio separately, and mux it in at authoring time. Doing that would have kept the AC3 untouched.

Other things I would have done differently. Although progressive sources are normally encoded as progressive, you encoded this as interlaced. It's usually done that way for 29.97fps progressive sources, but as we know, you made it 29.97 by adding dupe frames, although the source is 25fps progressive. Retail DVDs when using a 25fps source (and when not blending the hell out of it for NTSC) will hard telecine it to 29.97fps. That's inferior to a soft telecine (using DGPulldown), but will still play much more smoothly than will your duplicate frames. You set a 6000 max bitrate, way too low, which will cause mosquito noise, color smearing, and macroblocking during complex scenes. Although this may be more controversial, DCT Precision should have been set for 10.

I know, you just did a quick 90 second encode of it using unfamiliar encoders. Why even bother?

the reason i tried the alternate encoders is because ProCoder 1 and 2 just choked on the test file (i already mentioned as much). i have never seen ProCoder fail, but for some reason this file just causes the encoder to error out, so i had no choice.

but i must say, for a quick command line 90 second encode, i'm quite impressed with what ffmpeg did, run the file i provided threw a "proper" DVD player and see what i mean.

[deadrats]

manono: you're probably right, i shouldn't be giving advice in this forum but i feel i must despense one piece of advice to you:

if you're going to flame me and call me incompetent make sure you don't expose yourself as a rank amateur in the process. i'm refering to this statement of yours:

quote: "Other things I would have done differently. Although progressive sources are normally encoded as progressive, you encoded this as interlaced. It's usually done that way for 29.97fps progressive sources, but as we know, you made it 29.97 by adding dupe frames, although the source is 25fps progressive. Retail DVDs when using a 25fps source (and when not blending the hell out of it for NTSC) will hard telecine it to 29.97fps. That's inferior to a soft telecine (using DGPulldown), but will still play much more smoothly than will your duplicate frames. You set a 6000 max bitrate, way too low, which will cause mosquito noise, color smearing, and macroblocking during complex scenes. Although this may be more controversial, DCT Precision should have been set for 10."

you really need to learn the difference between progressive and interlaced encoding and that each encoding method has nothing to do with the resulting frame rate.

both of the encodes i created are progressive, i would never, ever encode anything as interlaced unless the source was interlaced to begin with. to clarify, the frame rate of a video is independant of it's status as a progressive video, you can have a video that's 23.97, 24, 25 or 29.97 fps that's interlaced or progressive. all the term progressive means is that the video is composed of full frames while interlaced means that each frame is replaced with 2 fields, an upper and a lower, so an interlaced 29.97 fps video is actually running at an "internal" frame rate of 59.97 fps and so on.

quote: "As Pinstripes23 said, the first one (I have to wait an hour to get the second one) shows one dupe frame in every 6 (or 5 in 30, not the 6 in 24 as he said). In my opinion, this disqualifies you from ever giving advice in this forum, and from any pretense that you have any idea what you're talking about. I didn't DL the FulciLives samples, but you will find only unique frames in them, I'm sure."

please tell me where you got your crystal ball so that i can buy one as well.

p.s. i would take your own advice and refrain from giving advice on this forum, it looks like you know "just slightly" less than me, so if i'm unqualified to help, then you are unqualified to even read the messages posted.

[Pinstripes23]

As Pinstripes23 said, the first one (I have to wait an hour to get the second one) shows one dupe frame in every 6 (or 5 in 30, not the 6 in 24 as he said).

My bad. Actually meant to say 6 dupe frames for every 24 original progressive frames. But it is 5 dupe frames for every 25 original progressive, which would add up to 30 total frames. I guess it's 25 cuz the encoder kept it at the regular running time for PAL and duping instead of doing the slowdown to 23.976 while duping the frames from there.

[manono]

you really need to learn the difference between progressive and interlaced encoding and that each encoding method has nothing to do with the resulting frame rate.

You encoded the first one as interlaced with alternate scanning. Do you dispute that? Open it in Bitrate Viewer or run the preview in DGIndex.

all the term progressive means is that the video is composed of full frames while interlaced means that each frame is replaced with 2 fields, an upper and a lower, so an interlaced 29.97 fps video is actually running at an "internal" frame rate of 59.97 fps and so on.

Are you talking about the pic_structure? What do you do, make this stuff up? Interlaced encoding can also output a frame pic_structure. Your first one is frame based. In fact, a field pic_structure, while certainly possible, and I own some DVDs that use it, is rarely used these days.

[FulciLives]

Well I've had a chance to look at the second file ... the one you called, deadrats__test_clip_2_ffmpeg.mpg

It is encoded the same as the first file ... every 6th frame or so is a duplicate of the frame before it.

At least you figured out how to stick the 5.1 AC-3 audio file into the final encode this time.

However I wouldn't call duplicate encoded frames a "success".

Another thing I noticed is that the Main Concept encoded video is very soft ... much softer than your ffmpeg encode and my encode.

Below are 4 images for comparison purposes:

The original PAL DVD frame



FulciLives - DGPulldown Method frame



deadrats - Main Concept Encoder frame



deadrats - ffmpeg frame



As I said the Main Concept Encoder looks very soft ... way too soft. The differences between my version and the ffmpeg version by deadrats is a very minor difference. I think mine looks a hint sharper but that might just be my ego! In all honesty they look about the same I guess (in terms of sharpness that is).

Please note that I even used a "video noise" filter on mine yet it is still nice and sharp. I did use a fairly "low level" setting though for the "video noise" filter. After all the source was a high quality source.

It does appear that I used a much higher video bitrate for my encoding than did deadrats but I'm not sure that accounts for the sharpness difference. For the record I used the HCenc encoder for this.

- John "FulciLives" Coleman

P.S.
deadrats ... you should try to use Procoder as per manono's suggestion (i.e., demultiplex and load just the video file into Procoder).

Another suggestion ... since I used HCenc and since HCenc is freeware ... perhaps YOU should try it as well.

*** EDIT ***
Sorry it took me so long to post all 4 images but my stupid cable modem suddenly started giving me connection issues. Too many people web shopping this time of year I guess LOL

[Pinstripes23]

you claim that the sample was PAL, 16:9, 720x576, progressive, yet the file has a rather strange peculiarity that i find quite odd, to wit, the video isn't a true 16:9 is it? half the time the video played like a true 16:9 and half the time the video appeared as if it were 2.21:1, i.e. as if it were a 16:9 and black bars were added to the top and bottom of the image). the effect is exactly as was described (with pictures) by another poster in this thread, but this effect should not happen with a true 16:9, is 2.21:1 a common format for DVD's meant for certain markets?

Can you explain what you mean by all this? How should a file be played like a true 16:9? The image AR for these test samples looks to be 2.35:1 ar. Didn't you see how I explained why black borders must be added within the 16:9 to display the image correctly? 2.35:1 doesn't equal 1.78:1(16:9), so how else would you fit it into there correctly without stretching the image vertically?

[manono]

Never mind.

[Pinstripes23]

deadrats, manono is right about you converting the first one as interlaced. If you don't believe it, go to the gspot screenshots above and look at the first one under the pics/sec field, the I/L will show up. The second one you did progressive.