which settings for rendering iphone movies (1920x1080x59,96) to mp4

Comments

vkmast wrote on 12/8/2018, 1:24 AM

Just a note to remind you again that build 157 is the latest build. Here. Check online Help (F1) > About > General tab and see which one you now have.

viitaan wrote on 12/8/2018, 5:14 AM

problem of two rigs but now both are build 157, tx!

Musicvid wrote on 12/8/2018, 7:52 PM

The MediaInfo you posted is not variable frame rate; it is a false positive caused by normal rounding jitter.

So, the approach of import, edit, render intermediate, Handbrake still seems pretty valid to me.

 

3POINT wrote on 12/9/2018, 2:04 AM

The MediaInfo you posted is not variable frame rate;

 

It says max framerate 60 fps, min framerate 30 fps. How do you call this?

EricLNZ wrote on 12/9/2018, 2:56 AM

So, the approach of import, edit, render intermediate, Handbrake still seems pretty valid to me.

Wouldn't it be preferable to:

  1. Render intermediate with Handbrake
  2. Import Handbrake files to VMS
  3. Edit
  4. Render to mp4 (or whatever) from VMS
EricLNZ wrote on 12/9/2018, 3:02 AM

The MediaInfo you posted is not variable frame rate;

 

It says max framerate 60 fps, min framerate 30 fps. How do you call this?

It also says the Frame Rate Mode is variable. Presumably this doesn't actually mean the framerate is variable?

viitaan wrote on 12/9/2018, 5:07 AM

any advice on which settings to do export from handbrake? iphone fps is 59,94, what should it convert "well" or does it not matter which I choose?

3POINT wrote on 12/9/2018, 7:56 AM

Export from Handbrake to constant framerate at 59,94 fps. Be careful, Handbrake normal template is also variable framerate, select manually to constant first before starting export.

viitaan wrote on 12/9/2018, 8:19 AM

K. and the framerate drop then takes place in vegas. tx!

I still don't know how to do that transition...

Musicvid wrote on 12/9/2018, 12:14 PM

It says max framerate 60 fps, min framerate 30 fps. How do you call this?

I call it 60000/1001 (not 59940/1000), divided by a clock frequency, that may give an irrational outcome (quotient) that MediaInfo cannot understand if a particular flag is missing or null. All it can see are nearest rationl neighbors, which are interpreted as variable, lacking preemptory guidance from oft-flaky metadata.

Medianfo is notorious for this. It is not the Holy Grail of metadata, just the most convenient. Handbrake metadata dump is exactly the same (wrong) and always has been. It doesn't mean the original source is perfect, however.

t also says the Frame Rate Mode is variable. Presumably this doesn't actually mean the framerate is variable?

Yes. Precisely. Mucho guesswork involved.

Below is what true variable frame rate source looks like. If there were stills involved, Minimum might be as low as 1 fps. It is good to know what you're looking at, even if MediaInfo does not always. This comes up several times a month on the Handbrake tech forum, and causes a LOT of consternation among new users.

 

Frame rate mode                          : Variable

Frame rate                               : 29.970 (29970/1000) FPS

Minimum frame rate                       : 29.412 FPS

Maximum frame rate                       : 31.250 FPS

Musicvid wrote on 12/9/2018, 1:04 PM

Wouldn't it be preferable to:

Render intermediate with Handbrake

Import Handbrake files to VMS

Edit

Render to mp4 (or whatever) from VMS

Not if it doesn't need two lossy encodes, but that's not a guarantee. I'm showing what it looks like, which "may" be a slam dunk.

Also, try out the brand new Happy Otter Import Assist and x264 encoder which will save the wasteful intermediate steps!

Best thing to do is experiment and post back with findings.

3POINT wrote on 12/10/2018, 3:22 AM

Better an extra encoding with HB than a single VMS render that will show blurry/ghosty images of movement due to the resampling caused by the VMS's interpretation of variable framerate.

ps Happy Otter is script based, nice for VPro but useless for VMS.

EricLNZ wrote on 12/10/2018, 3:46 AM

Not if it doesn't need two lossy encodes, but that's not a guarantee. I'm showing what it looks like, which "may" be a slam dunk..

I understand what you mean by lossy encodes but what does "but that's not a guarantee. I'm showing what it looks like, which "may" be a slam dunk" mean please in ordinary English.

vkmast wrote on 12/10/2018, 4:57 AM

@EricLNZ as @Musicvid may not yet read your question due to time zone differencies, this quote from Wikipedia might help in the meantime. "The phrase "slam dunk" has entered popular usage in American English outside of its basketball meaning, to refer to a "sure thing": an action with a guaranteed outcome, or a similarly impressive achievement. This is related to the high probability of success for a slam dunk versus other types of shots."

(Not being a native speaker of American (or any other) English myself I often need to refer to thesauruses/thesauri and the like to understand these idioms/expressions. Once upon a time I even needed to look up "down under".)

 

Musicvid wrote on 12/10/2018, 11:11 AM

Eric, I am embarrassed for my street corner English.

I think from experience that the source media may not be variable frame rate. The MediaInfo provided seems to have "bad guess" written all over it, and that happens quite a lot.

Therefore, an initial frame rate conversion step may "not" be necessary, and the solution may be easier than we all thought (Slang: a "slam dunk," or a "no-brainer," or a "gimme"). If correct, that would save one complete lossy encode, and a lot of time.

"But that's not a guarantee" means that the poster needs to test this for himself since we have not been provided a sample of his source to examine, only an interesting story.

I have no problem if my guess turns out to be wrong, but without "some" engagement or interest in testing from the poster, we may never know...

In the meantime, the Happy Otter Import script may provide a complete solution without resorting to deeper scrutiny or speculation.

https://www.vegascreativesoftware.info/us/forum/happy-otter-scripts-for-vegas-pro--113922/#ca704153

Musicvid wrote on 12/10/2018, 12:14 PM

You guys need to spend more time hanging out at American "saloons."

EricLNZ wrote on 12/10/2018, 3:33 PM

You guys need to spend more time hanging out at American "saloons."

Thanks Musicvid. Perhaps we should all bear in mind that frequently posters here do not have English as their native language. Consequently they struggle with basic English often using Google translate. Adding local slang only adds to their difficulties.

EricLNZ wrote on 12/10/2018, 3:48 PM
Therefore, an initial frame rate conversion step may "not" be necessary, and the solution may be easier than we all thought (Slang: a "slam dunk," or a "no-brainer," or a "gimme"). If correct, that would save one complete lossy encode, and a lot of time.

In the meantime, the Happy Otter Import script may provide a complete solution without resorting to deeper scrutiny or speculation.

Two comments here.

In respect of the first paragraph yes this may be a possibility. Personally I've used "variable framerate" videos from an iPhone and also Windows 10 Gamebar capture in Vegas Movie Studio rendering to 50i m2ts and 50p mp4 without major problems. With his first post the OP said "the intel hevc I've been using starts to suck". Unfortunately the thread has subsequently gone around in circles so we've not (unless I've missed it) established what the poor quality is. Perhaps the solution is as simple as not using hevc.

With "Happy Otter", as 3POINT as commented it is script based so cannot be used with Movie Studio and this is a Movie Studio thread.

Musicvid wrote on 12/10/2018, 5:12 PM

Yes we are in agreement, variable frame rate may not be the problem. With such minimal input from the poster, however, I doubt we'll ever know ...

My reference to scripting was in error, thanks for the reminder.

viitaan wrote on 12/12/2018, 11:00 AM

hey guys. a lot of comments, thanks a ton. pls keep in mind here's an amateur and to turn this into something I can actually use, the info in the end would have tho be pretty simple; step 1 etc format.

 

now that you have seen the mediainfo (for whatever it's worth), is the consensus to:

- use handbrake yes/no as the first step?

- what is the most suitable output format to mp4 from VMS? What I have used so far is based on about 100 rendering tests without knowing at all what I'm doing. so far, the best result for my eyes has been: intel hevc, 29,97, variable bit rate (max 24 bps and average 12 bps), encode quality 4. 

I don't recall anyone yet having said "pls try these encoder options at the following settings". is there a problem in making such a proposal?

Musicvid wrote on 12/12/2018, 1:01 PM

I don't recall anyone yet having said "pls try these encoder options at the following settings"

I don't recall you posting specific examples of your source and render that show your problem ("the intel hevc I've been using starts to suck").

Experiment. Make mistakes. Post back. Upload an original sample (not youtube) if you'd like more help.

If your videos load and preview in Vegas, they're probably ok. Good luck.

viitaan wrote on 12/16/2018, 8:11 AM

hehe, we're now into the second page of comments and I've so far only received requests to do this and that to get the analysis going. now I'm finally told I NEED TO post the original and the rendered as files. fine, I'll do that. I've switched to a new iphone this week so let me get comfortable with that first.

this might be a really helpful first sentence to post to noobs looking for tips: "There's a lot of video pros and tacit knowledge here in this forum. However, to unlock this potential you MUST 1) fill in the forms and ") post the original file plus the rendered file."

 

Musicvid wrote on 12/16/2018, 3:30 PM

Yeah, normally that comes first.

https://www.vegascreativesoftware.info/us/forum/important-information-required-to-help-you--110457/

But in an attempt to cut some corners for a new user, we came across an ambiguity in the MediaInfo, which is triggering different responses. The only way we will know if you need a preliminary conversion is if you actually try it for yourself (did I mention that?) to rule out sync errors and drops, or to upload the actual files. I know of no other way, and it's certainly not worth challenging my good friend Eric over.

I think the offer to look at your files for you is pretty generous, really. Asking for a "do this" answer will just have to wait for the proper information, thanks.

EricLNZ wrote on 12/16/2018, 6:44 PM

hehe, we're now into the second page of comments and I've so far only received requests to do this and that to get the analysis going. now I'm finally told I NEED TO post the original and the rendered as files. fine, I'll do that. I've switched to a new iphone this week so let me get comfortable with that first.

this might be a really helpful first sentence to post to noobs looking for tips: "There's a lot of video pros and tacit knowledge here in this forum. However, to unlock this potential you MUST 1) fill in the forms and ") post the original file plus the rendered file.

 

You've never told us (unless I missed it) in what way you find your rendered mp4 "starts to suck". I did ask in a post way back. What exactly do you find not good with your mp4?

Maybe not using hevc but instead using intel QSV might give better results. Faced with your problem I'd be trying other render codecs to find if they give improved results.