Does anyone else get severe blockiness on cuts, chapter points or transitions in TMPGEnc Authoring Works 5? 90% of the time, it works fine, but roughly 10% of clips I use are affected by this issue, and I'm yet to spot a pattern. It seems completely random. Here's a 30-second example I've made to demonstrate the problem:
I'm in Windows 7 and using the latest version of Authoring Works. There's a chapter point on the first two pixellations, and a fade-to-black transition at the end. Running the output VOB through Bitrate Viewer shows that the bitrate drops to a pitiful 882kbps on the first chapter point, and isn't much higher on the other two affected parts.
For the avoidance of all doubt, here's the source file (simple VHS -> standalone DVD recorder transfer):
So obviously Authoring Works - even when using a DVD-compliant MPEG - has to re-encode the picture briefly when cuts are made, chapter points are added between I-frames, or transitions are used. That's fair enough. But why does it make such a terrible job of it? Is there something intrinsically wrong with the source file? No other program seems to have any issues with it, so surely we should be able to expect better from Authoring Works. And it makes no difference whether I set the Smart Rendering option to VBR or CBR - it still spits out a VOB file with affected areas that look like they were shot on an early-90s webcam.
If anyone using the same software wants to try to recreate the problem (and I'd be extremely grateful if you do), this should take you no more than two minutes:
1) Start a new PAL DVD project.
2) Import the source file into track 1.
3) Add chapter points at 00:19:00 and 00:25:84.
4) Transition edit > Fade Out/In (Black), 2 seconds.
5) No menu.
I left everything on its default settings, but feel free to experiment. Please let me know how you get on, or if you can offer any suggestions that may help, because I'm completely out of ideas.
Many thanks in advance!
+ Reply to Thread
Results 1 to 9 of 9
They don't give you any control over the bitrate or quantizer used for the reencoded sections?
I downloaded your source file and set up a project like the one you described and got the same results.
Then, after poking around in the program's settings and help file and finding no resolution, I loaded the source file into MPEG Video Wizard DVD 5.0 and exported the source file from there (no transitions or anything). Then I loaded the new source file into Authoring Works and got a file with no pixelation. I have no idea why though. The only difference between the 2 source files is the bitrate. In the original file, the bitrate was 9248. In the new source file, the bitrate was 9278.
GSPot map of the GOP structure. You can see the regular pattern of the source file on top, the reencoded sections on the bottom.
If you zoom in to the bitrate map with Bitrate Viewer in frame mode you can see that even the I frames of the reencoded GOPs are tiny:
VideoReDo, and sometimes it works, sometimes it makes no difference. It really does seem random, as I can't for the life of me spot a pattern.
There is actually a more sinister related problem: when Authoring Works encounters one of those slightly broken MPEGs which are a fact of life (you know, the occasional GOP/timecode issue but still plays just fine), rather than just fixing the structure, it does the same thing. It's like Russian roulette - I can never actually be certain of a good DVD build.
Many thanks for everyone's help so far.
This is even worse:
Watch as the runner crosses the line. (Plus, there's also a bonus little one at the end.) Want to try to recreate that? Here's the source file:
1) Start a new PAL DVD project.
2) Import the file into track 1.
3) No menu.
That's right: no chapters, trims, transitions, or anything else - just pass the clip straight through Authoring Works and out the other end. Now, I accept there must be a glitch with the source (in fact, does anyone know what it is? I didn't do the transfer on this one), but as it plays acceptably in every media player I've tried, surely Authoring Works should make a better job of the output, shouldn't it? I was fortunate enough to spot that one, but in a real world situation, that would be a very nasty surprise long after the project has been put to bed and the source files deleted.
I hope the developers are reading this.