15 fps is about where you start getting the illusion of continuous motion. It does not look perfectly smooth. Flicker can be very obvious at 24, 25 or 30 fps. Even at 50 or 60 fps it's slightly noticeable with very high contrast material.
Download the 60 fps video in the following post and watch it full screen on a 60 Hz monitor. You'll see that the 30 Hz row (second row) flickers very noticeably. Motion of the bottom row should be very smooth.
https://forum.videohelp.com/threads/307004-Best-framerate-conversion-%28eg-23-97-to-30-...=1#post1888926
If your monitor is running at 50 Hz slow the video to 50 Hz with AviFrate and you'll see the second row flickers terribly at 25 Hz.
Make yourself a video that alternates between black and white frames at 50 Hz or 60 Hz. You'll be blown out of the room by the flicker.
Professional film makers (24 fps) know this and use motion blur whenever possible to reduce the problem. They also try to avoid high contrast during smooth motion scenes.
+ Reply to Thread
Results 31 to 46 of 46
-
-
Sorry didnt notice you responded, it was on page 2 for me, ill take a peek at what you just wrote up there, and there is some edits you may have not seen on my last post. Thanks.
wow thats super good to know, now i have a bigger picture of what i know about framerate (i used to be a cctv guy, and know alot about dvr and other cctv fps needs), this is helpful. Ive been working on getting a synced capture lately (vhs vdub) so ive been needing to make alot of fps decitions, as i archive off the last dozen vhs tapes i have over here.
I was wondering yesterday when adjusting the sync rate on my hdtv yesterday when playing one of these sourecs across the NAS, is 59HZ correct for a 720p visio, or should i run that at 60hz? and yeah, i guess from what your saying 25 vs 29.97 no difference on flicker of bad video, and using motion blur is the answer for that.
Motion blur, telecine?
so for example if i had a shitty flickering source, i would add a motion blur filter to reduce the flicker then? Well i can stick with 25fps to keep the filesize down atleast then, when applicable too.Last edited by wolfdogg; 19th Dec 2016 at 22:56.
-
The player adding black bars to just one side on playback seems a bit odd. The likely causes are auto-cropping isn't cropping all the black on one side (it'd pay to use Handbrake's preview to check) or there's a player setting causing it. I know VLC has options for centring the video but I don't use VLC myself. Maybe try one of the problem videos fullscreen with another player (ie MPC-HC) to see if anything changes.
Keep in mind the amount of cropping required can change throughout. In fact for older DVDs it generally does, so you might need to crop a little picture in one section to crop all the black in another. There's no reason why you can't crop all the black though. I always do. There's an occasional movie with more than one aspect ratio, such as one of the Batman movies which was mostly around 2.40:1, but the parts shot with Imax cameras were 1.7777:1. You'd have to choose between cropping the black and therefore cropping the Imax parts to 2.40, removing a fair bit of picture top and bottom, or not cropping at all and keeping the black. That sort of thing isn't overly common though.
I assumed you were living in PAL land as the video you asked about earlier is PAL, but as far as using the resize calculator goes, the theory would be the same for an NTSC source. If the source is very close to 16:9 or 4:3 I'd auto-crop, then adjust the cropping a bit more if required to make it 4:3 or 16:9 again.
There's many factors involved but one of the good things about CRTs and interlaced video was it worked in a way similar to how our eyes and brain work. They retain an image for a short period which is why you can be fooled into seeing movement when viewing a succession of still pictures. The phosphors in a CRT tube emit light when excited by an electron beam, which runs across the tube drawing one line at a time, and the phosphors take a short period of time to dim.... apparently it matches the way our eyes and brains work better than the way LCDs display video. They (in theory) should instantaneously switch from displaying one frame to the next, and when there's movement the "sample and hold" effect can cause motion to blur more as it doesn't match the way our eyes track movement. The only real fix is higher frame rates.
When 24fps film is displayed on a screen the projector flashes each frame at least twice, probably three times, otherwise 24fps would appear to "flicker". Even so, 24fps isn't fast enough for perfectly smooth motion and can result in a strobing effect when the camera pans at a particular speed. The "wagon wheel effect" is also caused by the low frame rate of film (where a turning object appears to turn at the wrong speed or in the wrong direction).
Anyway..... x264 is frame rate aware. I've tested it quite a few times when de-interlacing with QTGMC, and if I de-interlace to 25fps, and again to 50fps, and encode both using the same CRF value, the bitrate difference is only something like 5% or 10% from memory. Lossy encoding involves tracking and encoding the difference between frames. The lower the frame rate, the greater the difference when there's movement.
First I decide whether or not to use anamorphic encoding. It's personal preference although for me the answer is "no" these days because a couple of players here don't support anamorphic MP4s or MKVs so I always resize to square pixels.
I'd check several episodes, work out how much cropping they require, and how much it varies from episode to episode.
I'd then decide on a resolution to use for resizing, possibly based on the average cropping to keep resizing to a minimum.
To help explain....
Pixel Aspect Ratio x Storage Aspect Ratio = Display Aspect Ratio (Storage Aspect ratio is another name for Resolution).
So for an NTSC 16:9 DVD that's (32/27) x (720/480) = 1.7777 (16:9).
Based on that formula if you change one value you must change at least one other accordingly so as not to distort the picture.
Cropping on it's own doesn't change the pixel aspect ratio, it only changes the number of pixels (Storage Aspect Ratio). Therefore it must change the Display Aspect Ratio. Cropping 16 pixels from the width as an example:
(32/27) x (704/480) = 1.738
Resizing changes the storage aspect ratio (unless you resize the width and height by the same percentage). As a rule you don't want resizing to change the display aspect ratio, as that'd distort the picture. Therefore, the pixel aspect ratio is adjusted instead. The most common example of that would be resizing to square pixel dimensions. The pixel aspect ratio changes from 32:27 to 1:1.
Handbrake's Anamorphic Strict disables resizing, so cropping will change the display aspect ratio unless you crop to maintain the original storage aspect ratio. That's what I aim for, so if a 16:9 NTSC DVD required cropping 8 pixels each side to remove the black, I'd then crop an extra two pixels from one side and 6 pixels from both the top and bottom.
(32/27) x (702/468) = 1.7777
Handbrake will set the correct pixel aspect ratio when encoding.
Anamorphic None resizes to square pixels so after cropping it assumes the storage aspect ratio and display aspect ratio should be the same. If you want to resize to exact 16:9 or 4:3 dimensions, you'll probably have to adjust the cropping manually.
The old version of Handbrake I have installed has a resizing checkbox "keep aspect ratio" when anamorphic none is selected. If it's checked, when you change the resize width, Handbrake will automatically adjust the height (or visa versa). Normally you'd leave "keep aspect ratio" checked otherwise you're free to distort the picture with incorrect resizing. I don't know if the current Handbrake has the same checkbox or if the keep aspect ratio option is permanently enabled.
Anamorphic Loose enables resizing so it's kind of a compromise between Anamorphic Strict and Anamorphic None. Generally you'd only adjust the resizing to achieve a particular mod (if you resize by a large amount there's little point to using anamorphic encoding). Handbrake will keep the storage aspect ratio as close to the original as possible so it doesn't have to change the pixel aspect ratio any more than necessary. Using my previous example of cropping 18 pixels from the width and 12 from the height, it'd probably default to something like 688x464 if the mod is set to 16. If you change the resize width Handbrake will adjust the height. It'll calculate and set the correct pixel aspect ratio when encoding.
Which method you use is up to you and what your particular OCD tendencies permit. Mine force me to use the same resolution and display aspect ratio for episodic encodes, which means I've often got to manually fiddle with the cropping. That's possibly easier to do with MeGUI as it calculates the aspect distortion as you crop, plus you can adjust the cropping while seeing it in the preview.
Normally GUIs will help you adjust the resizing after auto-cropping, but they don't aim for a particular display aspect ratio as such. They only try to prevent you distorting the picture. For example if cropping results in an aspect ratio of 19:8, a GUI would expect to resize to 19:8 dimensions (anamorphic none). If you want exactly 16:9 or 4:3 or some other display aspect ratio when encoding, you have to make sure the cropping is adjusted accordingly yourself. From there you can let the program help with resizing as before. The same principle applies to both anamorphic loose and anamorphic strict.
There's one other Anamorphic option called "Custom". Handbrake makes no attempt to ensure correct resizing or calculate the pixel aspect ratio. It's all up to the user.Last edited by hello_hello; 20th Dec 2016 at 09:20.
-
Originally Posted by "hello_hello
I did some compression tests on this other video, the results are in. It looks like CRF19 is getting this particular video to my specs. So its a 1GB vob source nasa how we left the earth p1 see attachment below https://forum.videohelp.com/attachment.php?attachmentid=39981&stc=1&d=1482274398 So now ill try this on the flipper source again(for completeness, using CRF19 this time, instead of 2pass 1900kbps, and use that as my final result; Assuming it comes out correct :-p
I know i should have ran the tests on that flipper file, but honestly i thought i was done, now my OCD is saying 'DONT USE 2 pass, delete it, re-encode', lol.
@hello_hello
Resizing changes the storage aspect ratio
-this is an easy way to think of it, thanks.
So ok, when seing it the way you wrote the formula (Pixel Aspect Ratio x Storage Aspect Ratio = Display Aspect Ratio), that is an easy way to see whats DAR, and whats PAR really, seeing that the Display Aspect Ratio is a decimal number in your example, that is. So yeah, i use the ratio number alot, i forgot 16x9 was 1.77777, ok makes sense there now, so 1.777 is called the Display Aspect Ratio, or DAR, dude i think i might be able to remember that this time. So the DAR i calculate off, and get teh decimal number.
Ok, so now, your saying to achive NOT distoring the pixels, we need to keep the DAR the same right? This makes sense now i think. I have resized enough pictures in photoshop to last me a lifetime, to know that when you resize an image, you either lock the two together or not, for e.g., the former being keeping the pixels the same dimension im gathering, hence the same DAR?
So im seeing PAR is proportional to SAR (res), meaning they balance the outcome DAR. So tweaking one or the other to solve the AR(DAR) is possible, leverage which ever is to your benefit. And using the calculator to help keep the same DAR im guessing, when altering the resolution. Did i get that understanding correct? Where did you get teh 32/27 ratio at? is that a known standard for ntsc?
I realized what is meant by anamorphic, i didnt realize that it is the encoded "pixel itself" thats not square right? So are most widescreen movies anamoprphic? Or just the ones that say "anamorphic" lol. :-p
on the 24fps, your saying you notice this stuff, i can see why now. Connecting the dots, is that why when you have those movies, or is it all of them, that lack the theatre effect when played back at 29.97? Or is it vice versa? Im thinking that special 24fps indie films, but i could have that mistaken for something else.
Reading on, about your Anamorphic details, that makes much better sense now that Anamorphic None assumes to match sar to dar to achieve square pixel. sigh of relief....
So you said you opt to let it match those, so it correct to square pixel, or maybe you do it manually, since its not widely supported enough yet..
This is like homework, but i appreciate it, cause i wanted to know, thanks for taking the time.
Im going to think twice after cropping to resize at all, this is helping me understand better why, because i dont like to reencode a pixel at all, if possible, so as long as i keep DAR, i think ill let the cards fall, so the pixels are left untouched, and ill consider going Anamorphic None on top of that, to see that that works out without anything i have missed.Last edited by wolfdogg; 20th Dec 2016 at 18:11.
-
This number just barked out at me right now, like never before, hadnt noticed it till now. Its now in my vocabulary, lol. (The PAR Ratio)
[Attachment 39982 - Click to enlarge]
Oh i get it, the raio of PAR is just the value thats calculated, its not a constant or a standard. I see. We have AR, which is (DAR), then we calculate teh "actual" resolution to get a PAR fraction, got itSlightly misinterpreted that in my last post.
So what, now to look at this PAR, it tells us the pixel is not square? Its that simple? Thats the fraction of the pixel shape?Last edited by wolfdogg; 20th Dec 2016 at 18:19.
-
PAR 64:45 is standard for 720x576 16:9 PAL DVD. Though it's only implied since DVD only specifies the frame size and DAR.
-
right, that makes sense to me now. yay!!! Thanks guys for seriously working through all my questions, you have been very helpful.
Im encoding this think in virtualdub now, and guess what, my magic number (was hoping could do decmial, was nicely surprised to see that you can), CFR21.7 is my magic number, the Flipper video IS indeed coming out to be 1025MB, right on the money!!! Not sure WHERE the 7GB thing came in i mentioned earlier. Onwards and upwards! I think ill add that to my signature, lol.
Also, not sure if anybody mentioned, is adding some sort of telecine filter, for e.g. on vdub, a way to add motion blur to flickering source, to clean it up, as a technique, or is telecine strictly broadcase reasons? -
wolfdogg, here's the collection of PARs.
http://forum.doom9.org/showthread.php?p=1058927#post1058927
Traditionally encoder GUIs used the "almost exact ITU" pixel aspect ratios. They're probably the least accurate.
Most GUIs these days use either the mpeg4 or generic pixel aspect ratios, and some let you choose between them. MeGUI is still a little behind the times but you can choose between "Almost exact ITU" and "generic", although you can define your own PARs and use them instead, so I use the mpeg4 PARs that way. I assume Handbrake makes the choice for you.
Because the mpeg4 and generic PARs are slightly different, the mpeg4 PARs result in a display aspect ratio that's slightly wider than 16:9 or 4:3.
As a general rule of thumb I use the mpeg4 PARs for 4:3 DVDs and the generic PARs for 16:9.
You can work out the display dimensions simply by multiplying the width by the pixel aspect ratio. For your previous example:
720x(64/45) =1024. Therefore it's 1024x576.
I haven't read you earlier post properly yet. I'll have to come back to it in a little while.Last edited by hello_hello; 21st Dec 2016 at 02:33.
-
As a said previously, Anamorphic Loose was a kind of anamorphic compromise when mod16 or mod8 dimension were required. These days there's not much point to it, and for resizing by anything other than a tiny amount, I'd switch to Anamorphic None and resize to square pixels while I was at it.
For anamorphic encoding I'd stick with Anamorphic Strict and if you want mod4, adjust the cropping by a couple of pixels if need be.
When you resize in photoshop by locking the width and height together, yes that's what keeps the DAR the same.
Yeah that's pretty much it. Using the calculator to adjust the cropping to achieve a particular DAR is just something I do, so it's up to you. If Handbrake updates the output DAR for Anamorphic Strict you can probably do it without the calculator.
Mostly when the term anamorphic is used around here it refers to any source with non-square pixels, so all DVDs are anamorphic. To confuse the issue the movie industry labelled 4:3 DVDs "Full Screen" while 16:9 DVDs are labelled "Anamorphic".
For movies shot with anamorphic camera lenses that's a different thing, although the concept is the same. A wider image is squished down to fit on narrower film then expanded again later. It has no relation to how it's converted to digital though.
DVDs are the main source of anamorphic video. Standard definition Blu-ray is 720x576 or 720x480 using the mpeg4 PARs. I thought Bluray supported 1440x1080 at 16:9, but none of the official Bluray HD resolutions listed on Wikipedia are anamorphic. It's included in the AVCHD spec though, so maybe that's what I'm thinking of. https://en.wikipedia.org/wiki/AVCHD#Video_formats
Early AppleTV players were limited to 1280x720 at 24fps. To allow them to play higher frame rates, iTunes uses anamorphic video. It's generally 960x720 at 16:9 for 25fps or higher.
I don't know of any other common sources of anamorphic content, aside from digital SD TV broadcast in NTSC or PAL formats.
High frame rates are often described as having a "soap opera effect", named after TV soap operas which were traditionally shot on video rather than film. When video is de-interlaced to 50fps or 59.940fps, motion can look a lot smoother than film, and we're so accustomed to film some people find it looks unnatural, ironically. The lower amount of motion blur contributes to the "soap opera effect" along with a couple of other things, but it's why a lot of people don't like using a TV's frame interpolation to produce higher frame rates as it can seem less like film and more like video. Personally I prefer higher frame rates. They don't look like film for 15 or 20 seconds until my brain adjusts and I no longer care, then when I go back to 24fps it looks "jittery" for 15 or 20 seconds till my brain adjusts and I no longer care.... aside from the strobing effect 24fps can produce.
23.97fps/24fps content converted to 29.970fps and displayed on a 59.940Hz display can produce "judder". For a modern progressive display it's converted back to 23.976fps and in order to fit into the TVs refresh rate, one frame displays for two screen refreshes, the next for three screen refreshes, then two and so on, making 23.976fps fit into 59.940. TVs supporting "film mode" can switch to a refresh rate that's an exact multiple of 24, and they sometimes use interpolation to increase the number of frames and therefore the frame rate. Unfortunately though, frame interpolation tends to produce artefacts that I find more annoying than the original problem.
Chances are, support for anamorphic MP4s and MKVs is fairly normal these days. I don't know if they've got their act together now, but no Samsung products I know of supported it a few years back, so the Samsung TV's here need square pixels for their built in media players, as does the Samsung Bluray player for playing MP4/MKV via USB. Sony seem to have supported anamorphic MKVs and MP4s since day one. I have a five year old Sony Bluray player that supports it and my other half has a Sony Bluray player so old it has no USB input for playing video, but it'll play MP4s and MKVs burned to disc and displays anamorphic content correctly.
I probably should point out, because it'll trip you up at some point if you don't know.
The pixel aspect ratio has been called the pixel aspect ratio for a long time, but technically there's no pixels as such, just samples, so the description used is now "sample aspect ratio". It's referred to as sample aspect ratio in x264's help files, and the command line for it is --sar 64:45 (or your preferred SAR).
As SAR can mean either sample aspect ratio or storage aspect ratio, I think storage aspect ratio is now referred to as something else, but I can't remember what it is off the top of my head.
Edit: x264's help file refers to it as either "width/height" or "resolution", so maybe we're back to using resolution again.Last edited by hello_hello; 21st Dec 2016 at 02:53.
-
This is the telecine process. For a progressive display, an inverse telecine filter aims to reverse it.
https://en.wikipedia.org/wiki/Three-two_pull_down
The upshot of it is frames can consist of two fields (for interlaced video they have to). Even though film isn't interlaced it takes advantage of NTSC being an interlaced format by repeating fields. For every four frames, two of the fields are repeated, and 4 frames become 5 frames, and 23.976fps becomes 29.970fps.
Film is generally convert to PAL by simply speeding it up to 25fps, so there's no telecine involved. There's no doubt filters for reducing flicker, depending on the cause. There may be a VirtualDub plugin or two (I don't use it for encoding), and there'll no doubt be quite a few plugins and/or scripts for tackling it with Avisynth. -
Ok thanks @hello_hello, very helpful info, and I will refer to this post, now that i have the things that were hard to come by, plugged in where they need to be. Thanks you you guys for that much appreciated
Yeah, so im pretty aware of the 3:2 pulldown part, just didnt know if it was a way i can apply "motion blur", (had no idea convert to pal directly, thats cool, still learning what fps conversions can do) i have some vhs source that have flicker/studder and im looking for new ways to prevent that, i know that's an altogether issue, and i wont even ask a single question about that here. I pretty much have a good capture method set up here for that.
I wanted to share my latest encodes, it was of the nasa vid, which was what i tested the CRF on first, i had tried to mimic the 1900kbps direct pass, but it still came out way less, but the funny part is, the file sizes all came out closely correct, causing me to realize that if i had made that CRF come out at 1900kbps average it would seem to be a much larger video dataset, due the higher quality. I hadnt realized this before, to letting it at these reduced results (some as low as 938kbps) has shown me how powerful this is. So these are my finals. Thanks to all of you!!
Code:General Complete name : D:\dusers\Wolfdogg\Videos\processing\vobs\NASA When we left the earth\nasa-1-1-final-crf25-720x408squarepixel-16x9-deinterlaced-filmtuned.mp4 Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 (isom/iso2/avc1/mp41) File size : 554 MiB Duration : 48 min 16 s Overall bit rate : 1 604 kb/s Encoded date : UTC 2016-12-21 05:46:56 Tagged date : UTC 2016-12-21 05:46:56 Writing application : HandBrake 0.10.5 2016021100 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 48 min 16 s Bit rate : 1 376 kb/s Width : 720 pixels Height : 408 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.187 Stream size : 475 MiB (86%) Writing library : x264 core 142 r2479 dd79a61 Encoding settings : cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 Encoded date : UTC 2016-12-21 05:46:56 Tagged date : UTC 2016-12-21 05:46:56 Color range : Limited Color primaries : BT.601 PAL Transfer characteristics : BT.709 Matrix coefficients : BT.601 Menus : 3
Code:Complete name : D:\dusers\Wolfdogg\Videos\processing\vobs\NASA When we left the earth\nasa-1-2-final-crf25-720x408squarepixel-16x9-deinterlaced-filmtuned.mp4 Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 (isom/iso2/avc1/mp41) File size : 450 MiB Duration : 49 min 10 s Overall bit rate : 1 279 kb/s Encoded date : UTC 2016-12-21 07:58:10 Tagged date : UTC 2016-12-21 07:58:10 Writing application : HandBrake 0.10.5 2016021100 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 49 min 10 s Bit rate : 1 051 kb/s Width : 720 pixels Height : 404 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.145 Stream size : 370 MiB (82%) Writing library : x264 core 142 r2479 dd79a61 Encoding settings : cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Code:Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 51 min 22 s Bit rate : 1 180 kb/s Width : 720 pixels Height : 408 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.161 Stream size : 434 MiB (84%)
Code:Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 49 min 17 s Bit rate : 1 130 kb/s Width : 720 pixels Height : 404 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.155 Stream size : 398 MiB (83%)
Code:Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 48 min 4 s Bit rate : 1 043 kb/s Width : 720 pixels Height : 408 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.142 Stream size : 359 MiB (82%)
Code:Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 48 min 32 s Bit rate : 938 kb/s Width : 720 pixels Height : 404 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.129 Stream size : 326 MiB (80%)
Code:Complete name : D:\dusers\Wolfdogg\Videos\processing\vobs\NASA When we left the earth\nasa-1-6-final-crf25-720x408squarepixel-16x9-deinterlaced-filmtuned_preview.mp4 Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 (isom/iso2/avc1/mp41) File size : 12.0 MiB Duration : 1 min 0 s Overall bit rate : 1 671 kb/s Encoded date : UTC 2016-12-21 05:48:40 Tagged date : UTC 2016-12-21 05:48:40 Writing application : HandBrake 0.10.5 2016021100 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings, CABAC : Yes Format settings, ReFrames : 16 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 59 s 960 ms Bit rate : 1 444 kb/s Width : 720 pixels Height : 404 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.199 Stream size : 10.3 MiB (86%)
Question
I just realized there is two sources, one is variable GOP, which one do you think HB is pulling from? I just selected teh folder, it found the files, there was only one selection for this video, not two.
3_1.vob
Code:ID : 224 (0xE0) Format : MPEG Video Format version : Version 2 Format profile : Main@Main Format settings, BVOP : Yes Format settings, Matrix : Custom Format settings, GOP : M=3, N=12 Format settings, picture structure : Frame
Code:Format settings, GOP : Variable
Ok, so on returning, i looked in the nasa 2 folder, it has vts__3_1.VOB, and vts_3_2.vob also, yet these dont seem to differ at all other than a miniscule amount on bit rate(i.e. both are variable gop, same video, two files) unless im missing something, and filesize is same. whats the nature of this on the video_ts folder? Hmm, after looking again, the first one is 10 seconds longer than the 2nd one, and they are both PAL. Do i need to post the specs, or is this familiar? no biggie if not.Last edited by wolfdogg; 21st Dec 2016 at 17:03.
-
Once again:
Code:file size = bitrate * running time
-
I don't know much about capturing issues but for sources with flicker there's no doubt Avisynth scripts and plugins for improving it, but it's not the sort of thing I've worked with myself.
No doubt you did but there's nothing there to indicate for sure. MediaInfo rounds the aspect ratio at times. It's reporting 16:9 for all those encodes even though the heights differ slightly. I don't think x264 writes the SAR to the video stream with the other settings. It'll probably appear in HandBrake's log file. I'm pretty sure it includes most of the information x264 outputs. In MeGUI's log file there's a line like this:
[Information] [22/12/16 3:40:55 PM] x264 [info]: using SAR=1/1
I assume you selected mod4 when resizing? Keep in mind the greater the mod the less accurate the resizing "might" be (that only applies when resizing to square pixels). ie mod16 is potentially the least accurate, as the resizing has to be rounded to the nearest mod16, and therefore mod2 is the most accurate.
You could check the amount of aspect error by copying the cropping and resizing into the calculator (uncheck the ITU option). Alternatively you can set Handbrake's resizing to mod2 and check the resize dimensions. If they're not mod4 you should be able to adjust the cropping and Handbrake will automatically adjust the resizing as you do. When the resizing changes to mod4 dimensions you know it's mod4 and fairly accurate. I'm not 100% sure Handbrake will adjust the resizing as you crop though. I kind of remember if you change the cropping you have to uncheck and re-check the "keep aspect ratio" option in order to get Handbrake to adjust the resizing, but that may have been fixed for the latest version.
Of course the above is only necessary if you're particularly fussy about aspect error like I am.
Sequentially numbered vob files are just a single vob file split into 1GB segments for storing on a DVD disc. There can be more than one sequential set of vob files. The IFO files are kind of like an index to the vob files. The BUP files are backup copies of the IFO files. As long as Handbrake is opening it correctly there's nothing to worry about. -
x264 includes the SAR in the video stream if it's told too. eg: "--sar 32:27". By default it doesn't flag the SAR.
-
What threw me off i guess, is they were both IDENTICAL in size, i totally didnt realize that it was just two segments when i first came up with the wild idea, i didnt see the overflow 3_3 there. I see it now, my apologies, that was kind of a lame total newb question, just didnt realize thats what i was looking at, since there is way too many new variables im learning. the others sort of get momentarily cloudy, or im half blind, lol.
also, yeah, im not seeing the SAR on the mediinfo, ill find the flag one of these days, but dont really need it. thanks. That reminds me though, HB displays this on encoding, i can read the SAR there, no wait, thats the SOURCE video that it shows the SAR for. i guess the only real way to know then is this flag (or logs..)...
Finally guys, i feel like i have some real control over the pixel, using AVC format with x264. Yes theres many many options in VDUB, so i guess this isnt only bad for a newb in learning curve, but its also bad because you can go years on end playing with whatever favourite you may have chosen to play with years prior, when you were that newb. Hey, good bye XVID! Hello x264! Im going to encode all my vhs huffyuv source using these methods, no more AVI for me. Also i had recently re-realized it was a windows format to begin with, one last time... :-pLast edited by wolfdogg; 22nd Dec 2016 at 17:23.
-
When Handbrake's finished encoding, you could always use it to open the encoded video, which then becomes the source..... just so you can get Handbrake to show you the encoded video's SAR.
It might be easier than hunting through log files.
Some encoder GUIs (and I've no idea if Handbrake is one of them) ignore the sample aspect ratio/display aspect ratio when the source resolution is 720x576 or 720x480 and fall back to their usual NTSC/PAL assumptions, at least when the pixel aspect ratio is close to the standard PAR for PAL or NTSC. Something to keep in mind, just in case.
Most programs don't display a sample aspect ratio, but rather DAR as it's more intuitive. As a rule I check that sort of thing with MPC-HC and it's File/Properties menu. If no display aspect ratio is shown next to the resolution, the pixels are square.
Any display aspect ratio shown as part of the video stream info should be quite accurate. Above the stream info, there's a display aspect ratio shown next to "video size", unless the pixels are square in which case once again no display aspect ratio is shown. The "video size" DAR is sometimes a little different to the DAR shown for the video stream. That's because the "video size" DAR is the "display size" without any further upscaling and therefore it has to be rounded to whole pixel dimensions.
By default if both the video stream and container have aspect ratios specified and they're different, MPC-HC will use the container aspect ratio. Most players assume PAL or NTSC is exactly 16:9 or 4:3.
Similar Threads
-
Existing .mp4 AAC transcode to .mp4 AVC
By MelRay in forum Video ConversionReplies: 2Last Post: 14th Aug 2016, 16:11 -
Remux if possible, if not, transcode all videos in a folder to MP4
By Airjrdn in forum Video ConversionReplies: 2Last Post: 6th Oct 2014, 14:13 -
Transcode target bitrate
By n0hc in forum Video ConversionReplies: 4Last Post: 3rd Oct 2013, 14:55 -
Transcode 3gp and MP4 files using VirtualDub and Avisynth
By effes in forum Newbie / General discussionsReplies: 16Last Post: 19th Sep 2012, 15:20 -
best program to resize (larger) dat (VCD) video files
By perfection in forum Newbie / General discussionsReplies: 11Last Post: 18th May 2012, 16:06