digitalFAQ.com Forum

digitalFAQ.com Forum (http://www.digitalfaq.com/forum/)
-   Encode, Convert for streaming (http://www.digitalfaq.com/forum/video-web/)
-   -   AviSynth to MP4, easy direct way? (http://www.digitalfaq.com/forum/video-web/11380-avisynth-mp4-easy.html)

EmielBoss 01-12-2021 03:34 PM

AviSynth to MP4, easy direct way?
 
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 01-12-2021 03:39 PM

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 01-12-2021 11:08 PM

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
Code:

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 01-13-2021 08:30 AM

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 01-13-2021 09:37 AM

Thanks for all the info, keaton! :D

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 01-13-2021 02:37 PM

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 01-13-2021 08:38 PM

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.


All times are GMT -5. The time now is 05:48 AM

Site design, images and content © 2002-2021 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2021 Jelsoft Enterprises Ltd.