How do you go from 16:9 720p to 4:3 480p with letterboxing in ripbot?

[yoda313]

Ok I want to go from 720p to 480p but the video is widescreen and I need to go to letterboxed 4:3 to preserve the aspect ratio (destination is my tablet that is 4:3).

I'm using ripbot 1.16.4.

I can see the sd ntsc 1.78 output which is what I'm using now for my test run. What I want is a sd ntsc 1.33 output. I can't seem to find a 4:3 option with letterboxing.

Will I need to some calculations to get a fixed value to do a custom resize? What I want is just a drop down option or a "universal" value to use since I'm going to be batch encoding dozens of videos.

I was using handbrake but I've run into problems with certain videos and lately it just keeps crashing on me even after reinstalling.

It had the nice feature of the "none" anamorphic option and keep aspect ratio so I could get 4:3 with letterboxing.

Keep in mind this is mostly 1.78 material so it won't be super small on a 7" 4:3 tablet. I probably wouldn't bother doing the conversion for a 2.35:1 movie to such a small screen, but 16:9 tv material is ok (animated).

So if I need to go to something like 720x400 please let me know (I think this was what the auto recalculated numbers were in handbrake.

Would 720x400 in a custom resize in ripbot give me a letterboxed 4:3 output?

FYI my default player on my tablet has no controls on it so I can't adjust anything. I do have mx player working on it but its hit or miss too hence reencoding to baseline 3.0 in sd. (oh and its a mips tablet so chances are if you suggest a player it won't work).

Thanks and I'd like preferably only one or two FIRM numbers to use for a resize if I have to do the custom resize. I'd hate to have to do this for each set of videos.

---------------------

One last thing I'll also be converting sd 16:9 videos to sd 4:3 videos (hardsubbing involved hence reencoding). Would the same resize number work on material that is originally sd?

Edit - I have done some searching on the forum but I haven't quite found the direction I'm going in.

[jagabo]

So your tablet doesn't respect aspect ratio flags? Won't add borders as necessary? You didn't say what container and codecs you need. Or list any other restrictions (max frame dimensions?). For DVD you would resize the frame to 720x360, add black borders top and bottom to make a 720x480 frame, then encode as 4:3 MPEG 2 for DVD. Or resize to 720x480 and encode as 16:9 MPEG 2 for DVD. For Xvid AVI you can resize to 720x405, add borders to 720x540, and encode square pixel. Or resize to 640x360, add borders to 640x480, and encode as square pixel. Or add borders to your 1280x720 frame to make it 1280x960, then encode square pixel.

[yoda313]

Sorry it can do h264 sd and my destination is mp4.

doesn't respect aspect ratio flags?

Nope. Well put it this way it won't display 16:9 in letterbox, it will be distorted. 4:3 is fine hence the need to letterbox it upon reencoding.

For DVD you would resize the frame to 720x360, add black borders top and bottom to make a 720x480 frame

So if I resize to 720x360 where is the option to add the black borders in ripbot? Also the source material is h264 720p and its 16:9.

Thanks for the help.

[jagabo]

I don't use ripbot. So I can't advise you on that. I seem to recall reading that ripbot lets you modify the AviSynth script it's going to use.

If you're going to h.264 and your player doesn't respect aspect ratio flags you'll need square pixel encoding. Use what I gave you for Xvid AVI. Or just resize to any 16:9 frame size, pad to a 4:3 frame size, and encode as square pixel.

[FulciLives]

If Ripbot let's you adjust the AviSynth script (and I believe it does because I think I did that once) then use FitCD to get the proper resize numbers and change the script.

[FulciLives]

Actually I just encoded a short test clip that I have which is 1080p and it is exactly 1920x1080 (no black in the image so nothing to crop).

I picked the Profile called: [MAIN 3.1] HD, iPAD, iPhone

Then I clicked on PROPERTIES (next to where you pick the encoding mode and if you want CRF or bitrate etc.) and that brings up another window where you can pick cropping options and resolution etc.

I did no cropping (clip didn't need it) and for size I picked: SD-PC 640x360 [1,78:1]

Now on the right hand side of this dialog box it shows the image for cropping purposes but above that you see text that says, "Show Script" and if you click on that it shows you the AviSynth script.

In my case there was a line like this:

video=Spline36Resize(video,640,360).Sharpen(0.2)

I simply added a period at the end and my AddBorders command to make it:

video=Spline36Resize(video,640,360).Sharpen(0.2).AddBorders(0,60,0,60)

When I encoded this clip it did indeed end up at 640x480 and in the proper 4:3 aspect ratio (with black above and below the image).

I double checked with MediaInfo:



Please note that this was done with RipBot264 v1.17.3 (which is the most up-to-date version right now)

[yoda313]

Thanks everyone and thanks fulci. I'll give that a go. That looks like exactly what I need.

[yoda313]

I just wanted to let everyone know I got it! Thanks fulci.

It turns out the corrections you gave me did the trick. However the file stuttered badly and wouldn't play right.

I dug out a file I knew worked ok. I was on baseline 3 but I looked closer at mediainfo and it turns out it had 1 reference frame (the working file that is) but the default is 3 reference frames in ripbot. So I changed it to 1 and lowered the bitrate (upped the cq to 24 instead of 20 thinking it might ease the cpu load). It worked

So know I'm gonna do a larger test bed. I'm gonna do a series that I want converted. I'll use the same settings and each and everyone should be 4:3 letterboxed with hardcoded subs and no stuttering or playback issues with the stock player.

As far as I can tell the reference frames have been giving me issues so now I think I'll just manually adjust it to 1. I'll try testing with 2 and again with 3 at some point to see what the breaking point is. For right now I'm just happy I got a non distorted hardsubbed video that is playable in the stock player.

Thanks again fulci and everyone for pitching in

[FulciLives]

Glad you got it sorted out.

Also you should know that RipBot264 will let you set the MAX bitrate. I did that for some stuff I encoded for my mom's tablet (which is capable of HD resolution MP4 video files, but drops frames like crazy when the bitrate spikes "too" high and that threshold is very low).

[yoda313]

let you set the MAX bitrate.

Shouldn't a high cq rate like 24 be safe?

It is odd though I could play the set that I encoded last night but only after opening it over and over again. So maybe the bitrate is too high. It seems like I"ve got everything else all right.

I'm hell bent on using h264. However if I keep having little hiccups I may abandon it and go for xvid or divx or whichever gives me a totally perfect no issues file.

Thanks for all the tips.

Edit - I"m also wondering if there might be a frame rate issue. I've got a lot near 24fps (you know decimalled to under 24). On the cruz website it did recommend 30fps. So I may have to try that.

What danger is there in letting ripbot do this 24 to 30 conversion? Sync isn't a total issue as these are foreign (to me) videos so I'm using subtitles. However things like music cues and sound effects are time sensitive. If it were to drift significantly that could be just as bad as de-lip synching.

I'm gonna do this next batch the same as the last. I'll test tomorrow night. Hopefully these will work just fine. If not I'll have to dig more deeply.

That max bitrate thing might be a factor as well.

[FulciLives]

It should be able to handle any normal framerate at or under 30fps so trying to change the framerate to exactly 30 makes no sense to me.

Not sure what else to say other than good luck. Sounds like your device is very picky

[yoda313]

It should be able to handle any normal framerate at or under 30fps so trying to change the framerate to exactly 30 makes no sense to me.

Not sure what else to say other than good luck. Sounds like your device is very picky

Just grasping at straws right now. I'll be checking my latest batch in a bit. Hopefully it worked ok. And yes its pretty picky. It can play a few different codecs but seems to be relatively strict.

I will eventually get a more versatile tablet but for now its a love hate relationship. But I look at it as a learning curve.

Also it is fun tinkering with the right settings to a point. After all I am a videohelp veteran But after a certain point nitpicking over every detail loses its appeal if it doesn't get you closer to a final usable product.

Like I mentioned if I keep having issues I may abandon h264 and shoot for divx/xvid and give that a go. Though it definitely feels like taking a step back if I do that......

[yoda313]

Well I nearly had my eureka moment. I did get a batch of videos converted to h264 with ripbot264 and they worked! Well all is not well. I've done a batch of seven sets of videos (each with different beginning attributes). It seemed I inputted them all with the same encoding settings including the add borders command fuclilives pointed out.

5 of the batches work correctly while two do not. I'd say that is a good success ratio considering I was hitting a brick wall earlier.

I thought I had done the same procedures for each batch before and now it seems I have not somewhere along the line. Please note a few had flac audio whereas others had aac audio. The ones with aac audio I simply did a copy audio to let it passthrough. For the flac I let ripbot do the audio conversion it saw as the best option. I do have one set of videos that is out of sync signifcantly.

I will have to piece through all of the differences with the two batches that don't work to make sure I get a fool proof setting laid out before piling forward with the ton of batches I have left. I don't have a time frame to do this but I wanted to get it going and simply set up a mega batch job and let it rip. So for now I will have to hold off and try to sort out the issues. Several of the sets are 720p while others are standard def - with the goal of converting to standard def.

Here are the details for the different batches. Please note I haven't confirmed yet that the other four working batches all share essentially the same stats as the one that I am posting here. For now i am making an assumption that for the vast majority of the vital stats all 5 of the working batches are identical - or nearly identical in codec and format structure.

The details are attached:

converted plays fine.txt

converted plays but out of sync.txt

converted won't play at all.txt

One thing I did notice was one was set to 720x480 but it should have been the sd pc 640x360 that fucli posted. Also for some reason one has m4v and the others are mpeg4. All have .mp4 extensions.

The ripbot version I am using is 1.16.4. I know fulci pointed out there is a newer version out but once I got a set of videos working I didn't want to jinx it.

It looks like once I do nail the right settings I will have to go just a touch slower in setting up the batch job as apparently I missed a setting with the resolution on one.

I can confirm that the one with the audio sync issue did originally have flac audio. It might be I will need to have to treat the source vids with flac differently versus the ones that already have aac audio.

Thanks for anyone that can help point out other issues with the two sets that don't work properly with the one that does.

I appreciate all of the assistance. I'm nearly all set to getting my velocity cruz t301 to work with h264 video! Woohooo

Edit - upon closer inspection the one that won't play at all has a different profile format than it should - High@L1.3 - I don't remember selecting that.

Also please note in ripbot I was using the default base profile 3.0 and cq crf 26. I wanted 26 to lower the bitrate (a LOWER crf number means a higher bitrate, isn't that the way it works? i want a lower bitrate to lessen the load on the tablet plus its not high def and only 4:3 so I don't need to push the bitrate too high).

[FulciLives]

Well the only real difference that I can see between 1 and 2 is that 2 has 3 ref frames where as 1 has 1 ref frame. It is possible the files in group 2 are in sync with a capable device (like your computer) and only out-of-sync on the Tablet since it can't handle 3 ref frames? I guess if they play in sync on your computer we can conclude that and I suspect this is the case.

The 3rd batch has the different, higher resolution and totally different settings. I'm guessing you just screwed up the settings there in the program. I'd do one from that batch making very sure you select all the correct settings and then see how it turns out.

[yoda313]

Well the only real difference that I can see between 1 and 2 is that 2 has 3 ref frames where as 1 has 1 ref frame. It is possible the files in group 2 are in sync with a capable device (like your computer) and only out-of-sync on the Tablet since it can't handle 3 ref frames? I guess if they play in sync on your computer we can conclude that and I suspect this is the case

Do you mean 1, 2, 3 in the order I posted the files?

In any case I have confirmed that actually it can play with 1 AND 3 reference frames. Somewhere along the line in this set of encodings I had made the switch. Anyhow it will play with 3 reference frames and that file is a-ok sync wise.

The 3rd batch has the different, higher resolution and totally different settings. I'm guessing you just screwed up the settings there in the program. I'd do one from that batch making very sure you select all the correct settings and then see how it turns out.

Actually it can play the 720x480 resolution - from other testing. However the rest of the settings must have made it reject the file.

I'll simply have to reencode that batch and try again as you suggested.

At least I've been making progress. Hopefully I can also nail down the sync issue. It may be that the three different aac options ripbot gives has something to do with it. It might be whichever was chosen the tablet doesn't like.

Thanks again. I think I'm nearly there. At least I have some benchmarks to work with.

[FulciLives]

Yes I'm using numbers as in the order you posted them.

Also you are confusing me. Batch 1, which you say works and is in sync, show only 1 ref frame.
Batch 2, which you say plays but it out-of-sync, shows 3 ref frames.

You can understand how I came to the conclusion that your player doesn't like 3 ref frames, right? Yet you say it does. I can only assume you have at least SOME files with 3 ref frames that do play and are in sync.

As for the audio options in RipBot ... you might want to try re-encoding the audio first and then remux and import that into RipBot, telling it to pass it through. It seems that worked well with other files (that were already AAC) so that may need to be your plan of attack with files that aren't already AAC to begin with.

[yoda313]

Also you are confusing me. Batch 1, which you say works and is in sync, show only 1 ref frame.
Batch 2, which you say plays but it out-of-sync, shows 3 ref frames.

Sorry for the confusion. Yes there are working and in sync files with 1 reference frames as well as 3 reference frames. I didn't remember I made the switch when I posted.

As for the audio options in RipBot ... you might want to try re-encoding the audio first and then remux and import that into RipBot, telling it to pass it through. It seems that worked well with other files (that were already AAC) so that may need to be your plan of attack with files that aren't already AAC to begin with.

Yes I'll have to check exactly which aac settings were used on the working converted files. Then I should be able to get it working. The out of sync did originally have flac so that will my flag to know to do something about it in the batch setup process.

Thanks again

[yoda313]

I have an update.

I have all the sets working now!

I did test encodes with one video each from the two sets that had issues. Both are working now.

handbrake flac converted works.txt
handbrake ac3 conversion works.txt

It turns out the one above that had the totally wrong settings (batch 3 I believe) did work out ok upon reconversion. However it ended up out of sync as well.

The one that did play but was out of sync originally (batch 2) worked out ok with handbrake.

I found the common denominator with the sync issues. In ripbot both sync issue files had different times reported for the video and audio. They were off by several seconds. I checked the original files with mpchc and they did play ok but there was a line in the player stats while it was playing about an offset for audio being several ms. So it was playing correctly but there was somekind of underlying sync issue. Rather than fight an offset issue with ripbot (please note I was importing the original source file into ripbot and that was what was showing a time difference) I tried again with handbrake.

So with handbrake I used the universal Apple preset for h264. I set the video to anamorphic-none and keep aspect ratio. I also set the audio to aac and did the subtitle burn in. I made sure it outputted it to mp4. Upon conversion it worked. It was in sync and played with the stock video player on the tablet. It was also correctly displayed even though it was 16x9 according to mediainfo but handbrake cropped it so the player actually does show the video with the black bars so it is not distorted.

Whew what an exercise. But now I have two working platforms to use. So long as the time durations are equal in ripbot I will use ripbot. If any are out of wack I will encode with handbrake.

Please note the two that were out of sync after conversion with ripbot were ac3 and flac. I'm not sure why ripbot would have a problem with either. I even tried demuxing the flac file and reencoding to ac3 prior to using avidemux (reencoded flac separately with eac3to). Than I used avidemux to use the converted video and use the converted ac3 to convert that to aac but it didn't solve the sync issue - using handbrake with the original source file did).

So all in all I now have a working process for the large batch project that I am embarking on. Thankfully I seem to be ready to go with confidence that the resulting files will not only play but play in sync and without issues.

------------------

One seperate question about subtitles. These are all .ass subtitles so far as I can tell but handbrake and ripbot encode them differently. Ripbot encodes them on top of the frame so that a long sentence will be two lines covering the video and the black bar. Whereas handbrake completely embeds the subtitle inside the black bar *edit - what I mean is it is completely inside the video itself within the black bars not touching the black bars - . I am wondering if this has to do with the square pixel encoding I'm doing with ripbot - the sd pc 640x360 and the add borders command that fulcilives suggest that I use.

What I do with handbrake is tell it to use none for anamorphic and keep aspect ratio. It keeps it 16x9 but crops it. Is this the difference with the subtitle location? Not that I really need to but is there a way in handbrake to totally and completely get a 4:3 frame output? Would that create the same subtitle output as ripbot does?

The only reason I'm bringing this up is that the ripbotted subtitles are a bit larger and easier to read on the tablet. I suppose I could fiddle around in handbrake and see if there is a way to make the subtitles larger. But for now I am just happy everything is working and in sync.

Thanks again for everyones help - especially fulcilives

I hope this will help anyone else who is using a second (or third) tier class tablet like the velocity cruz t301. It is capable but finicky.

[FulciLives]

I looked into it before and there seems to be no way in HandBrake to do the AviSynth equivalent of AddBorders. You can always NOT crop but you cannot add anything (like black borders).

Also since you have HandBrake cropping the video there is no black border in the video and so the hard subtitles cannot be in the back (since they aren't there). If you see black borders on your Tablet that is because they are being added by the player. Just like when you play cropped video on a computer monitor but it adds black if the ratio doesn't fit the screen ratio 100%

In RipBot you are encoding 640x480 and so if the ratio isn't full screen the black is getting encoded into the video which allows the subtitles to be placed lower, thus they will be entirely or at least partially in the black (on a widescreen video).

I have no idea why the subs are different sizes (RipBot vs HandBrake)

[yoda313]

I looked into it before and there seems to be no way in HandBrake to do the AviSynth equivalent of AddBorders. You can always NOT crop but you cannot add anything (like black borders).

Also since you have HandBrake cropping the video there is no black border in the video and so the hard subtitles cannot be in the back (since they aren't there). If you see black borders on your Tablet that is because they are being added by the player. Just like when you play cropped video on a computer monitor but it adds black if the ratio doesn't fit the screen ratio 100%

In RipBot you are encoding 640x480 and so if the ratio isn't full screen the black is getting encoded into the video which allows the subtitles to be placed lower, thus they will be entirely or at least partially in the black (on a widescreen video).

I have no idea why the subs are different sizes (RipBot vs HandBrake)

Ok. THanks for the info fulci.

Eventually I'll get a more powerful tablet and I'll be able to play the original files with a better video player. Than I should be able to do subtitles better and I'll hopefully get a widescreen tablet so this conversion won't be necessary. Or put it this way any conversions would be fewer and farther apart on a more capable tablet.

For now I'm happy with the results I'm getting.

I'm also looking forward to testing a lot of the sd videos I've downloaded. Many are just plain old vanilla xvid/divx. I might be able to play those on the tablet as is. As long as there aren't any funky codec settings in the video I should be able to get away without encoding. However if they are too packed in with special modes and stuff I may have to reencode.

Anyway it has been fun being able to actually get some of these to work. Especially the high def ones. Now it will be interesting to see how many of the sd ones I can simply load into the player and go. It would be nice if I don't have to convert ALL of my videos.

Thanks again.

Edit - if I were to encode a 2.35:1 widescreen movie for my tablet would the 0,60 border dimension work or is it a different value? These have been 1.78/85:1 tv type videos and the conversions have given it a black bar but not a super wide black bar that would make it excessively tiny on screen.

[FulciLives]

Well RipBot will resize it correctly so it is up to you to see what numbers it used and to then add the black accordingly to get 640x480

For instance 16x9 should resize to 640x360 which means 60 black on top and 60 black on bottom.

However something that is 2.35:1 should resize to 640x272 and then you are looking at 104 black on top and 104 black on bottom.

I should point out that now that I think about it ... you might not need to add the black. Since 640xwhatever is 1:1 pixels your player may not need it padded out to a height of 480

[yoda313]

However something that is 2.35:1 should resize to 640x272 and then you are looking at 104 black on top and 104 black on bottom.

Sounds good.

I should point out that now that I think about it ... you might not need to add the black. Since 640xwhatever is 1:1 pixels your player may not need it padded out to a height of 480

Interesting. I"ll have to test it out sometime. Right now I'm backing up all my source files. I'm also in the middle of converting my high def files. I'll be testing my sd files to see which ones i have to convert and which I don't. Assuming I can play them straight away I might not even need to convert them for subtitles hardcoding so long as the mx player software can read the files using the hardware decoder - that way the mx player for android actually can play subtitle files (this version that I have actually does run on my mips tablet - but the video still has to be natively playable on the tablet since my tablet is not powerful enough to use the software decoder in mx player - it stutters horrifically at like 10fps at best or lower I'm sure.

[yoda313]

I thought I'd give an update. I haven't worked on a 2.35:1 movie yet but I have been getting a lot of conversions done lately. I've been doing batch encodes just about every night. I still have more to do of course but it is nice to be making progress on my collection.

I do have good news. I have some standard def xvid videos that work without converting. I thought I'd post it here so that others can now what settings to use in xvid for working files (though it is a bit odd that in the stock player it will play it but you have to click play after the file loads, sometimes the player does "stick" on some video files but will play after pressing play).

Here are the stats of the one that works (fortunately it was hardsubbed but I could use the mx player if it wasn't since it can use the "hardware decoder" to play the video file thus saving a reencoding job - but only when the video itself can be played by the stock player on the velocity cruz t301 tablet.

General
Complete name : E:\*******.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 70.9 MiB
Duration : 9mn 53s
Overall bit rate : 1 002 Kbps
Writing application : VirtualDubMod 1.5.10.1 (build 2366/release)
Writing library : VirtualDubMod build 2366/release

Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 2
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 9mn 53s
Bit rate : 865 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.117
Stream size : 61.2 MiB (86%)
Writing library : XviD 1.1.0 (UTC 2005-11-22)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 9mn 53s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 9.05 MiB (13%)
Alignment : Aligned on interleaves
Interleave, duration : 42 ms (1.00 video frame)
Interleave, preload duration : 504 ms
Writing library : LAME3.97 (beta)

I'll edit and update this post as I check out more and more of my sd xvid and divx files. I don't have a lot but I do have some so not having to reencode these will definitely save a lot of time and space. Unfortunately since h264 files have more complications with this tablet I have to reencode those to a more simplified level for the player to handle. But at least I am making progress and can get video to work out on this tablet.

Hopefully this will be useful to other people who have this tablet or a similar spec'd mips tablet that doesn't play a wide range of video formats.