Bad Pixellation with Fast Mpeg2 Encoder Enabled

[TimA-C]

Dan, if I have a DVB-T file with GOPs bigger than 15 (PAL default) and I save it from VRD TVS with 'Max GOP Length' set to 15 then I get bad and regular pixellation throughout the resulting .mpg file if the 'Fast Mpeg2 Encoder' is enabled. If I save the same file with either the 'Fast Mpeg 2 Encoder' setting disabled or I don't set the 'Max Gop Length' then the resulting .mpg file plays fine. You should be able to try this on any recording from 'Dave' on Freeview and probably More4, E4, etc.

I've tried this several times with versions 549 and 551 (and I think I had this with some previous versions as well). The pixellation is clearly visible in Windows Media Player 11, Real Player 10, VLC, Nero Showtime, Winamp, etc. I'm running Win XP Home (sp2) fully up-to-date, AMD X2 4200 CPU, 2 x 1Gb PC3200 DDR, nVidia 7600GT (nVidia Forceware 169.21) and no codec packs.

[DanR]

I haven't seen this here. What quality setting are you using on the Tools>Options>Stream page and encoding speed on the Tools>DVD page.

[laserfan]

Can we get an explanation please as to what the "Fast MPEG2 Encoder" is and why it's buried deep in the "Manual Parameter Settings" shift-Options area?

I'd been using it all last year until with TVS it crashed--I turned it off and haven't thought about it again until this thread.

[phd]

Could you trim and copy a 30-50MB segment of the original file and upload it to us? Tools>Trim and Copy Source File

Confirm that the trim and copy segment has the same problem before uploading.
ftp://upload:upload@videoredo.net/

Create a folder with a unique name and place the file in it.

Send an email to Support@VideoReDo.com and let us know when it has been successfully uploaded.

Also include a reference to this topic number: 5951

[DanR]

Can we get an explanation please as to what the "Fast MPEG2 Encoder" is and why it's buried deep in the "Manual Parameter Settings" shift-Options area?

I'd been using it all last year until with TVS it crashed--I turned it off and haven't thought about it again until this thread.
The fast encoder is a totally new encoder derived from HCENC which is many times faster than our old encoder in Plus. There was a bug in the earlier versions (fixed during the summer or fall I believe) that would cause it to crash on some 1080i material.

The fast encoder is used exclusively when recoding video for DVDs, and the manual options page determines which encoder (old or new fast one) is used for cut points, GOP reduction and titling.

Update: Check the code, and it appears that "Enable Fast Encoder" is still defaulted to Off, so I can only guess that many users are not currently using it. I guess we changed the default to Off back when we had the crashes during the beta and never reset the option. I would appreciate if some folks here could give it a try.

[Anole]

I am more likely to change GOP length during editing, but not have TVS make a DVD for me.
There is actually a difference in encoders between just an edit-save and DVD authoring???

I do recall making some DVDs last summer and seeing them play badly on a buddy's laptop computer connected to his 32" SD TV.
It's been too long and I don't remember if they looked bad on my TV , but it was strikingly annoying.
The picture jerked every second or two.
I chalked it up to some garbage software/hardware he was using, at the time.

Back then, I think I was setting GOP=48, and I suppose the glitches were about 1.5 seconds....
But, had I authored with TVS in an early experiment?
I just don't recall.

Not really sure this is associated.
Just know that I've not noticed problems with my stand-alone DVD players, nor hi-def TV.

Fast MPEG Encoder , line 39, is turned off in my copy here on the laptop..

[laserfan]

The fast encoder is a totally new encoder derived from HCENC which is many times faster than our old encoder in Plus. ...the manual options page determines which encoder (old or new fast one) is used for cut points, GOP reduction and titling... I would appreciate if some folks here could give it a try.Thanks DanR for that explanation. I will turn Fast MPEG2 back on for all my HDTV editing--I think I've only made one DVD since TVS was officially released. :o

[TimA-C]

phd, I will get back to you with sample video & logs etc. but it's the first few days back at work since the holidays and it's pretty hectic. Also, living out in the sticks, I have to contend with a "blisteringly fast" .5Mb broadband service so big uploads are a bit of a PITA!

I'm (fairly) sure I have brought this up before and was advised to turn off the Fast Mpeg2 Encoder to solve it. It's only because I had to uninstall & re-install VRD TVS recently (don't ask!) that I came across the problem again.

[rgoold]

Dan,

With respect, I think you're mistaken about this only applying to DVD encoding. I remember testing this with one of Plus betas before DVD authoring was added and being very impressed with it's speed.

I'd noticed it was turned off in TVS and had assumed it was still in beta.

I've turned it back on (in 549) and the throughput in the regular editor is much faster around the cut points.

[DanR]

With respect, I think you're mistaken about this only applying to DVD encoding. I remember testing this with one of Plus betas before DVD authoring was added and being very impressed with it's speed.
I think you misunderstood me. What I meant was that the fast encoder is always used if reencoding for DVD regardless of the Shift+Tools>Options setting.

You are correct it was enabled during one of the Plus (later to be renamed TVSuite betas), but then turned off due to the 1080i crash problem. After fixing the 1080i problem, we forgot to reenable it by default so most users are not taking advantage of the encoder for cut points and titling at this time.

I'm still waiting to see some examples of pixilations / problem cuts that are related to the fast encoder.

[rgoold]

I see, thanks.

Being in the UK I can reproduce the issue reported by TimA-C, there is a regular pulsing pixelation effect across the whole display and throughout the file. The resulting file size is several percent smaller.

I've no idea of the technical details, but as a viewer I know that the picture quality on these channels is relatively poor when compared with the main BBC or ITV channels.

Unfortunately I'm on dial-up so an upload difficult for me too.

[TimA-C]

... I'm still waiting to see some examples of pixilations / problem cuts that are related to the fast encoder.
OK. OK. I can take a hint! :) I've just uploaded some files to a folder called "Topic 5951 - Bad Pixellation" on the ftp site and sent you an e-mail detailing what the files are and where they came from. Hope they help.

Keep up the good work, guys, it is appreciated by most of us whinging users.

[TimA-C]

I see, thanks.

Being in the UK I can reproduce the issue reported by TimA-C, there is a regular pulsing pixelation effect across the whole display and throughout the file. The resulting file size is several percent smaller.

I've no idea of the technical details, but as a viewer I know that the picture quality on these channels is relatively poor when compared with the main BBC or ITV channels.

Unfortunately I'm on dial-up so an upload difficult for me too.Nice to know I'm not the only one. When nobody else reports the same problem, after a while you do start wondering if it's just you and that you're doing something incredibly stupid, so thanks for easing that little worry, rgoold.

[halsboss]

The fast encoder is a totally new encoder derived from HCENC which is many times faster than our old encoder in Plus.

Great ! HC is a fantastic encoder. Just an fyi, in v022 there's a compatibility issue re use of *LUMGAIN if you use it, where some standalone DVD players go to choppy video playback (eg some sony players) ... http://forum.doom9.org/showthread.php?p=1084786#post1084786 :)

why does this post keep disappearing ?

[Anole]

Your multiple posts were auto-moderated (sent to bed without their supper) and a message to that effect should have been displayed.
I've deleted the extra posts, and we're all better now. :D

[DanR]

Just an fyi, in v022 there's a compatibility issue re use of *LUMGAIN if you use itWe don't use that feature.

OK. OK. I can take a hint! :) I've just uploaded some files to a folder called "Topic 5951 - Bad Pixellation" on the ftp site and sent you an e-mail detailing what the files are and where they came from. Hope they help.Thanks for the upload it immediately pointed out the problem. This topic header is "bad pixellation", but actaully the problem isn't pixellation but "blocking". Pixellation is when spurious data appears in an image. Blocking is when a video is encoded at too low a bit level and the artifacts of encoding are visible. Should have a fix available in a few days.

[estork]

Dan asked for user reports on "Fast Encoder."

I have had that option set "True" in both 549 and 551 and have NOT encountered any problem of which I am aware when encoding mpeg2 files that were recorded on a Hauppauge PVR150 board in a P4 XP-SP2 1.8meg CPU Intel 845 motherboard system.

Eric

[TimA-C]

We don't use that feature.

Thanks for the upload it immediately pointed out the problem. This topic header is "bad pixellation", but actaully the problem isn't pixellation but "blocking". Pixellation is when spurious data appears in an image. Blocking is when a video is encoded at too low a bit level and the artifacts of encoding are visible. Should have a fix available in a few days.I stand corrected!

[DanR]

It appears that the "blocking" occurs during GOP shortening. This has been fixed and will be available in our next build.

[Anole]

It appears that the "blocking" occurs during GOP shortening.

Probably what I described in post #6 above.
However, I ran a couple of discs through TVsuite last night for end-to-end authoring, with the fast encoder turned on, and didn't notice a problem.
I loaded TVS 551 before the test.
Is it possible I'm seeing something different in NTSC, or maybe in differing playback equipment here?

This has been fixed and will be available in our next build.

Or maybe I'll just hold off an 11 show project for a few days... :)

[TimA-C]

Just tried my test clip in v552 with the fast mpeg2 encoder turned on and everything looks good. Thanks, guys.

[TimA-C]

One final wrinkle found! Everything seems to work OK as long as you don't set the Bitrate whilst saving and reducing the max gop size. On my sample clip, if you set the bitrate to 2mb/s then you get heavy blocking, very similar to the results I was getting in 551. The higher the bitrate you set, the less blocking you get. If you don't set the bitrate then I can't see any blocking.

[DanR]

Why do you say that's a wrinkle? When you do a GOP reduction, the bit rate of the GOP is going to rise becuase you are converting P frames into I-Frames. By setting the header bit rate to 2Mbps, you aren't giving the encoder many bits to work with.

[TimA-C]

I say it's a wrinkle because it doesn't happen if you turn off the fast mpeg2 encoder.

[DanR]

OK, will check it out. However I think the difference is that the fast encoder pays more attention to the header bit rate than the old encoder did.

[TimA-C]

Maybe. It's just that I got into the habit of setting the bitrate to something realistic so that TMPGenc DVD Author didn't complain. Since you've added the setting for VRD to automatically set the actual bitrate in the saved file's header, it's a habit I should break. I really only noted it here in case other people noticed the blocking without knowing how to avoid it. In other words, don't waste your time on it on my account.

[TimA-C]

Dan, I thought changing the BitRate in the 'Output File Options' only changed the value in the outputted file's header?

[DanR]

That's true, but when you shorten GOPs it needs to choose a bit rate to encode with. In build 551 with the fast encoder, the bit rate is determined by the bit rate of the I-Frame for the current GOP. This will preserve the original quality, but raise the overall bit rate for the two GOPs since a P-Frame will be reencoded at a higher bit rate.

Now, the header bit rate limits the bit rate for the entire GOP. So we use that as an upper limit. However, in thinking about it, that might not be a great idea since this could force the encoded I-Frame to be too low. Let me see what I can do for the next build.

[TimA-C]

Thanks. :)