Temporary bummer.

The major glitch that Grazie found does not seem to have an obvious solution. I just re-encoded, making sure that my MeGUI queue was clear before I started, and once again, it encoded the video twice, with the second instance having no audio. I suspect something is odd with the way it is multiplexing the audio and video.

The only deviation from the tutorial is (and I already mentioned this) that I used FAAC audio instead of the Nero audio. I watched the video in the Vegas preview window as it was being frameserved out to AVISynth, and the video was definitely only requested once (i.e., it did not start over again at the beginning).

I did a quick Google search, but couldn't come up with any clues.

[edit] Tried deleting all MeGUI files and then "installing" again, but that didn't help. Tried demultiplexing and then remultiplexing using a tool outside of MeGUI, and that almost worked, but the audio went silent in the middle of the clip and then came back. I looked at the bug report thread on doom9.org, but it is 95 pages long and searching on "mux" within the thread didn't get me very far.

[Further edit] After 1/2 an hour of fiddling, I figured out that it is a bug with how it muxes audio from the FAAC encoder. I switched to the LAME MP3 encoder and all appears to be healthy. I'll try to remember to report it tomorrow.

I have uploaded a fixed video, so the video in my post above should now play correctly.

johnmeyer wrote: >> ...here are the results of a couple of hour's worth of fooling around (most of it spent getting QTGMC to work multi-threaded... <<

John, it's great to have you and your immense expertise involved in this project. Thanks. I'm wondering if you could post those valuable findings on the QTGMC thread on the doom9 forum. I know you're a member there and I'm sure the author -Vit-, the originator Didée, and others would appreciate it.

farss wrote: >> One thing I've found with the smart de-interlacer and I think will also apply to YADIF is noise can really screw it up <<

QTGMC should excel with noisy footage. This seems to be one of its main strengths, although I haven't personally tested it for that specifically. And there are plenty of settings in it to tweak. The cost is processing time.

johnmeyer wrote: >> the &fmt=22 switch doesn't seem to be working <<

YouTube have shelved those fmt switches in favour of giving control of the resolution to the viewer's setup and preferences.

Nice video, John, and, temporary showstoppers aside, it's good to see a graphic validation of the technique.

>> or the highlights I only used the video from the FX1 <<

So, just to be sure, the footage was HDV 1080-60i, right? Also, if you used a crf of 19.2, what bitrate did your video stream come out at (MediaInfo can quickly tell you that)?

>> I'm still not sure the levels are correct <<

You can retrieve the downloaded YouTube file from your browser cache and use the Vegas scopes to compare levels with the original. I find it easier to retrieve files from the IE cache than the FF cache. But I've just started using this brilliant script which puts a download button right under the YouTube video and offers all the resolutions. I use it in Google Chrome. In FF you need to have Greasemonkey installed.

>> Wow, something went really wrong with the encode! <<

In the past I had an issue with double-speed audio when I uploaded MeGUI/x264/Nero-AAC output to Facebook. I put this down to using HE AAC profiles instead of LC, as the problem went away in my latest upload.

If you continue to get trouble and suspect the audio stream, ABR might be upsetting something. Try CBR instead. I should probably have advised CBR in the tutorial anyway. ABR is more for low bitrates. Alternatively I'm wondering if trusty old LAME mp3 could be muxed into the mp4 and read by YouTube etc.. At high bitrates it should sound the same as the AAC options. It's available in MeGUI.

I think MeGUI is using mp4box under the hood to mux, but If you suspect a muxing problem, maybe you could skip the MeGUI mux (don't do autoencode) and try muxing manually to see if you get the same result. I have successfully used mp4box inside the Yamb GUI in the past but I seem to remember that command line operation was a piece of cake.

The other option is to mux to an mkv container instead of mp4. That is also available in MeGUI. I have read that YouTube will accept it. I don't know if Vimeo will. I bet Facebook does as they read uploaded files with ffmpeg. I doubt Vegas will open it.

If the trouble persists, here's the MeGUI: General Questions and Troubleshooting Thread. I got very fast responses there the other day.

Embarking on more testing now... I'm still interested in anyone's Mike Crash settings (Bob? Laurence?).

>> it is a bug with how it muxes audio from the FAAC encoder <<

Glad you got it sorted. I'll amend the tutorial to say use LAME if you don't want to use Nero.

Nick,

I just read your long response. Too late for me to reply both here and at doom9. I'll get to it tomorrow. Thanks for all your help!

John

Also John, could you please confirm which multi-threaded version of AviSynth you're using. I linked to 4 different ones in the MT part of the tutorial. One is based on AviSynth 2.5.7.5, one on 2.6, and the other two on 2.5.8 but compiled using differently. They may all give different results.

p.s. There is already feedback on your MT findings.

Rob Mack wrote: >> (in VP9 and 10) that Vegas *always* deinterlaces stills exported from the preview window in NTSC DV projects. (probably in all interlaced projects) <<

Rob, I'm seeing the same thing with 1080i footage in 10.0c. I guess they think we're too dumb to do our own deinterlacing. It really sucks because we're stuck with Vegas' crude deinterlacing for stills. This is another reason I'll be keeping 8.0c on my system (the other, so far, being free Cineform rendering).

[Further edit] After 1/2 an hour of fiddling, I figured out that it is a bug with how it muxes audio from the FAAC encoder. I switched to the LAME MP3 encoder and all appears to be healthy. I'll try to remember to report it tomorrow.

It would be a good idea to upload some YT and Vimeo tests using LAME before getting too deep. Although I prefer it to faac, both upload services say they "expect" aac. Will be interested to see if they like mp3. Matter of fact, I'll try one today, and if it works, I'll include LAME as the suggested audio encoder in my Handbrake tutorial.

I always used to send YouTube Xvid + Lame muxed as .avi. But worth an up to date check.

Also John, could you please confirm which multi-threaded version of AviSynth you're using. I'm using (based on using the "version" call): "AVISynth 2.5.8 tsp MT version 5(mod seraphy), build: Aug 16 2009 [23:00:29]"


I'm wondering if you could post those valuable findings on the QTGMC thread on the doom9 forum. I know you're a member there and I'm sure the author -Vit-, the originator Didée, and others would appreciate it.I looked at your post at the end of that thread, and at Didée's reply. He and some of the other gurus there know infinitely more about some things than I do, but they are often very prickly to deal with, as you can tell by his response where he claims that I should be able to use more than four cores. However, if you look at his script, it is amazingly complex, and depending on the settings used, there are all sorts of interactions, potential race conditions, etc.

The old adage is: according to engineering calculations, the bumble bee cannot possibly fly. The bumble bee, not being an engineer, merrily flies through the air ...

So, I am quite certain that on my computer, with the script settings used, serving into VirtualDub, the script slowed down and became unstable when using more than four cores.

So, just to be sure, the footage was HDV 1080-60i, right?Yes, that's right.

Also, if you used a crf of 19.2, what bitrate did your video stream come out at (MediaInfo can quickly tell you that)?Yes, I used 19.2. GSpot reports 3,580 kbps. This sounds about right because the MP4 I created from Vegas in December was done at 4,000 kbps, and its file size is 101,486 kB. The new MeGUI fil is 89,394. The ratios of the files sizes and the reported bitrates are virtually identical.

As for levels, the latest upload looks fine, except for the glitch in the first three seconds. I am re-uploading (3rd time's the charm) because I think this was a YouTube glitch, hopefully a one-time problem.

As for testing the muxing bug, I don't know if I have time to get into that. I think the LAME audio is probably going to be plenty good for my purposes in uploading to YouTube, etc., so if I can get it to work, I'll just go with that, and if I need a little more quality, I'll just crank up the audio bitrate.



I just tried to upload the video again, and YouTube rejected it as being a duplicate. So, I'm deleting the new video, then re-uploading, and after all that I'll find out if the washed-out first scene is a YouTube bug, or is some sort of interaction with the MP4 file. The MP4 looks fine when played in VLC.

John, we cross-posted yesterday, so by the time I'd posted my trouble-shooting suggestions, you'd already fixed it and edited your post. So forget all about the muxing tests and go with LAME, assuming YouTube accepts it.

Err... I think you mean "serving into MeGUI", not VirtualDub, don't you?

YouTube does come up with some weird bugs. I was getting 2 seconds of mangled footage at the end of Stringer's driving clip that never showed up in VLC. I couldn't get rid of it no matter what. Something to do with the GOP structure perhaps. Maybe adding a frame or two longer lead-in to the video might fix it for you.

Interesting that YouTube are kicking out duplicate videos so quickly these days. If they cotton on to all our near-identical test uploads then there are going to be a lot of broken links! I expect the change in the title in the first few seconds has saved us.

Still got the testing bug so I've done some short comparisons of the rendering speed and quality of 5 different AVC encoders (see table below) at low bitrate 720p.

Each render is 12 seconds long, based on 3 clips from the test project we've been using. With the detailed, moving footage, everything looked terrible at 1Mbps, so I've tuned them all to 2Mbps. By using VFAPIConv to get back into Vegas, I've taken the interlacing and resizing out of the mix as variables so this is purely an encoder comparison. Each render has gone from 1080i to 720p via the same "faster" QTGMC deinterlace and Lanczos3 resize in AviSynth.

I found that VFAPIconv does a [16,235] to [0,255] conversion. So this is the correct line to put at the end of the AviSynth script to compensate for that:

# scales a [0,255] clip to [16,235]:

Levels(0, 1, 255, 16, 235, coring=false)  # this is the same as ColorYUV(levels="PC->TV")

I did two x264 tests. One with "plain" settings as per our MeGUI/Handbrake YouTube and Vimeo uploads (but with 2-pass VBR 2Mbps) and one with "fancy" settings as per MeGUI's DXVA High-def. preset (but with 2-pass VBR 2Mbps).

I've zipped up the 6 mp4 files into a 17 MB download for anyone who's interested.

Here are the results:



I attempted to rank the quality in terms of detail but quality is not as simple as that so download the files and make your own mind up. Personally I would never use Sony AVC in Vegas Pro 10.0c at 2 Mbps for detailed/moving footage, and x264 is worth the extra effort for me over any of the bundled encoders.

Blur vs Interpolate vs Yadif-Vegas vs Yadif-AviSynth vs Mike-Crash vs QTGMC comparison on Stringer's driving clip at 1080i>1080p next...

Nick,

I don't have time to pursue this any further at this time. I uploaded one more time to YouTube, after first deleting my new upload. Once again, YouTube got the levels wrong on the first scene. Obviously it is some interaction between the video that MeGUI created and YouTube. So, it looks like I need to change some setting in MeGUI, but I don't have the time to play around with it. So, for the moment I can't use this workflow for YouTube. Bummer.

Oh, and yes I did mean that I serve into VirtualDub because that is how I initially test the script settings. When everything is working, I then serve into MeGUI (or second instance of Vegas, or whatever) to actually do the encoding.

Speaking of VirtualDub and AVISynth, I was going to post the AVISynth Levels script line you just posted. I use that all the time when I have the 235/255 0/15 levels issues.

I'll check in periodically to see if anyone has similar problems with YouTube and maybe that will give me a hint as to what to change in the MP4 MeGUI encode to get it to work.

I asked the question. You never know, someone who has encountered this before might get to see it before YouTube delete the video again.

It shouldn't be necessary but maybe it's a good idea to feed YouTube a bit of generated media at the start. A title or at least a bit of level-16 solid black before fading up.

Nick,

I didn't know you were going to post there, and didn't see your post. I also posted, with considerably more detail:

MeGUI support Post

After finding out about your post here, I went back and added a note at the end of my writing to inform everyone that our two posts are about the same subject.

It will be interesting to see if anyone replies. I do suspect that, since the levels revert back to the proper settings at exactly the scene change, that one of the GOP settings will turn out to be the answer. Note that I provided details of every change from the defaults.

I re-encoded using the default MeGUI settings, except for changing to Main Profile and constant quality. It was still screwed up.

I'm out of ideas for the moment.

Sorry for all the posts, but I finally found the problem. As I mentioned in an earlier post, I was leery of using the Nero AAC encoder because of problems I've had with Nero products in the past. What I didn't realize is that you don't have to use an installer and instead just have to copy a few files to the MeGUI folders. So, I installed the Nero AAC encoder, re-encoded the whole project, and uploaded to YouTube.

Everything works just fine.

So, the moral of the story is this: when Nick Hope writes a tutorial, follow it exactly and your life will be fine.

Did I mention somewhere how impressed I am with his tutorial?

Thanks again.

Dear Nick,

I'm curious: have you ever tested your workflow by letting Vegas deinterlace 1080i footage (via interpolation) but not letting Vegas scale to 720p?

A while back I ran some tests on Vegas' scaling, which suggested that V9 was visibly inferior to Photoshop CS5. I've heard that via bayer interpolation, 1080i is roughly equivalent to 720p in spacial resolution, so I wonder how much of your output gains are coming from AviSynth's scaling, versus its interpolation algorithm.

??

I've done this and what I've found is that Vegas's interpolate seems to use the same math in deinterlacing as it does in a times two resize (which makes sense if you think about it). Even worse on the upsize (doubling fields) than it is on the downsize (downrez to 720). I much prefer the Lancos 3 that is in Handbrake and the AVIsynth filters. They aren't perfect either though. I have a program called Photozoom Pro that lets you do even better looking resizes using some newer scaling algorithms that blow away Lancos 3. The difference in quality is striking. Way better in fact. The only problem is that you have to export as a picture sequence, batch resize the individual pictures, then reimport the sequence and rerender as a new avi. This of course takes oodles of time and hard disk space. None the less, it shows how much room for improvement in quality there is in the Lancos 3 algorithm used in Handbrake.

Interesting. Hadn't thought of it that way but it makes perfect sense that Vegas' interpolate deinterlace is using the same math...

Which would explain why external deinterlace tools are giving so much better results.

John, sorry for pre-empting your post on doom9. I got the idea you'd given up on it and I wanted them to take a look before your video got deleted by YouTube again.

I've changed my tutorial to advise people to steer clear of FAAC or LAME.

I have a nagging feeling that one of my uploads in the last couple of months had a corrupt first few frames on YouTube, but I can't find it now. So I'm a little worried by the talk of an incompatiblity between mp4box-muxed files and YouTube's mp4 demuxer (from the x264 developer himself). I'll keep that in mind and if anyone else gets problems I'll test and perhaps recommend mkv instead.

>> have you ever tested your workflow by letting Vegas deinterlace 1080i footage (via interpolation) but not letting Vegas scale to 720p? <<

Andy, I've never tried that. I believe that the external deinterlacers are giving us a big advantage in areas of moving footage. I'm going to run off some deinterlacing comparisons today at 1080i->1080p and post screengrabs which I expect will illustrate this.

There is definitely scope for experimenting with the resize algorithm. The AviSynth options are here. I did try Lanzos4. It's supposedly sharper but I didn't see a significant difference at 1080>720. It's better for upscaling though, apparently.

This article suggests that a simple bilinear resize might be a better idea than Lanczos3 at low bitrates, and following yesterday's tests I think they may have a point. The sharpness produced by Lanczos3 is probably helping the AVC codecs make a dog's dinner of the encode at 2Mbps.

That article also implies that spline16 or even spline36 downscaling might be a better/sharper option than Lanczos.

The S-spline algorithm in PhotoZoom Pro looks great for upscaling by a big factor.

>> Yes, I used 19.2. GSpot reports 3,580 kbps <<

This figure has just sunk into my brain and illustrates the huge variation in bitrates that constant quality can give. With your footage you're getting less than half the bitrate that I've been getting at crf 19.2 with the "busy" footage in our test project. It goes to show how much easier your type of footage is on the encoder. i.e. Tripod, less movement, plainer background.

I think it would be reasonable to drop the generally recommended crf to 19.0 or even less. I wouldn't go lower than 18.0 though.

Dear Laurence,

Could you please link us to the 64-bit recompile of Mike's deinterlacer you mentioned?

Thanks

Piotr

Piotr, There are 2 builds mentioned at the start of this thread.