Bren F
Do any of you guys think the videos at Smashvidz and 8thwonder could look better?
I especially think some of the work from 8thwonder should be encoded with higher settings..
geposted Sun 07 Sep 08 @ 2:20 pm
Andrew87
I downloaded the sample from smashvidz and have these criticisms:
The deinterlacing algorithm they used can be better.
They've wasted valuable bits encoding black borders. Always crop them.
They've used a non-standard (non mod-16) resolution, 620x480. A nice size for 4:3 videos after cropping is 640x480. 624x352 is common for 16:9 although 736x416 could be used too.
A 3:2 pulldown could be applied so that the framerate becomes 23.976 which will result in a better compression, although very few people may see a faint jittering.
There is only 1 reference frame used with the encoding. But processor requirements increase with more reference frames too, although I got away with using 3 which even played on my ipod with my encoding in the experienced forum.
No complaints with the audio. Not sure what encoder they used but I've found nero to be my favourite, although they don't allow commercial usage.
The deinterlacing algorithm they used can be better.
They've wasted valuable bits encoding black borders. Always crop them.
They've used a non-standard (non mod-16) resolution, 620x480. A nice size for 4:3 videos after cropping is 640x480. 624x352 is common for 16:9 although 736x416 could be used too.
A 3:2 pulldown could be applied so that the framerate becomes 23.976 which will result in a better compression, although very few people may see a faint jittering.
There is only 1 reference frame used with the encoding. But processor requirements increase with more reference frames too, although I got away with using 3 which even played on my ipod with my encoding in the experienced forum.
No complaints with the audio. Not sure what encoder they used but I've found nero to be my favourite, although they don't allow commercial usage.
geposted Sun 07 Sep 08 @ 4:13 pm
Bren F
Thanks for that informing answer Andrew.
geposted Sun 07 Sep 08 @ 4:28 pm
low-fat-al
Andrew87 wrote :
The deinterlacing algorithm they used can be better.
The deinterlacing algorithm they used can be better.
what do you suggest?
Andrew87 wrote :
They've wasted valuable bits encoding black borders. Always crop them.
They've wasted valuable bits encoding black borders. Always crop them.
I haven't found a program that allows you to batch auto crop... any suggestions for batch cropping/encoding?
There is only 1 reference frame used with the encoding. [/quote]
reference frame? do you mean GOP?
Anyone have a real good ideal formula for encoding to mp4/h.264?
geposted Sun 07 Sep 08 @ 8:01 pm
Andrew87
I usually use TomsMoComp for deinterlacing because it's quick, although there's a brilliant guide over at Doom 9 which describes the differences between a couple of algorithms. It also goes through IVTC (3:2 pulldown) although it's really aimed at manual encoding.
As for batch autocropping, I know that mencoder has the ability to detect cropping but I've not played about with it. There are a lot of programs which will detect the cropping and deinterlacing options for you. I use MeGUI for most of my X264 and AAC encodings, it gives good results and has a large variety of encoding profiles to suit everyones needs. I hear AutoMKV is very good too. However, I don't know if either program will automate everything, i.e. whether you can drag 100 videos in for example and simply queue them all up.
I'm not really sure about the exact meaning of GOP if I'm honest but increasing the number of reference frames can increase quality. The sample video uses the Baseline profile which doesn't aim to achieve maximum compression but rather maximize compatibility with decent compression.
I encoded a sample here which also uses the baseline profile although was from a progressive source.
As for batch autocropping, I know that mencoder has the ability to detect cropping but I've not played about with it. There are a lot of programs which will detect the cropping and deinterlacing options for you. I use MeGUI for most of my X264 and AAC encodings, it gives good results and has a large variety of encoding profiles to suit everyones needs. I hear AutoMKV is very good too. However, I don't know if either program will automate everything, i.e. whether you can drag 100 videos in for example and simply queue them all up.
I'm not really sure about the exact meaning of GOP if I'm honest but increasing the number of reference frames can increase quality. The sample video uses the Baseline profile which doesn't aim to achieve maximum compression but rather maximize compatibility with decent compression.
I encoded a sample here which also uses the baseline profile although was from a progressive source.
geposted Sun 07 Sep 08 @ 8:56 pm
It's refreshing to see someone who knows what they're talking about! However, you mean standard FILM based video is 23.976, such as most feature films, primetime TV series and major label music videos. Non film-based video is 29.97 frames per second/59.94 fields per second.
"Lossless" h.264 is possible with a CRF=100. But you are absolutely correct, anything below is still a generation loss and lossy. I would imagine file sized of h.264 with a crf of 100 would be around file sized of HuffYUV, Logarith and other lossless codecs.
As long as the black borders are "clean" (pure black, no noise), the amount bits allocated to these areas are minuscule and do not have a noticeable impact of file size or quality. Smashvidz encodes their content at the standard 4:3 square pixel resolution of 640x480, which is a mod16 resolution. Also, h.264 allows for mod8 and mod4, so its quite possible to use 640x360 for 16:9 1.78 content. 736x416 would be upscaling video is your source is SD and should be avoided. I would imagine letterboxiing is not cropped due to VDJ's behavior with different aspect ratios, that is, it always stretches the video to a 4:3 aspect ratio, at least in my tests. Perhaps there is a way around that?
I can confirm that newer videos on SV do in fact use 3:2 pulldown removal and are at 23.976. They look much better than ones that are simply deinterlaced.
"Lossless" h.264 is possible with a CRF=100. But you are absolutely correct, anything below is still a generation loss and lossy. I would imagine file sized of h.264 with a crf of 100 would be around file sized of HuffYUV, Logarith and other lossless codecs.
As long as the black borders are "clean" (pure black, no noise), the amount bits allocated to these areas are minuscule and do not have a noticeable impact of file size or quality. Smashvidz encodes their content at the standard 4:3 square pixel resolution of 640x480, which is a mod16 resolution. Also, h.264 allows for mod8 and mod4, so its quite possible to use 640x360 for 16:9 1.78 content. 736x416 would be upscaling video is your source is SD and should be avoided. I would imagine letterboxiing is not cropped due to VDJ's behavior with different aspect ratios, that is, it always stretches the video to a 4:3 aspect ratio, at least in my tests. Perhaps there is a way around that?
I can confirm that newer videos on SV do in fact use 3:2 pulldown removal and are at 23.976. They look much better than ones that are simply deinterlaced.
geposted Sun 12 Oct 08 @ 2:25 am
funkturnal
Andrew I'm curious to know if you found a way to use active picture videos (black borders cropped) in vdj & it displaying them correctly?
that would be some great news.
that would be some great news.
geposted Sun 12 Oct 08 @ 3:30 pm
dj-e-lectric
dj_czar wrote :
It's refreshing to see someone who knows what they're talking about! However, you mean standard FILM based video is 23.976, such as most feature films, primetime TV series and major label music videos. Non film-based video is 29.97 frames per second/59.94 fields per second.
"Lossless" h.264 is possible with a CRF=100. But you are absolutely correct, anything below is still a generation loss and lossy. I would imagine file sized of h.264 with a crf of 100 would be around file sized of HuffYUV, Logarith and other lossless codecs.
"Lossless" h.264 is possible with a CRF=100. But you are absolutely correct, anything below is still a generation loss and lossy. I would imagine file sized of h.264 with a crf of 100 would be around file sized of HuffYUV, Logarith and other lossless codecs.
You are absolutely correct technically, what I meant that 7000kbs was no loss of quality was compared to the usuall "highest quality" standard setting to rip to mpeg2 of most software ripping programs I have experienced. In fact a 7000kbs h264 rip is a smaller file size than a 7000kbs mpeg2 rip due to the way mp4 packages it vs mpeg2 and the video quality is considered superior to the mpeg2 as is the AAC audio standard with h264 vs the mp3 audio standard with mp3.
The question I have with resolutions is where does the 720x480 fit in to all this because most ripping or converting programs using h264 rip to 720x480 resolution which was explained to me as the standard of the Sony Digital Video used for broadcast cameras like they use for live sporting events and news shows (at least here in the US). This is the resolution I use on all my rips and they look great on the LCD and Plasmas at all the clubs I play.
geposted Mon 13 Oct 08 @ 7:48 am
720x480 is a derivative of the Rec. 601 (formally CCIR 601, http://en.wikipedia.org/wiki/CCIR_601) NTSC resolution of 720x486. It was adopted for use by miniDV cameras and DVD due to is even divisibility by 16 (since MPEG-2 uses 16x16 macroblocks, a mod16 resolution can be most efficiently compressed.) This format was first used by the Sony D-1 format (http://en.wikipedia.org/wiki/D1_(Sony)), which is probably where you got your info from.
720x480 does not use square pixels and allows contains 16 pixels of padding (those thin black borders you often see on the left and right), so if you're encoding straight to 720x480 without any kind of flags, your video is distorted at playback. The correct way to "convert" 720x480 to square pixels is to crop off 8 pixels off each side (http://en.wikipedia.org/wiki/Nominal_analogue_blanking) and then resize to 640x480. You can also encode at 704x480 after cropping by using the PAR (pixel aspect ratio) of 10:11. Software like YAMB/mp4box allow you to modify the PAR (http://en.wikipedia.org/wiki/Pixel_aspect_ratio) of a mpeg4/h.264 stream. My prefered method is the latter, since the less you resize, the best your encode will look.
720x480 does not use square pixels and allows contains 16 pixels of padding (those thin black borders you often see on the left and right), so if you're encoding straight to 720x480 without any kind of flags, your video is distorted at playback. The correct way to "convert" 720x480 to square pixels is to crop off 8 pixels off each side (http://en.wikipedia.org/wiki/Nominal_analogue_blanking) and then resize to 640x480. You can also encode at 704x480 after cropping by using the PAR (pixel aspect ratio) of 10:11. Software like YAMB/mp4box allow you to modify the PAR (http://en.wikipedia.org/wiki/Pixel_aspect_ratio) of a mpeg4/h.264 stream. My prefered method is the latter, since the less you resize, the best your encode will look.
geposted Mon 13 Oct 08 @ 6:14 pm
djrenee
I keep reading these responses over and over trying to see if my head will EXPLODE.
geposted Mon 13 Oct 08 @ 8:06 pm
funkturnal
what your seeing is the real deal in video knowledge!!
geposted Tue 14 Oct 08 @ 12:14 am
dj-e-lectric
Czar, you must do this for a living...thanks for the explaination/correction....only 16 pixels distortion on a 42" tv....not worth the bother to reencode in my opinion.
geposted Wed 15 Oct 08 @ 5:23 am