AviSynth to MP4, easy direct way?

[EmielBoss]

After capturing Hi8 tapes as HuffYUV AVIs, I am now in the restoration phase, using VirtualDub and AviSynth. Is it at all possible to have VirtualDub/AviSynth output MPEG 4:2:2 MP4s? This thread seems to suggest so, but I don't think VirtualDub offers this option. Does this mean that after restoring and saving to a second lossless working file (again HuffYUV?), I should re-encode to get an MP4? (If so, how? FFmpeg? Handbrake? Something else?) Or is it possible to simply move the video stream to an MP4 container or something like that?

[lordsmurf]

VirtualDub2 can, using the x264vfw encoder, but it's not great.
VirtualDub can too, actually, if manually installing x264vfw (not much to it). But again, not great for encoding.

Ideally, yes, output lossless, and let Hybrid encode to x264 with high quality.

[keaton]

This thread http://www.digitalfaq.com/forum/vide...html#post68523 shows a sample ffmpeg command line for 4:2:2 H.264 (mp4), if you are only looking for an x264 encoder and not looking for all the other things that come with Hybrid.

I've used ffmpeg's libx264 encoder a bit lately after deinterlacing some video in Avisynth with QTGMC and saving to HuffYUV or Lagarith 4:2:2 AVI.

The crf option is a number which has higher quality the lower the number. It's a variable bitrate preset, as opposed to setting a fixed bitrate. If you use crf option, I've read that 16 is about as low as you can go and still see a difference. That's been my anecdotal experience as well with the bit of video I've processed lately. The example in the link above goes with crf of 10, which will generate much higher file size. I encourage you to try and find out for yourself what you think is good enough. If you try 10, then 12, then 14, then 16. You'll notice quite a drop in filesize and bit rate. Coming from MPEG-2, however, where I see how important a high bitrate is, I'm quite surprised at how much less bitrate can be used for H.264 without a noticeable drop in quality.

Another thing to consider is whether to input a 720 x 480 NTSC video to the encoder and set the SAR value so that the player is told to play that in a 4:3 aspect ratio (640 x 480) (which is how it works for say DVD MPEG-2), or if you'd rather not rely on the players to use SAR correctly and just adjust the video to 640 x 480 and have a SAR of 1:1 so that no matter where you play it, the video will be correct aspect ratio. The example thread referenced above is using the SAR to try and tell the player to resize the pixels so it fits in a 640 x 480 resolution, but keeping the video file itself at 720 x 480. It says divide 720 by 9, then multiply by 8, resulting in 640.

For all the various players out there, you may find that you cannot rely on every player to use the SAR at all or to use it correctly. If you find a player you use either leaves it stretched out at 720 x 480 or if you see a player such as VLC (which I use a lot) use the SAR to display your 720 x 480 as 720 x 540 to get a 4:3, and you expect 640 x 480, then the only way to thwart that is to resize the video yourself to 640 x 480.

Lots of threads around for how to correctly resize from 720x480 to 640x480. In avisynth, basically crop the video by 8 pixels on each side, i.e. crop(8,0,-8,0), to make it 704 x 480, then use Spline36Resize(640,480). The reason for cropping to 704 is for a cleaner resize calculation. Dividing 704 by 11 is 64, then multiply by 10 to get 640. No analog video capture I've ever seen has a full 720 anyway. Although, it may not be centered perfectly. So, for example, if you have no blank pixels on the left side, but blank pixels on the right side, it could be better to call crop(0,0,-16,0) instead, or whatever combination of the 1st and 3rd values to crop that work out best and add up to 16 to not remove anymore video than expected. Of course, I also get rid of things on the bottom edge like head switching noise. In that case I would also crop, but add a border back in to create the 704 x 480 video. So, for example, if I had 8 pixels worth of head switching on the bottom, and all the blank pixels are on the right edge, I'd do crop(0,0,-16,-8).AddBorders(0,4,0,4). The AddBorders re-centers things horizontally so that I add 4 rows of black pixels on top and 4 on bottom to account for the 8 rows of pixels I cropped off the bottom (still keeping the 480 rows in the frame).

If you go the route of resizing to 640x480, you can still set the sar value to 1 when passing to ffmpeg.

Borrowing from the referenced thread above, it may look something like this for a CRF of 16 and a 640x480 avi input file

ffmpeg -i video.avi -vf "format=yuv422p,setsar=sar=1" -c:v libx264 -crf 16 -x264opts colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m -c:a aac -b:a 192k output.mp4

The -b:a is the bitrate for the AAC audio encode. I think that can go as low as 128k or high as 384k, but not 100% on that. Although, the high end like 384k is said to be for 5.1 surround (64k per channel). For 2 channel stereo, you're most likely using a range between 128 and 256k. AAC is also better than mp3, so I had to recalibrate myself to that. Experiment with audio bitrates as well to see what you think is enough. But, just as with the x264 video bitrate, I found that aac preserves a lot more quality with a lot fewer bits than I would have thought.

The smpte170m options refer to the color domain of analog video. It's another setting that video players can use to indicate that this video is from the analog NTSC color domain when converting things to say a digital HD color domain.

Best of luck to you.

Edit: Sorry. I didn't notice until now you are from PAL land. Sorry for that. Trying to think on my feet now as to what's different for PAL vs NTSC for a resize. Not having done PAL, it's probably better for me not to guess. There's a lot of discussions on the forum about this sort of thing, I'm sure. Hopefully this reply still gives you enough to communicate the ideas and key points if you need to do different calculations for PAL resolutions. Perhaps 640 x 480 is still the goal for PAL. But it's probably best for me to not try to talk about something I'm not familiar with and hope others who do know can help.

And a quick search took me here https://video.stackexchange.com/ques...ng-unspecified and tells me that PAL is bt470bg instead of smpte170m.

[keaton]

After a good night's sleep and a bit of review. I assume you are capturing at 720 x 576 for PAL. If so, the same idea of cropping a total of 16 pixels off the left and right edges to create 704 x 576 should be what you'd want. Then you would use Spline36Resize(768,576). This should be clean for resize. 704 / 11 = 64, then multiply 64 * 12 = 768. And 768 x 576 is a 4:3 aspect ratio. Similarly, if you didn't want to resize, but use a SAR, I would think you'd pass a 704 x 576 video and set the sar to 12/11 to get 768 x 576 (4:3).

I suppose you could try to resize to 640 x 480 still, because 576 could be cleanly resized that way by dividing 576 by 12 then multiplying by 10. I guess it's all PC domain now anyway, so I guess NTSC and PAL are no longer valid there. But if you watched on a TV, I'd guess you still have the 576 row resolution and not a 480 row resolution. Also, the less resizing the better. I'd guess staying with 576 rows is the way to go for PAL.

Anyone please feel free to correct me. I've never done PAL. I'm just extrapolating from my NTSC experience and making what seems like sound advice.

[EmielBoss]

Thanks for all the info, keaton!

Quote:

This thread Keeping 4:2:2 all the way to final encode? shows a sample ffmpeg command line for 4:2:2 H.264 (mp4), if you are only looking for an x264 encoder and not looking for all the other things that come with Hybrid.

Now I have a hard time deciding between FFmpeg and Hybrid. I don't think my captures need much work besides deinterlacing and a lil bit of cropping and masking, which I think can all be done in Hybrid. FFmpeg does look much easier, however. Do you think it makes much of a difference in terms of quality (like, does Hybrid use an older version of QTGMC or something)? Hybrid does support chapter metadata, which is more of a hassle in FFmpeg as far as I've tinkered around.

Quote:

I assume you are capturing at 720 x 576 for PAL.

That's true.

Quote:

If so, the same idea of cropping a total of 16 pixels off the left and right edges to create 704 x 576 should be what you'd want. Then you would use Spline36Resize(768,576). This should be clean for resize.

The whole resizing part is going a bit over my head. What's the downside of having a 5:4 aspect ratio? (I'll be mainly playing the results on PCs, iPads, etc. Don't think I'll ever burn them to DVD or something like that.) I assume some players want 4:3 and then stretch the image? Because, yeah, I don't want that :')

I have considered enlarging the actual video content to cover the whole video resolution to get rid of the black borders, but some posts dissuaded me from doing that, because — as you indicate yourself — resizing should ideally be avoided. But with the black borders, I can do small changes to the aspect ratio without resizing the actual content.

As a last question, I think I only want to deinterlace and mask/crop, but do you think my captures could use more work besides that? Here's a sample.

Many thanks again!

[lordsmurf]

The general rule is to never upsize, so
PAL = 720x540
NTSC = 640x480

Upsize artifacts are worse than downsize.

In fact, the best upsize it 2x-4x, then re-downsize. So, technically, when you upsize VHS (for a non-stupid reason, ie documentary sources), for the 1080p deinterlaced, you process (sharpen, color correct, etc) at 2K or 4K, for best quality. But almost nobody does that (not even me), because the gains of up+down are slight, when using the best current methods. Slight, but present. For some restorations, however, essential.

[keaton]

Thanks for the feedback, lordsmurf, on not upsizing to 768 from 720.

EmielBoss, the reply about choosing between ffmpeg or Hybrid seems to confuse things a bit. I've never used Hybrid, only know what I hear and see on the website. But it's a replacement for having to use Avisynth for things such as QTGMC, and possibly ffmpeg. I say possibly ffmpeg, because perhaps it can output the same lossless AVI without using ffmpeg to encode to a lossless format like mp4, and you could still use ffmpeg separately if you choose for some reason. But ffmpeg is not a deinterlacer, QTGMC is a deinterlacer. I have heard there may be ways to encode interlaced video with libx264, but I have no experience with that. So, you either have to choose between Hybrid or using Avisynth to deinterlace with QTGMC.

I stick with Avisynth because I'm a software guy and so I have an aptitude for scripting, and prefer to know exactly what is being done to the video and when. I totally understand those that don't want to get bogged down with that and prefer a GUI. Seems like that's what you would be leaning towards.

Resizing is only involved if you find the players you are using are not using the aspect ratio settings you specify for your encoded video. Outside of physical formats such as DVD or Blu-Ray, which would honor aspect ratio data, it is much harder to guarantee that all software players out there are going to use this data to render the video in correct 4:3 aspect ratio. So, that's why I tend to favor resizing the file and setting aspect ratio data to 1:1. Even if I don't have issues now, I cannot guarantee I won't encounter it some day with another player. It's the fault of a lack of standardization compliance for all the media player apps out there. Another thought is that some players may not be the best at resizing the video. Were as, I know that Spline36Resize does a good job of resizing things without creating distracting video issues. I'd rather have it "baked in" as good than to hope another player will do as good of a job with it. I don't know if a resize is available in Hybrid. If not, and you want to do so, you could use a simple Avisynth script to call Spline36Resize. Example scripts are out there on the forum. Load that .avs script file into say Virtualdub and save it back to a lossless AVI file. Then, you could use Hybrid to do the rest.

The downside of an aspect ratio greater than 4:3 (1.33), such as 3:2 (1.5) is things are more stretched out horizontally. Objects are wider than they should appear. The downside of an aspect ratio smaller than 4:3, such as 5:4 (1.25) is things are more compressed horizontally. Things are narrower than they should be. 5:4 is much closer to 4:3 than 3:2, so maybe you wouldn't notice. But if you want it be the same as the original source material, you want 4:3.

I would agree with those that dissuaded you from resizing so that there are no borders or just cropping and not adding back a small border to keep the correct dimensions. Just my choice. I don't want to find out later that I introduced something distracting or noticeably wrong by resizing a small amount or by having a file that doesn't follow a standard set of dimensions. I'd prefer to keep a small and barely noticeable border around the video. But, you are free to do whatever. You would not be the only one to have a video with a few rows less than 540 and/or a few columns less than 720. I suppose in the PC world, it really doesn't matter. I think those that follow a stricter policy believe in compliance to standards and are trying to avoid potential issues by not following those. The final judge is you and your potential audience.

Your video sample is pretty clean. Don't see anything distracting that I would spend time fixing. QTGMC would do a fair amount of cleaning as a bonus when you deinterlace. The YUV histogram shows it stays within 16 to 235 range.

One comment is the color is pretty "hot" when viewed on a Vectorscope. If you haven't already, get Virtualdub 1.9.11 + Filters pack http://www.digitalfaq.com/forum/atta...dub-11-filters and also be sure to get the ColorTools Virtualdub filter. If it's not in the pack, you can get it here http://www.trevlac.us/colorCorrection/colorTools.html Copy the clrtools.vdf file into the Virtualdub Plugins folder, then open this video sample in Virtualdub. Go to Video Menu, select Filters, and pick Color Tools, then select the Vectorscope option for that tool and click OK. As you play the video, you'll see in the vectorscope in the right window that the color is going out of gamut (past the boxes marked with R and Y). Those boxes show the limits of valid colors. There's a couple different ways I fixed this with a single call in Avisynth. Either try ColorYUV(cont_u=-50, cont_v=-50), which reduces the U (Blue and Yellow) and V (Green and Magenta) color channels in the YUV color space, or call Tweak(sat=0.8) (this cuts saturation to 80% of the original). Again, I haven't used Hybrid. So I don't know if either of these built-in Avisynth functions is available to you there. But they can be used in a simple Avisynth script file (.avs). Search on ColorYUV or Tweak on avisynth.nl or this forum for plenty of info on those.

[EmielBoss]

Many thanks for your efforts in teaching me, keaton! Apologies for the late reply; I only sporadically have time for this project. I read through your posts thoroughly, and now I think I get it.

Quote:

Originally Posted by keaton

I stick with Avisynth because I'm a software guy and so I have an aptitude for scripting, and prefer to know exactly what is being done to the video and when. I totally understand those that don't want to get bogged down with that and prefer a GUI. Seems like that's what you would be leaning towards.

I've experimented with Hybrid for a bit, and I honestly think Hybrid's GUI is way too convoluted and messy to be considered much easier to use than a straightforward script. And while it seems very transparent in the actual commands that it calls, I think I'd rather build those up myself. So I want to try AviSynth + FFmpeg and compare that with Hybrid's output.

Quote:

Originally Posted by keaton

So, that's why I tend to favor resizing the file and setting aspect ratio data to 1:1. Even if I don't have issues now, I cannot guarantee I won't encounter it some day with another player. It's the fault of a lack of standardization compliance for all the media player apps out there. Another thought is that some players may not be the best at resizing the video.

Yeah, I want my end files to be universally playable as well (VLC, iPads, consoles, streaming, etc. But I'm not burning them to DVD/Blu-ray); MP4 with chapters, deinterlaced and in 4:3 SAR.

Quote:

Originally Posted by keaton

The reason for cropping to 704 is for a cleaner resize calculation. Dividing 704 by 11 is 64, then multiply by 10 to get 640.

Quote:

Originally Posted by keaton

because 576 could be cleanly resized that way by dividing 576 by 12 then multiplying by 10.

I assume a "clean resize" means that the intermediate dimension (576 divided by 12) is an integer?

Quote:

Originally Posted by keaton

I assume you are capturing at 720 x 576 for PAL. If so, the same idea of cropping a total of 16 pixels off the left and right edges to create 704 x 576 should be what you'd want. Then you would use Spline36Resize(768,576). This should be clean for resize. 704 / 11 = 64, then multiply 64 * 12 = 768.

Quote:

Originally Posted by mjb2019

For PAL content in a 720×576 frame, you'll want to resize to 768×576. You might want to take into account whether the capture includes horizontal blanking—black stripes down the left and right sides—which is outside of the intended 4:3 picture area. Standard procedure in your workflow, when this is present, is to crop to 704 wide (e.g. 8 pixels off of each side) before resizing the remainder to a width of 640 (NTSC) or 768 (PAL).

Quote:

Originally Posted by lordsmurf

I do find 720x540 is much better, that 720>768 incur minor quality loss from upsizing.

So I can choose between 768×576 and 720x540 to get a 4:3 SAR, but because upsizing sucks I'd better go for 720x540. But in that case, what should I do in terms of cropping? I would say that I leave the horizontal resolution entirely as it is; because my captures are already 720 wide, I should NOT crop the 8 bits from the sides, because than I would have to still upsize the 704 video to 720 again. Does this mean that I can instead crop 8 of the top and bottom (giving me 560 vertical resolution), divide that by 28 (which is an integer) and multiply that by 27 to get 540 vertical resolution? Does this make sense, or is this a bad idea?

Would you mind sharing your AviSynth script with me, as a starting point?