VideoHelp Forum




+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 46 of 46
  1. Originally Posted by wolfdogg View Post
    On another note, also because im hopeful still that 25fps will help shrink the file sizes, knowing that the brain really only needs 15fps for fluid motion, so if the flicker isnt visible at 25fps
    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.
    Quote Quote  
  2. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    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.

    Originally Posted by jagabo View Post
    Originally Posted by wolfdogg View Post
    On another note, also because im hopeful still that 25fps will help shrink the file sizes, knowing that the brain really only needs 15fps for fluid motion, so if the flicker isnt visible at 25fps
    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.
    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.
    Quote Quote  
  3. Originally Posted by wolfdogg View Post
    im the same way, just more careful when i clip top and bottom, and dont OCD on that part, just all the rest, lol, i have to have all my episodes same. You are shedding light on some of the intricacies that count though, i think i SHOULD be paying more attention to that detail, since i have been struggling with(well thats the OCD in me, cause they mostly all come out perfect, lol) AR, usually par/dar as mentioned, but the end result is always a strict 4x3, 16x9, or blackbar/envelope on only ONE side (when played-back with default vlc settings in fullscreen for e.g.)
    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.

    Originally Posted by wolfdogg View Post
    Ill try this sometime, after i go through my encodes using these refined methods. This is VERY HELPFUL, SUPER THANKS for those few examples , especially i would have never attempted anything at 1.777 anything, and im totally not familiar with PAL much, i have been an NTSC guy until recently, since im ready to learn it.
    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.

    Originally Posted by wolfdogg View Post
    On another note, also because im hopeful still that 25fps will help shrink the file sizes, knowing that the brain really only needs 15fps for fluid motion, so if the flicker isnt visible at 25fps, i think all vid should be encoded to that, lol, save file space.
    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.

    Originally Posted by wolfdogg View Post
    So this is a bit confusing to me as to what that means, so picking an anamorphic type, you mean in HB, e.g. strict vs loose? If so i can follow; And so your saying resize, AFTER crop it looks like, so meaning let HB crop, then resize to specific apsect ratio (all episodes), (and im guessing at the expense that widths, or is it hieghts, may differ, but dont always; but then your saying during that resize, it will definitely be square pixel (where is this determined? you mean by keeping the dimensions exactly proportional to the source(minus the crop)?
    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.
    Quote Quote  
  4. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    Originally Posted by "hello_hello
    The player adding black bars to just one side on playback seems a bit odd.
    You were completely right, it was something stupid on my part, good call. My middle monitor (of a 3 wide setup) resolution was, causing the black bars, couldnt tell because the wallpaper had black bars too, when the video played, it just didnt take up the foll monitor, Buah, hahhh, sorry, my bad!! :-p I wondered why the hell when i played it back on the other monitor it worked perfect, man i tell ya..

    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.
    Image Attached Images  
    Last edited by wolfdogg; 20th Dec 2016 at 18:11.
    Quote Quote  
  5. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    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)Image
    [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 it Slightly 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.
    Quote Quote  
  6. 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.
    Quote Quote  
  7. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    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?
    Quote Quote  
  8. 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.
    Quote Quote  
  9. Originally Posted by wolfdogg View Post
    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?
    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.

    Originally Posted by wolfdogg View Post
    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?
    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.

    Originally Posted by wolfdogg View Post
    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
    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.

    Originally Posted by wolfdogg View Post
    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.
    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.

    Originally Posted by wolfdogg View Post
    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..
    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.
    Quote Quote  
  10. Originally Posted by wolfdogg View Post
    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?
    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.
    Quote Quote  
  11. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    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%)
    the 6 preview was much higher rate, more power to CRF as it synced down on the fly!
    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%)
    p.s., im wondering if somebody is going to tell me that this totally isnt square pixel, i believe i did an 'anamorphic none' 'Keep aspect Ratio' to get it to that. did i square them up?

    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
    3_2.vob
    Code:
    Format settings, GOP                     : Variable
    Edit: im going to do some tests real quick to see if i can find out.
    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.
    Quote Quote  
  12. Originally Posted by wolfdogg View Post
    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
    Once again:

    Code:
    file size = bitrate * running time
    Universally, No matter what the frame size, frame rate, codec, other setting, etc. There is a small amount of overhead for the container (typically a few percent for MP4 or MKV, 5 to 10 percent for transport streams) and of course, the audio adds to the size. But if two videos use the same container, same audio, are the same length, and MediaInfo reports the same bitrate, but the file size is different, then the bitrate report is wrong for one or both files.
    Quote Quote  
  13. Originally Posted by wolfdogg View Post
    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 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.

    Originally Posted by wolfdogg View Post
    p.s., im wondering if somebody is going to tell me that this totally isnt square pixel, i believe i did an 'anamorphic none' 'Keep aspect Ratio' to get it to that. did i square them up?
    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.

    Originally Posted by wolfdogg View Post
    Edit: im going to do some tests real quick to see if i can find out.
    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.
    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.
    Quote Quote  
  14. 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.
    Quote Quote  
  15. Member wolfdogg's Avatar
    Join Date
    May 2011
    Location
    Portland, OR, USA
    Search Comp PM
    Originally Posted by hello_hello View Post
    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.
    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... :-p
    Last edited by wolfdogg; 22nd Dec 2016 at 17:23.
    Quote Quote  
  16. 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.

    Click image for larger version

Name:	MPC-HC.gif
Views:	556
Size:	15.1 KB
ID:	40042
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!