MeGUI Doing Weird Things to Frame Rate

[koberulz]

I've got a 29.970fps MP4.

I've imported it into Premiere, and placed it into a 29.970fps Sequence.

I've exported to Advanced Frame Server, then loaded the resulting AVI into MeGUI:

AVISource("file.avi", audio=false).AssumeFPS(30000,1001)

ConvertToYV12()

The resulting .264 file shows up as 29.970fps in MediaInfo, which makes perfect sense.

But I imported it into DoStudio and was having all sorts of problems with chapters being where they shouldn't, so I opened the .264 file in VLC just to check, and VLC claimed it was 59.940059fps. When I flagged it as 59.94 in DoStudio, my chapters lined up perfectly.

What happened?

EDIT: They line up perfectly in terms of time code, but what's happening on the screen isn't right. Starts out off by a split second, by the last chapter marker it's out by a couple of seconds. I'm guessing this is just a result of the frame rate change.

[hello_hello]

Is it interlaced? Sometimes interlaced h264 can be interpreted at twice the correct frame rate. 54.94 instead of 29.97 etc.

Places where things might go a little wrong....
How are you determining the frame rate of the source MP4? Try removing AssumeFPS(30000,1001) from MeGUI's script. That's telling Aviynth to assume a frame rate of 29.970. If you open the script in MeGUI's preview while it contains AssumeFPS(30000,1001), remove that from the script and refresh the preview and the total duration changes, then maybe the source isn't exactly 29.970. Even if for some reason the source is really 29.965 or something similar, that's enough.

Keep in mind 29.970 or 59.940 are very close to the NTSC frame rate, but not exact. The difference in practice usually isn't enough to matter, however....
30000/1001 = 29.97002997002997002997002997003
60000/1001 = 59.94005994005994005994005994006

In theory VLC reporting 59.940059fps would be correct (assuming it's reporting exactly twice the frame rate) relative to 30000/1001, so any slight frame rate change might have happened at the 30000/1001 stage in the script.

You might want to check, assuming you didn't edit, that the final output has exactly the same number of frames as the source. If not, maybe frames are being dropped at the frame serving stage and that's throwing a spanner in the works

I can only guess, but start by checking the total frame count and the exact durations to see if any mysteries are revealed. If you want to check the total frame count of the final output file, try opening it with MeGUI and indexing with L-Smash if possible. By default, L-Smash decodes at the average frame rate, so if there's missing frames the frame rate won't be exactly 29.970, and by default it doesn't replace dropped frames with duplicates, so you can determine the real frame total that way. Add Info() to the end of the script after indexing with LSmash.

[koberulz]

Is it interlaced? Sometimes interlaced h264 can be interpreted at twice the correct frame rate. 54.94 instead of 29.97 etc.

No.

I also forgot a step I'd done: I put it through tsMuxer to create a TS file, in order to solve audio sync issues I was having.

How are you determining the frame rate of the source MP4?

MediaInfo and Premiere both claim it's 29.970. Try removing AssumeFPS(30000,1001) from MeGUI's script. That's telling Aviynth to assume a frame rate of 29.970. VLC claims 29.970029. I'm assuming the difference is just rounding.

If you open the script in MeGUI's preview while it contains AssumeFPS(30000,1001), remove that from the script and refresh the preview and the total duration changes, then maybe the source isn't exactly 29.970. Even if for some reason the source is really 29.965 or something similar, that's enough.

Duration is 2:30:20.945 in both instances (sequence length 2:30:20:28).

You might want to check, assuming you didn't edit, that the final output has exactly the same number of frames as the source.

I removed about 15 minutes of footage in Premiere, but MeGUI reports the same number of frames as the Premiere sequence (270358). If I import the .264 file into Premiere, it still says it's 29.97fps, but it's suddenly down to 2:30:11:29. If I create a sequence from it, though, that sequence still has 270358 frames.

[hello_hello]

I removed about 15 minutes of footage in Premiere, but MeGUI reports the same number of frames as the Premiere sequence (270358). If I import the .264 file into Premiere, it still says it's 29.97fps, but it's suddenly down to 2:30:11:29. If I create a sequence from it, though, that sequence still has 270358 frames.

That seems to make no sense. I can't get my head around it.
MeGUI encodes and outputs the h264 video at 29.970fps and it has a total of 270358 frames. Duration 02:30:20.
After giving it to Premier to play with though, you're losing 9 seconds. Is that correct?

1001/30000 x 270358 = 9020.95 seconds = 150.35 minutes = 2.5058 hours = 02:30:20 or something pretty close, so if that's MeGUI's output when encoding the video it should be okay.

Unless a Premier user comes along to help (I'm not one) you might have to have stern conversation with it. 270358 frames at 29.970 for a 02:30:11 duration doesn't compute. Unless my math is bad, which it could be, that'd mean a frame rate of around 30.003fps.

To be honest I hardly slept last night and my brain turned to mush about an hour ago, so I could be missing something obvious. It doesn't make sense and I'm not sure why.

Edit: Oh hang on....... drop frame timecode..... does Premier use it?
I live in PAL land so I hadn't thought about that. It could explain the apparent time difference which mightn't be a time difference at all, or it might account for most of it. I'd work it out but I hurt my brain earlier converting frame count to duration. If that explains the apparent time difference I'm still not sure how to explain the chapter sync problem though (maybe they need to be imported in a specific way for Premier to adjust them.... assuming that's where they're being added... I'm still not clear on the whole process), but have a read, and hopefully someone more clever will come along with another idea. Is there audio involved and it is staying in sync? I'm not sure if that's been asked yet.
https://en.wikipedia.org/wiki/SMPTE_timecode#Drop_frame_timecode

I'll post back if I think of anything else, but if you work it out please let me know. I'm curious now and it can't hurt to learn.

[koberulz]

MeGUI encodes and outputs the h264 video at 29.970fps and it has a total of 270358 frames. Duration 02:30:20.
After giving it to Premier to play with though, you're losing 9 seconds. Is that correct?

Duration is 2:30:20 in video preview in MeGUI. Opening the .264 file in PowerDVD, it's...01:42:33. Looks like it's the whole video, and it's playing at normal speed...but that's way too short. WTF. Not really going to sit and watch the entire .264 file though; it's long and pretty dull without audio. VLC doesn't list a duration at all.

Edit: Oh hang on....... drop timecodes..... does Premier use them?

Yes, yes it does. Changing from drop to non-drop display on the sequence that's being output gets a duration of 02:30:11:28. So there's that problem solved.

Still no idea why VLC and DoStudio treat the .264 as being 59.94fps or why PowerDVD has it 50 minutes shorter than it should be. It can't be that sped up. It's a basketball game, with a clock on the screen, so I put my watch to my ear and viewed it, and the game clock decreased by one second for every tick of my watch (obviously I couldn't sync them, so minor differences remain a possibility, but it seems unlikely).

[hello_hello]

I'm not sure I'd expect a player to do anything reliably when opening a raw h264 stream. Stick it in an MKV or MP4 first and it'll probably be a different story.

MeGUI can be configured to write the encoded video directly to an MKV if you haven't done so already. Possibly not ideal if you ultimately need MP4, but MPC-HC (for one) will index the output MKV when you open it so it can seek accurately and display the correct duration, and you can open the output MKV while the video is being encoded. Opening raw video streams mightn't work very reliably. Players might have a quick peak and take a guess.... mind you I don't know if every player will index and accurately seek when opening the MKV x264 writes (before it's remuxed) but MPC-HC definitely will. Even for MKV, other players might peak and guess.... and correct the total duration as playback progresses. I kind of remember that's what VLC does when opening the MKV written by x264..... takes a wild guess which it gradually corrects as it's playing.... although don't hold me to that. VLC and I have never managed to become close friends so I don't use it much.

If you don't have AVIsynth "installed" (in addition to MeGUI's portable version), you definitely should install it, and download the portable version of MPC-HC too if you don't have it. Once that's done, MPC-HC can open the scripts MeGUI creates for previewing which can be quite handy.... even for just confirming the frame rate.
I stick a shortcut to MPC-HC in the Windows SendTo folder so I can right click on a script and use SendTo/MPC-HC to open it, then eventually drag the player over to the TV and run it fullscreen. There's no substitute for being able to preview the video to be encoded as you intend to watch it.... before you encode anything.

PS. Just curious.... I noticed you live in Australia. Where are you located? I'm in Melbourne. Narre Warren South, to be more specific.

[koberulz]

Possibly not ideal if you ultimately need MP4

I ultimately need raw 264: that's all DoStudio accepts. It then muxes that with an .ac3 file to create an .m2ts for the final Blu-Ray disc.

If you don't have AVIsynth "installed" (in addition to MeGUI's portable version), you definitely should install it, and download the portable version of MPC-HC too if you don't have it. Once that's done, MPC-HC can open the scripts MeGUI creates for previewing which can be quite handy.... even for just confirming the frame rate.

Well, according to MPC-HC the .avs has a frame rate of...between 28.44 and 29.97. Wanders all over the place initially, but has seemed to steady now (about a minute in) between 29.96 and 29.97. File is 02:30:21. The wandering happens every time I drag back to the start of the video.

PS. Just curious.... I noticed you live in Australia. Where are you located? I'm in Melbourne. Narre Warren South, to be more specific.

Perth.


EDIT: Tried throwing the .264 and the .ac3 into tsMuxer and creating an .m2ts. It was just a grey screen with intermittent patches of color, occasionally turning completely green. No audio, no runtime, claimed a 59.94 frame rate. tsMuxer claims a "59.9401 (pulldown)" frame rate for the .264 file.

[flashandpan007]

Is it interlaced? Sometimes interlaced h264 can be interpreted at twice the correct frame rate. 54.94 instead of 29.97 etc.
Keep in mind 29.970 or 59.940 are very close to the NTSC frame rate, but not exact. The difference in practice usually isn't enough to matter, however....
30000/1001 = 29.97002997002997002997002997003
60000/1001 = 59.94005994005994005994005994006

Are you really sure?
I thought there are framerates like 24.000, 25.000, 30.000, 50.000, 60.000 and then there are 24000/1001, 30000/1001 and 60000/1001 which are also called 23.976 or 23.98, 29.970 or 29.97 and 59.940 or 59.94 which are also EXACTLY the same.

[hello_hello]

23.976 is the "rounded" version of 24000/1001 and the same applies to 29.970. Some programs/plugins/whatnots probably convert 23.976 to 24000/1001 but I don't think that's universal. That's why MeGUI adds AssumeFPS() to the script when decoding via AviSource and DirectShow. To make it exact. The other standard frame rates would be correct whichever format you use. NTSC.....

Avisynth provides some info here: http://avisynth.nl/index.php/FPS#AssumeFPS

koberulz,
I've got to spend most of today in the real world.... but I'll be thinking of you.
The frame rate changing.... I can only assume that's because the frame serving isn't happening in a timely manner and MPC-HC is reporting the actual frame rate rather than the "what it should be" rate. I don't know if it matters and that could be a load of bullocks (I'm guessing). Any frame serving experts around?

DoStudio doesn't accept MP4? AVI even? I still think it'd be better to but the video in something. Try muxing an M2TS file with MeGUI (under the Tools menu) if you haven't yet.. It probably uses TSMuxer anyway, but it might add some command line cleverness that'll make the resulting file useful. I'm not sure, but it can't hurt to try....

[koberulz]

I've got to spend most of today in the real world.... but I'll be thinking of you.

Creepy.

The frame rate changing.... I can only assume that's because the frame serving isn't happening in a timely manner and MPC-HC is reporting the actual frame rate rather than the "what it should be" rate.

The possibility occurred to me, so I opened the TS file I got from putting the source MP4 through tsMuxer...same thing. It's also true of the source MP4 itself. So...is it a variable frame rate file? Everything reports the TS file as 29.970, even VLC (which has the .264 at 59.94), which would indicate that it isn't, and even if it was the output from Premiere certainly shouldn't be VFR.

EDIT: A very-definitely 25fps file going through the same process (Premiere -> AFS -> AVS -> MeGUI -> .264) reports an all-over-the-place frame rate for the frameserved AVI file and the AVS file, and a varying but consistently 24-25fps rate for the resulting .264. Same with a VOB file from a DVD. So MPC-HC's frame rate information is evidently worthless.

DoStudio doesn't accept MP4? AVI even?

It accepts .m2v, .m2p, .mpg, .mpeg, .vc1, .avc, .264 and .h264. It has no encoding ability of its own, so it needs the raw files.

[hello_hello]

I've got to spend most of today in the real world.... but I'll be thinking of you.

Creepy.

I was referring to your problem, not doing a stalker impression.

EDIT: A very-definitely 25fps file going through the same process (Premiere -> AFS -> AVS -> MeGUI -> .264) reports an all-over-the-place frame rate for the frameserved AVI file and the AVS file, and a varying but consistently 24-25fps rate for the resulting .264. Same with a VOB file from a DVD. So MPC-HC's frame rate information is evidently worthless.

I'm not sure I'd rush to any conclusions just yet. I've never seen MPC-HC get the frame rate wrong, although I'm not sure I've ever opened raw h264 with it. It displays the frame rate more accurately than the MediaInfo GUI much of the time. For constant frame rates anyway. Variable frame rates are a potential for oddness using any program.

Edit: I think I've remembered. View/Statistics is enabled in the MPC-HC menu? I disable it so I forgot about it. Sorry about the confusion. Check it using the File/Properties menu.
I'm fairly sure what you're seeing is the rate at which the video is being decoded... not the frame rate of the video itself. Try Ctrl+J while a video is playing. The video frame rate and decoding rate should both display. The latter always changes a bit.... it only matters that it keeps up with the frame rate. If Ctrl+J doesn't display much of anything useful, select either VMR9 (Renderless) or EVR Custom Presenter as the renderer under View/Options/Playback/Output. If the frame rate is variable don't assume the displayed frame rate is correct. MPC-HC seems to just pick one to display. I recently finished encoding quite a few NTSC episodes of a TV show as variable frame rate and for those MPC-HC reports either 23.976 or 29.970. I'm sure the timebase used by the encoder for variable frame rate effects how MPC-HC sees it. For the video I encoded recently, x264 generally decided on a timebase of 1001/1 and for those, MPC-HC mostly says 23.976. I have some older Handbrake VFR encodes (probably a different timebase) and for those MPC-HC generally says 29.970, so I assume the timebase and frame rate both effect the reported frame rate for VFR video but I don't fully understand how that works.

One way to check frame rates is to mux the video as an MKV, open that with gMKVExtractGUI and extract the video time codes (text file). For a constant frame rate each frame should have the same duration, although for some rates it alternatives a little (between 41ms and 42ms for example) as the durations are rounded to the nearest millisecond. PAL's easier to check. Nice evenly spaced 40ms frame durations. Like this:

# timecode format v2
0
40
80
120
160
200
240
280
320
360
400

Thinking about it....
Can the frame rate of raw streams be variable? I guess the frames have timestamps so it's possible.... I'm speculating out load as I almost never output h264 or open raw video streams.

DoStudio doesn't accept MP4? AVI even?

It accepts .m2v, .m2p, .mpg, .mpeg, .vc1, .avc, .264 and .h264. It has no encoding ability of its own, so it needs the raw files.

Where are all the forum Premier frame serving experts. I can only make long distance guesses.
In theory the frame rate of a constant frame rate video shouldn't vary throughout the process. The frame rate is the frame rate whether it's processed and encoded at 2fps or 200fps, the processing time shouldn't matter, unless frames are being dropped somewhere but I don't see why that would be happening here.

The way I generally check the frame rate is to index the video with MeGUI, so you'd probably have to put it in a container first. Index with L-Smash, and when the script creator opens check the frame count and duration. Add frame rate conversion to the script (the correct one): ie

LWLibavVideoSource("E:\problem video.mkv", fpsnum=30000, fpsden=1001)

Refresh the preview. If nothing changes the video is already constant frame rate. If the frame count changes it's variable.
For variable frame rate sources without frame rate conversion in the script, if you add Info() to the end you'll probably see an odd frame rate, as you're seeing the average.

What's the current status? The chapters timing is sorted now? I think you said the audio sync was okay.... I've lost track.... but are there still issues with the final output or are we checking the accuracy of reported frame rates at the moment?

[koberulz]

Edit: I think I've remembered. View/Statistics is enabled in the MPC-HC menu?

Yes, that's what I was looking at. Okay, using the other thing then:

The AVS shows "Frame rate: 28.990 (34.483ms = 29.000, P)". Just guessing at the first number, it's flicking between 28 and 29 and the numbers after the decimal place are changing, and it's all happening so quickly it's impossible to read. Paused it at the number given, then restarted it and now it's stuck at 29 with the decimals still changing constantly (currently paused at 29.462). The numbers within the brackets are constant.

The .264 shows "Frame rate: 40.379 (16.683ms = 59.940, P)". Again, the numbers after the decimal place are changing, and after a pause-and-unpause it dropped to 39.xxx.

What's the current status? The chapters timing is sorted now? I think you said the audio sync was okay.... I've lost track.... but are there still issues with the final output or are we really just checking the accuracy of reported frame rates?

The audio of the initial MP4 was out of sync when used in Premiere (although it was fine in VLC), but not consistently. So I ran it through tsMuxer, and that fixed the problem.

Chapter markers were initially miles out when I had it marked as 29.97fps in DoStudio, now they're between half a second and four or five seconds out with it marked as 59.94. However, I can't get the pop-up menu to display. Setting it to 25fps and using a 25fps .264 file fixes the pop-up menu problem, so I'm guessing there's a good chance it's caused by whatever's going on with the video, and I'd like to get the chapter markers exactly where they should be even if they are currently much closer than they were.

[SameSelf]

You really should have put Premiere and some other clues in your subject because it sounds like your problem is MeGUI. I have never used that program, but I am not convinced that is where the problem lies. I have ignored this thread because of the MeGUI title, and now the thread has grown to such a length that I am not sure I understand completely what your problem is and what your have tried. However, here are my thoughts as a Premiere user who follows a very similar workflow for bluray authoring.

First, make sure PP is interpreting your footage correctly. It is possible that PP is interpreting your footage as interlaced when it is progressive or vice versa. I used to be fat dumb and happy when it came to this until I realized that PP often guesses wrong. So now as a rule I always double check.

Secondly, 29.97 fps content is problematic for bluray as it is not really supported. I don't use DoStudio, but maybe it doesn't like your elementary stream. Authoring programs can be finicky. For example, DVDA complains when I exceed 28 Mbps. Anyway, I convert all my 29.97 fps progressive footage to 59.94 fps and downrez to 1280x720:

ChangeFPS( 60000, 1001 )
Spline36Resize( 1280, 720 )

Of course, this will probably screw up your chapter markers. But, can you add them manually in DoStudio? It may be a pain, but given your problems, potentially a necessary evil.

Thirdly, why are you using ConvertToYV12()? Your MP4 should already be 4:2:0.

Lastly, why MeGUI? I would try just using x264 cli with something like this. Using a GUI just adds unnecessary overhead while encoding, IOW, tends to runs slower.

x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 60 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file

x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 60 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file

[koberulz]

You really should have put Premiere and some other clues in your subject because it sounds like your problem is MeGUI. I have never used that program, but I am not convinced that is where the problem lies.

I'm putting a 29.97fps AVS in, and getting a 59.94fps .264 out.

First, make sure PP is interpreting your footage correctly.

It is.

Secondly, 29.97 fps content is problematic for bluray as it is not really supported. I don't use DoStudio, but maybe it doesn't like your elementary stream. Authoring programs can be finicky. For example, DVDA complains when I exceed 28 Mbps. Anyway, I convert all my 29.97 fps progressive footage to 59.94 fps and downrez to 1280x720:

It's already 1280x720.

Of course, this will probably screw up your chapter markers. But, can you add them manually in DoStudio? It may be a pain, but given your problems, potentially a necessary evil.

The chapter markers themselves need to be added in DoStudio, but there's no ability to view the video file to determine chapter placement. Further, I'm using a .qpf file with MeGUI to make sure I have GOPs in the right spots. No idea how that would be affected by ChangeFPS.

Thirdly, why are you using ConvertToYV12()?

MeGUI seems to think not having it is a problem. Whenever I hit 'queue' to start encoding, if that line isn't in the script it pops up a message to point that out and ask if I'd like it to be added.

Lastly, why MeGUI? I would try just using x264 cli with something like this. Using a GUI just adds unnecessary overhead while encoding, IOW, tends to runs slower.

Because I had no idea the CLI existed, and I have no idea how to use it. Any time saved in encoding would be lost twice over in trying to figure out what I'm doing, and redoing things because I set things up wrong.

[koberulz]

Hang on...if 29.97 720p, which is what I'm inputting, isn't BD-compliant, could the bluray-compat thing be causing the change in frame rate?

[SameSelf]

OK, things are a little clearer now. It sounds like your footage is AVCHD 1280x720p29.97. It is most certainly 4:2:0, not 4:2:2, as AVCHD is a delivery codec, while 4:2:2 and higher are for intermediate codecs. MeGUI might be complaining because maybe you selected the wrong colorspace to frameserve out of PP. I haven't frameserved out of PP in a long time, but I seem to recall that YV12 should be available as an option. So double check that as well in the AFS options. It is important to avoid unnecessary conversions in your workflow.

Now ordinarily, unless you are applying some filters to the video (e.g. NR, sharpening, color correction, etc.) I would try to treat the footage in a lossless manner to avoid generational losses. I don't work with AVCHD very often, but I think PP will export AVCHD losslessly or pretty close versus frameserving and re-encoding which is what you are doing. It might depend on the PP version you are using. But at any rate, it doesn't matter. Your footage is 29.97 fps, and you are trying to author a BD, so you have to do something. If you don't believe me, just read the wiki, you will see that 29.97 fps is not listed.

https://en.wikipedia.org/wiki/Blu-ray

So, for 1280x720 content, you need to double the frame rate. As for what MeGUI is doing, I have no idea. Like I said, I have never used it. But I would think you are much better off putting these things in your Avisynth script rather than leaving things to MeGUI. If this screws up all you chapter markers, I don't know what to tell you. There may be a workaround in DoStudio. DVDA doesn't have this problem as I can easily see the video and go in and create markers manually.

Another option is to double the frame rate in PP. IOW, move the conversion further up in the workflow. But I don't know how easy doubling the frame rate is for inter-frame codecs. I never have to think to hard about these things because all my footage is ProRes which is intra-frame only.

In fact, the more I think about this, the more I think that you might be better off transcoding your AVCHD footage to an intermediate intra-frame codec before doing anything, including importing it into PP. It adds an extra step that can take a lot of time and hard drive space, but it greatly simplifies your workflow when these sorts of conversions need to be made (29.97->59.94). There are all sorts of issues you can run into. In fact, I have moved away from frameserving and even lossless intermediates and only use TIFFs now because of all these problems. I am not saying you have to do that. But transcoding to an intra-frame codec could be very beneficial in the long run.

Lastly, running x264 in the cli is a cinch. You just download the x264.exe to the same folder as your video. Go to Windows Start and type cmd for a command prompt. Navigate over to the folder where everything is and run the commands above. Simple. Of course, this means you have to get everything right in your Avisynth script. But like I already stated, your footage is very nearly BD compatible already. The ONLY problem is the frame rate and that is easily fixed.

[koberulz]

I haven't frameserved out of PP in a long time, but I seem to recall that YV12 should be available as an option. So double check that as well in the AFS options. It is important to avoid unnecessary conversions in your workflow.

RGB24, RGB32, YUY2 and UYVY are the available options. I've been using YUY2; I was told either of the latter two would do the trick.

If you don't believe me, just read the wiki, you will see that 29.97 fps is not listed.

https://en.wikipedia.org/wiki/Blu-ray

That's odd. The DoStudio manual lists it as valid, but only for 1080i.

I would think you are much better off putting these things in your Avisynth script rather than leaving things to MeGUI. If this screws up all you chapter markers, I don't know what to tell you. There may be a workaround in DoStudio. DVDA doesn't have this problem as I can easily see the video and go in and create markers manually.

Markers have to be on a GOP, though. MeGUI can read a .qpf file and place them on the frames listed; those numbers have to be accurate or there'll be slight differences.

In fact, the more I think about this, the more I think that you might be better off transcoding your AVCHD footage to an intermediate intra-frame codec before doing anything, including importing it into PP. It adds an extra step that can take a lot of time and hard drive space, but it greatly simplifies your workflow when these sorts of conversions need to be made (29.97->59.94). There are all sorts of issues you can run into. In fact, I have moved away from frameserving and even lossless intermediates and only use TIFFs now because of all these problems. I am not saying you have to do that. But transcoding to an intra-frame codec could be very beneficial in the long run.

It's only a personal project, and is the only time I can ever see myself working with 29.97fps video, so I'm not hugely fussed on dragging the absolute best out of it. If a 59.94fps sequence in Premiere looks okay, I'm happy to settle there.

[SameSelf]

Thanks for reminding me what the choices are for frameserving out of PP. YUY2 and UYVY are both Y'CbCr 4:2:2. RGB24 and RGB32 are both 8-bit RGB 4:4:4, the only difference being RGB32 adds a fourth alpha channel which is important when you are doing CG. Since your footage is 8-bit Y'CbCr 4:2:0, never choose RGB24/32; that is a very lossy conversion. But your AVCHD footage unavoidably gets uprezzed to 4:2:2 when frameserving as YUY2 or UYVY. Most likely the method used is bicubic for speed. Then you must convert it again to 4:2:0 in your Avisynth script. Trust me, these lossy 4:2:0 -> 4:2:2 -> 4:2:0 conversions add a bunch of noise/ringing/halos and other artifacts to your footage. More artifacts means x264 has a harder time encoding. This is one of the reasons why transcoding your footage at the very beginning can be beneficial because you have complete control over the uprez and downrez algos used. Maybe your footage would benefit from Spline36 or Blackman. I know this is a personal project, and the benefits might seem pointless or unnecessary. But these details are why studio DVDs and BDs look so good and home productions don't. At the end of the day, it's your video, and you can do what you want with it. I am just pointing out the unnecessary problems you are introducing into your workflow.

I really have no idea how PP handles frame rate conversions. I avoid those sort of conversion like the plague in PP or any NLE for that matter. But you are in a difficult pickle here, so hopefully it is just a simple doubling a la ChangeFPS.

[koberulz]

99.9% of what I put through this process starts as 1080i 25fps 4:2:2, so I'm disinclined to spend hours figuring out the exact best way to handle this particular footage.

The only other issue I'm having is I always have to include "ColorMatrix(mode="rec.601->rec.709")" in my script or the colours come out wrong. Or, at least, differently to Premiere, but when I captured a broadcast one time I flicked between that and my resulting Blu-Ray and the color-converted one was definitely right.

[SameSelf]

Color shifts are a major issue. The only way to be sure your workflow isn't causing any shifts in color is to test it with a color bar and scopes. See the lossless workflows link in my signature.

[hello_hello]

I've read through the new posts and have some thoughts....

The AVS shows "Frame rate: 28.990 (34.483ms = 29.000, P)

The decoding rate doesn't matter. "29.000, P" is the one to look at. Why isn't it 29.970 would be the question, and looking into that further might be good idea.

The .264 shows "Frame rate: 40.379 (16.683ms = 59.940, P)"

On the face of it you appear to have a script with a 29.000 frame rate being encoded as 59.940 (or 29.970) by MeGUI.

Hang on...if 29.97 720p, which is what I'm inputting, isn't BD-compliant, could the bluray-compat thing be causing the change in frame rate?

I've never seen that happen but I've never encoded for Bluray. I don't know if they would, but it might pay to check through MeGUI's log file for warnings about Bluray compliance to see if MeGUI or x264 are taking it upon themselves to make Bluray compliant adjustments. If you try to encode something that's not Bluray complaint that can't be adjust to make it compliant, there should always be warning in the log file, but I'm pretty sure x264 will fiddle with the aspect ratio for 720x576 or 720x480, so maybe it's adjusting the frame rate.

Here's a Bluray compliant 720p29.970 command line courtesy of --pulldown double. I can't remember how it's done... pulldown flags I assume.... but it should be complaint. It's under the Frame-Type tab in MeGUI's x264 encoder configuration. Maybe check MeGUI's log file to see if it was being applied on your behalf.
http://www.x264bluray.com/home/720p-encoding
x264 --bitrate XXXXX --preset xxxxx --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --open-gop --slices 4 --pulldown double --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file

At this point I'm most inclined to think there's only an apparent 29.000 and 29.970 frame rate difference to investigate, and hopefully there's an endeavor to make you Bluray complaint causing the problem. Have you checked absolutely, positively, no doubt at all, the source MP4 is really 29.970 with no frame rate variance? If it is, I don't know why Premier's frame serving at 29.000, or at least appears to be. I've never used it.

On the subject of Bluray compliance, the majority of Bluray players these days have those USB thingies for connecting a hard drive or USB stick. I know some players are format limited and I haven't befriended every player ever manufactured, but I've never met one that won't play standard High Profile, Level 4.1 via USB, no Bluray complaint settings required. My other half owns a Bluray player made before the Bluray-USB craze, but it'll play MKV and MP4 containing High Profile Level 4.1, you just have to burn them to disc as data files first.
Which has caused me to wonder.... how likely is it a player's going to happily decode High Profile, Level 4.1 from USB, but create a Bluray video disc and it'll spit the dummy, or would it just play what it can play? I suspect, although I've never been enthusiastic enough to test the idea, there may be no need to use the Bluray compliant settings unless you own an old, fairly primitive player, or you need to create a disc playable by any player that's ever existed. I probably should create one myself to see what the Bluray players here have to say about it. One of them will play video via USB with peak bitrates well over the maximum for Level 4.1, neither care the slightest about frame rate up to and including 1080p60, so to me it'd seem quite odd for them to spit out a Bluray disc because the video was encoded with -keyint250, or without --slices 4, or because it's 29.000p. Anything's possible though..... I guess.

[koberulz]

@SameSelf: Would outputting from Premiere as Lagarith YV12 be a suitable alternative to frameserving for 4:2:0 footage?

@hello_hello: How do I find the log file?

EDIT: Found it.

--[Information] [8/26/2016 02:43:33] changing --pulldown to double as it is required for encoding of 1280x720 with 30000/1001 fps for the selected device.

[hello_hello]

Lools like MeGUI is doing the fiddling, not x264, but it appears you selected Bluray as the target device in the encoder configuration so it's just doing as it's told. Not selecting Bluray as the target playback device but enabling all the necessary compatibility options might prevent MeGUI adjusting the frame rate. I suspect it will. Or you could copy and paste the required options into the custom command line section under the Misc tab, then deselect the target playback device.

There's no reason not to use a lossless intermediate rather then frame-serving. The latter has the advantage of requiring less time and less disc space, but if there's a problem... the one that works tends to be a good choice.
I'm not sure why frame-serving would effect the frame rate of the source though, and you haven't confirmed it's definitely 29.970.

Alternatively, let MeGUI adjust the frame rate and re-encode the audio to match. You'd have to manually create a script to open it and time stretch by an appropriate amount. Unless Premier has a similar ability. The chapters are probably adjustable with "some program" but I've not done it myself. I'd have to experiment. And there's the qp file too...

[koberulz]

Biggest reason to frameserve: I completely ran out of hard drive space three-quarters of the way through encoding a lossless AVI.

[hello_hello]

If I had to guess now it appears you have VFR MP4 with an average frame rate of 29.000, probably due to missing frames or "null" frames (duplicates that weren't encoded). To make it 29.970 you'd usually decode at a constant frame rate which would mean the decoder replaces the null frames with duplicates. If you simply assume/import at 29.000 the result won't be the same. The duration won't change but the audio will no doubt lose sync. Further down the chain (from frame-serving onwards) everything will appear normal, but the damage is done. ConvertFPS/ChangeFPS won't fix it. I'm pretty sure the only way to convert to CFR 29.970 is to decode it that way.

I don't know if that's a true story or the way Premier can import, but it seems the most logical one at the moment. I've written instructions on how to check the source MP4 frame rate and if it's constant a couple of times, and I've asked if you've verified it it a couple of times, but without that information I'm probably not going to come up with any better ideas.

Hopefully there's enough info here for you to track down the problem now, or maybe someone else will come along and offer a fresh perceptive. Good luck.

[koberulz]

Tried throwing it into a 59.94fps Premiere sequence, which just finished encoding. Sound is in sync from beginning to end, no issues there, but the pop-up menu still won't function. I had a 25fps video in there and it worked fine, just replaced it and it's broken the menu. It's now reporting 59.94fps in VLC, MPC-HC, and MediaInfo, unlike the previous output.

FWIW the original MP4 shows 29.97fps in MPC-HC. AME is busy working on something else at the moment, so I can't check the AVS.

EDIT: Threw together a brand new 59.94fps 720p Premiere sequence. Dropped in a Bars and Tone, dragged it out to about seven minutes, encoded as Blu-Ray compliant .m2v. Dropped that into my project...still no pop-up menu. So we've eliminated the source file and the encoding method as possible sources of the issue, leaving just DoStudio, which for some reason doesn't work with pop-up menus and 59.94fps playlists. Which makes no sense, but I also randomly get chapters springing up at one second and 29 frames, even in 25fps sequences, which can't even be deleted. And I paid a lot of money for this software.

EDIT 2: Forgot about the chapter markers initially. Just checked and they're all exactly where they're supposed to be. So other than the pop-up menu, the entire disc is working absolutely perfectly.

EDIT 3: Just for fun, I tried using the pop-up menu even though it wasn't working....and it worked. So it's there, it's just not actually visible. But if you've memorised the layout and can keep track of whether it's supposed to be on the screen or not, you can use it. Weird.

[SameSelf]

@SameSelf: Would outputting from Premiere as Lagarith YV12 be a suitable alternative to frameserving for 4:2:0 footage?

Since your footage is already 4:2:0, the only YUV options for frameserving are 4:2:2, and BD only accepts 4:2:0, then, yes, to avoid needless 4:2:0>4:2:2>4:2:0 conversions which will just add a bunch of artifacts to your footage that will degrade the final encode, writing out a lossless intermediate that is 4:2:0 would be preferred, maybe. The problem is that the only lossless pathway in and out of PP is AVI UYVY which is 4:2:2. All the others, including Lagarith, do strange things to footage and are not truly lossless. Again, see the lossless workflows thread in my signature.

However, since hard drive space is limited, I guess you are stuck with frameserving unless you have the budget for a larger hard drive. Working with HD video requires a lot of hard drive space. It is one of the reasons I moved all my data off my hard drives to bluray discs. An empty 2 TB hard drive for video projects is a wonderful thing.

I am glad you got everything working including the pop up menus. Congrads! I have often thought about learning DoStudio for the BD-J support. So your success gives me motivation. Getting a completed project is important. After every project, I often reflect about how I can improve the workflow. If you are dealing with a lot of 4:2:0 footage I would strongly consider adding a transcode to your workflow to make it 4:2:2 and 59.94 fps in a UYVY AVI container. That way you can push footage through PP losslessly, and all these problems magically go away.

[koberulz]

Like I said, 99.99% of what I use for Blu-Ray starts out as 4:2:2 25fps 1080i. If UYVY is 4:2:2, can I not just frameserve as UYVY, instead of YUY2? Cleaned out some hard drive space and put together a YV12 Lagarith AVI to use with MeGUI for a 4:2:2 1080i25 video I'm using in the same project, because I'd previously just run it through the frameserver and it looked weird around the edges of some things when there was movement. Saw some differences in the combing in Premiere between the final .264 and the initial .ts, so I gave the Lagarith file a shot. But the Lagarith AVI shows the same differences.

Original .ts:


Lagarith AVI:


400% zoom in Premiere. Zoom out and they both look identical as stills, but watching on a TV the resulting .264, showing the same combs as the AVI, looks weird around some areas. It only seems to affect certain colors, strangely. It looks very similar, if not identical, to what used to happen before I added "interlaced=true" to the ConvertToYV12 line in the AVS file. Seems fine in PowerDVD though.

I'm waiting on DoStudio tech support regarding the invisible pop-up menu before I try putting the 59.94fps file on a disc.

[koberulz]

Solved the menu issue, for the record: the menu was 1920x1080, the playlist was 1280x720. The menu was appearing below the bottom of the screen.

Can someone answer the UYVY question above, and does anyone have any suggestions about the interlacing issue?

[koberulz]

Anyone?