View Full Version : Impossible footage
Trixter
2nd May 2006, 08:21
First off, I want to say that I've been encoding MPEG-1 and MPEG-2 video for nearly a decade, so I'm familiar with the concepts behind MPEG-2 (discrete cosine transforms, quantization matrices, luma vs. chroma, subsampling, etc.). I say this to let you know you can use any terminology you like in your replies.
Here's my problem: I've got some incredibly difficult PAL material to encode for an upcoming DVD, and I have access to CCE SP 2.70.02.01. The material has, in some sections, what is essentially a concentric interference circle test pattern moving at the full 25i (50 images per second). Here's a sample frame (demosceners will recognize this):
ftp://ftp.fusecon.com/pub/SOTAChallenge/SOTA_original.png
(I duplicated one field for demonstration purposes; the actual footage is interlaced). Now, no matter how I try to encode it, I get enough quantization and blocking artifacts that I'm unhappy with the end result. Here's the same frame using CCE SP's CBR @ 8500 (my maximum bitrate allowed for video on the DVD due to reserved space for audio tracks) at five passes and no extended options/filtering:
ftp://ftp.fusecon.com/pub/SOTAChallenge/SOTA_MPEG_artifacts.png
As you can see, the chroma has become completely blurred. In motion it's not as noticable, but it's nowhere near the crispness of the original footage. And this is @ 8500kbps!
If anyone can come up with one or more settings I may have missed that clearly improve the quality of the footage over my efforts, I'll send you a free copy of the DVD when it's finished. (Or, if I should be using some other encoder, that information would be helpful too, but I really like CCE and would like to stay with it.) Here's a link to the sample footage I used that you can use for testing: ftp://ftp.fusecon.com/pub/SOTAChallenge/SOTA_sample.7z
It's 720x576 25i PAL, uncompressed YUV. VirtualDub loads it just fine, as does CCE; if you have a problem viewing it, snag the Blackmagic Design codecs from www.blackmagic-design.com)
If anyone can help, I'd be most appreciative! I've spent a week dorking around with the filtering and various quality options and all it does it make the edges blurrier (which degrades some fine detail earlier in the video). I've also messed around with the quanization matrix, but I think CCE discards that if you run multipass, yes? All I ask is that the footage must stay interlaced -- If you deinterlace it, half the motion will be thrown away and it looks like crap.
(PS: It's *not* emulator output, but analog Amiga RGB run through a broadcast scan converter to YUV 4:2:2 and captured through a DeckLink SP via component cables -- pretty nice capture, eh?)
scharfis_brain
2nd May 2006, 17:21
is this better? : http://rapidshare.de/files/19445504/Trixter.rar.html
I used 9400 kbps for the Video and 224 kbps for the Audio. Si it still is DVD compliant.
please tell me - without analysing the files - which one looks better with normal (bobbed) playback.
Trixter
2nd May 2006, 20:40
is this better? : http://rapidshare.de/files/19445504/Trixter.rar.html
I used 9400 kbps for the Video and 224 kbps for the Audio.
Hey Scharfis, long time no see :-)
Unfortunately, I can tell you already I can't use it. In my original post, I stated that the maximum video bitrate cannot exceed 8500kbps because the audio tracks take up the rest of the space. So your 9400kbps test exceeds that...
That being said, I'm downloading the file now and will take a look at it when I get home tonight (I'm in USA) and I'll let you know which looks better on a real PAL broadcast monitor, just for your own records.
scharfis_brain
2nd May 2006, 22:46
oh sorry, I missed the bitrate thing. of course I can redo it with 8500 kbps: http://rapidshare.de/files/19473053/Trixter.rar.html
Trixter
3rd May 2006, 04:32
please tell me - without analysing the files - which one looks better with normal (bobbed) playback.
I grabbed the 8500 files. First off, I don't know how you multiplexed it or what, but it stutters quite badly in VLC (Deinterlace->Linear is a refresh-rate-synced interpolated bob so that's my usual software playback). So I stopped looking at them in VLC and burnt them as-is to a PAL DVD and played them in a PAL player on my PAL broadcast monitor. I told my program not to re-encode them, and it didn't, but they still don't play right on the player... so I then de-multiplexed them and then re-multiplexed them and got errors regarding buffer underflows... finally tried to play the files themselves using the file selector mode of my DVD player... no go. So how did you make these? How were they multiplexed?
I ended up looking at them in VirtualDubMod. The first one you cheated :-) and used Half D1 -- sorry, but the loss of horizontal resolution will seriously damage the 640x200 title screen earlier in the demo ;-). The second one does look better, though! How did you make it? What encoder, what parms, etc.?
scharfis_brain
3rd May 2006, 06:03
I used Canopus Procoder 2 and its Fieldbased encoding mode (Frame type = AUtomatic).
The other parameters were left at defaults except I set:
DC-precision: 8
Encoding Quality: Mastering Quality
I do not have such immense problem with the fieldbased encoding as you experienced. In Mediaplayer classic with the dscaler mpeg decoder filter they play fine for me. The m2p's were muxed by the encoder itself.
WHen I author DVDs I create elementary streams which I then put into ifoedit or muxman directly. And that works pretty good.
btw.: In that particular scene Half D1 didn't damage a thing ;) after figuring out that pointresize(width/2,height,1,0,width,height) took the right pixels without blurring them.
But with 640x200 sources you will loose detail, of course.
Trixter
3rd May 2006, 07:21
I don't have Procoder so I can't test with that, unfortunately (and demodvd project isn't exactly overflowing with money to purchase it :-) But you may still earn a free DVD yet -- I hadn't thought to try DC precision of 8, although I wonder how much that will mangle the fade-ins/outs. I'll give it a shot as soon as I'm done restoring the system drive on the video rig (grrr).
I was always under the impression that CCE SP was one of the kings of the hill -- are there better MPEG-2 encoders to use and/or purchase? Is ProCoder that much better, for example?
PhillipWyllie
4th May 2006, 20:40
Here's my effort with CCE 2.70.02.06 SP :http://rapidshare.de/files/19624716/SOTA_sample_v_tff_.m2v.html(12Mb).
I deinterlaced first, and encoded VBR@ 8500kbps max, 8000kbps average. I think the big mistake you made was to encode CBR. If you leave adaptive Q-matrix on(recomended)[under template\advanced] it won't make a blind bit of difference what matrix you use.
Trixter
6th May 2006, 06:48
Here's my effort with CCE 2.70.02.06 SP :
I deinterlaced first, and encoded VBR@ 8500kbps max, 8000kbps average.
A good effort, but I can't really do the same since you deinterlaced it. As I wrote in the original post, the footage needs to stay interlaced because it really does contain 50 different images per second.
I think the big mistake you made was to encode CBR. If you leave adaptive Q-matrix on(recomended)[under template\advanced] it won't make a blind bit of difference what matrix you use.
More excellent advice, thank you! I'll try this combined with Scharfis' DCT precision of 8 bits and see what I get.
PhillipWyllie
6th May 2006, 19:21
There are three reasons I deinterlaced:
1.) The source really is progressive(all computers render graphics progressive, the RF unit then interlaces).
2.) I couldn't tell if the material was tff or bff(that's what led me to conclude it was progressive).
3.) The material looks infinitely better deinterlaced(no combing artifacts).
What we have here is mosquito noise(which is due mainly to motion) and can be reduced (supposidly)by reducing the GOP length. You can try playing around with the GOP settings under template\advanced, noteing that even if all you have is I-frames the stream is still DVD compliant(you can also have variable GOP lengths).
scharfis_brain
7th May 2006, 00:28
1) the video is interlaced. there are 50 movements per second
2) then your setup is wrong.
3) I don't understand. you seem to contradict yourself here.
but I agree that another GOP structure can help here.
I-Frame only GOPs just will make it worse but a GOP without B-Frames may help pretty much: IPPPPPPPPPPPPPP
Trixter
9th May 2006, 09:32
but I agree that another GOP structure can help here.
I-Frame only GOPs just will make it worse but a GOP without B-Frames may help pretty much: IPPPPPPPPPPPPPP
Agreed, but I can't seem to get it exactly in CCE. Best I can do is M=1, N/M=5, GOP header every 3xN frames. (DVD compatibility is checked, because this is going onto a DVD.) This leads to a sequence of IPPPPIPPPPIPPPP. The end result is essentially the same poor quality.
CCE is very flexible except in one area: Motion Estimation. Proprietary algorithm, but not tunable. I was able to get slightly (by a hair) better results from TMPGEnc with a High (slowest) motion search...
Should I abandon CCE for this footage? If so, what alternatives are better? I would like to avoid spending $700 for Procoder if at all possible, given our existing investment in CCE.
Use ProCoder 2. How you said CCE has poor Motion Estimation algorithm. Maybe it will change, because I've already reported that for CCE support.
Andrew
scharfis_brain
9th May 2006, 12:48
Maybe ProCoder Express may be an option for you. It costs about 54€.
IMO it uses the encoding engine of Procoder 2 and has downgraded features and flexibility compared to Procoder 2.
However. This won't be such a disadvantage, because I mostly used standard-settings.
Trixter
8th September 2006, 20:24
For anyone interested, the problem was "solved" (not really) by not trying to encode the problem footage all by itself and splicing it into the 3+ hour project, but just letting CCE do an n-pass encode on the entire thing and deal with it as best it could. The results aren't perfect, but they're at least as good as my custom efforts without the pain of CBR slammed at 9mbit/s.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.