Suppose there is a 4:3 video, that is 720x480, non-square pixels. And that at the left side of the frame, there is a vertical black bar that has a width of 10 pixels. And at the right side of the frame, a vertical black bar that has a width of 10 pixels.
What would happen if I encode it with x264, without cropping those black bars, so that I can set the mkv container to 4:3, so that I won't have to resize to reduce the resolution until an aspect ratio close to 4:3 is reached ? Will it reduce the visual quality for the same CRF value ? Will it require more bitrate which will increase file size ? Or both ?
+ Reply to Thread
Results 1 to 14 of 14
Last edited by codemaster; 17th Dec 2014 at 19:06.
The black bars aren't going to eat up a whole lot of bitrate themselves, but any re-encode entails a loss of quality. Is that what you're asking?
Source is mpeg2, ntsc, 30i. If video editing is not required, maybe it would be better to not decode it to lossless, deinterlace with qtgmc at 60p, and encode it to h264. However, the video player cannot deinterlace in real time... as good as qtgmc can. So, in this case, a re-encode could potentially be an improvement to visual quality (but only if the black bars don't reduce visual quality somehow, by somehow lowering x264's performance at motion detection or prediction). An additional problem is the non-square pixels thing. Some players will ignore the aspect ratio in a mkv container. Some video players don't ignore it, but they modify the aspect ratio of the font used for subtitles. Cropping and resizing to square pixels and proper aspect ratio, cuts so much from input resolution, that the output looks less sharp than the input. It seems maximum quality would result from deinterlacing with qtgmc at 60p, not resizing, not cropping, and setting mkv to 4:3.
Last edited by codemaster; 17th Dec 2014 at 19:46.
First question would be:
Why do you need to convert this to H264?
Most 4:3 DVD video would use an ITU aspect ratio. That means, instead of 720x480 being resized to 4:3, 704x480 is resized to 4:3. There's 8 pixels each side that don't count as part of the 4:3 aspect ratio.
Or to put it another way, if you didn't crop the black bars the aspect ratio of the 720x480 would need to be a bit wider than 4:3. It's 1.3656:1 for NTSC. According to the resize calculator I use, if you didn't crop the black bars you'd set the aspect ratio in the MKV to 103545/75824.
If it was me, I'd probably crop 10 pixels from each side and 2 pixels from either the top or the bottom. The remaining video would have an aspect ratio of 4:3 (give or take 0.01%).
It's an exe, but it's safe if you want to have a play. It's designed for calculating resizing to square pixels, but you can ignore the resizing and use the displayed Matroska aspect ratio instead. YodaResizeCalculator
If you're asking about the effect of black borders on encoding efficiency, clean ones don't cost much in terms of bitrate. So if you are encoding using CRF rate control, the filesize won't be much different. However if the borders are noisy, with ratty edges, then it can make a more significant difference if you leave them in
That's a 2.2% difference, which is likely imperceptible to >90% of humans.
(by comparison, NTSC & PAL non-square pixels seen as square exhibit a ~9.8% difference)
If you plan on already converting to h264 and deint with QTGMC (AVISynth...), etc, you could also instead of cropping just do an overlay of new black on top of the old black, without resizing, so you know for sure that the look you had is the look you will have (AR-wise).
You could also just crop and encode to 704x480 and be done with it (leaving 2 pixels of black on each side, using the same overaly idea).
Even when de-interlacing with QTGMC I'd still be inclined to crop while setting the correct aspect ratio for the remaining video, although I tend to crop the crud, then crop a little picture here and there if need be to take me back to exactly 4:3, but that's just my OCD way of doing it.
I'd disagree resizing to square pixels necessarily makes the video look less sharp. After de-interlacing with QTGMC I often resize to 640x480 (both NTSC and PAL) and that's a fair reduction from the original PAL 720x576 resolution, but mostly the 640x480 version looks a tad sharper running full screen on my TV. It'd probably also depend on the resizer used and how sharp it is.
I did some experimenting a while back, encoding video, adding black borders, encoding it again etc. I think the presence of black borders can have slight effect on how the picture itself is encoded but it's very, very, marginal (slightly lower bitrate for a CRF value when the bitrate required to encode the borders themselves is factored in). Nothing you'd worry about when deciding whether or not to crop.
The encoding I did was adding borders with nice clean edges to the picture. Normal DVD borders, which are often not very sharp, might effect the bitrate a little more.
Last edited by hello_hello; 17th Dec 2014 at 20:14.
Don't know about MPC-HC, so you are saying it has a bad deinterlacer?
Sorry but it sound to me you made up your mind to convert this to H264 and you are trying to find arguments to justify it.
Sometimes the best solution is the simplest solution: just keep it in MPEG-2.
MPC-HC's mpeg2 de-interlacing was so bad at one stage I used to disable it's mpeg2 decoder and get ffdshow to do the decoding instead. The MPC-HC decoder didn't seem to pass the interlaced flag along correctly when it's de-interlacing was disabled either.
These days, after the switch to LAV filters, I think it's a lot better, but it's still not as good as QTGMC. Most real time de-interlacing seems to be Yadif type quality.
this post. They were originally made to compare Yadif and QTGMC de-interlacing at 25fps and 50fps. The original video is also included. If you can de-interlace it on playback and it looks as good as QTGMC at 50fps, please share your de-interlacing method. The QTGMC 50fps de-interlaced sample was resized to 640x480 and it still looks better than the original 720x576 video being de-interlaced on playback to me.
Or try the samples attached to this post and de-interlace the text while playing the original video, then compare it to the QTGMC sample at 50fps. I suspect the difference will be fairly obvious.
Last edited by hello_hello; 17th Dec 2014 at 20:40.
Yes, the main reason for wanting to re-encode to h264, rather than keep the original mpeg2, is superior deinterlacing with qtgmc.
I now realize that although resizing to 640x480 cuts 64 pixels from width, at least it solves 4 problems:
- square pixels, so proper aspect ratio on all players, including video players that ignore aspect ratio in mkv's containing non-square pixels video;
- proper aspect ratio for font used for text-based subtitles;
- i can resize after I crop the black borders; therefore I can resize, which not only enables me to maintain proper aspect ratio, but it also enables me to exclude all black borders;
- superior deinterlacing using qtgmc; real-time deinterlacers bypassed.
Last edited by codemaster; 17th Dec 2014 at 21:34.
x264 encoder is generally transparent enough for any filtering that improves the video quality not to be be negated by the fact it's being re-encoded. QTGMC's de-interlacing improves the video quite a bit compared to standard de-interlacing, and these days it's got to be de-interlaced sometime.
QTGMC in progressive mode can also be very good for stabilising the picture and/or removing noise. I use it that way as a noise filter quite a bit.
But take a look at the samples I linked to. I think the QTGMC de-interlaced and re-encoded version looks better than the original interlaced mpeg2 video. Let me know if you disagree.