if i use an mp4 file for encoding with 23.97 fps it lags at the output, but

[zanzar]

why when i encode an mp4 file (that runs at 23,97 constant fps) the out put is choppy (i also set it to encode at 23.97 fps)
but when i set the fps to 29.97 fps at the out put it comes out smooth with no chopping

why is that?
here is the script i use

SetMtMode(5,4)
v = LWLibavVideoSource("d:\4.mp4", fpsnum=24000, fpsden=1001, format="YUV420P8")
a = LWLibavAudioSource("d:\4.mp4")
AudioDub(a,v)
ConvertToYV12()
ColorYUV(cont_y=-5, cont_u=0, cont_v=0,gamma_y=-20)
ColorMatrix(mode="rec.601->rec.709")
nnedi3_rpow2(2, cshift="spline36resize", fwidth=1280, fheight=720)
aWarpSharp(depth=10)
Sharpen(0.5, 0.5)

[sneaker]

Post a sample file.

[zanzar]

it doesnt matter what mp4 file it is so a sample would not matter

here is a media info

Format : Matroska
Format version : Version 4 / Version 2
File size : 168 MiB
Duration : 29mn 53s
Overall bit rate : 784 Kbps
Encoded date : UTC 2013-10-24 18:00:43
Writing application : mkvmerge v6.5.0 ('Isn't she lovely') built on Oct 20 2013 12:50:05
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 29mn 53s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 132 r2309 3b1f1f7
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 29mn 53s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Frame rate : 46.875 fps (1024 spf)
Compression mode : Lossy
Delay relative to video : 9ms
Default : Yes
Forced : No



maybe the problem is with LWLibavVideoSource settings?

[manono]

it doesnt matter what mp4 file it is so a sample would not matter

Nonsense. Sneaker shouldn't even have had to ask. You should have posted a sample with your original post. And not only a sample of the jerky output file, but a sample from the 'source'.

And both are MP4? Why are you doing this? Just to blow it up to 'hi-def'? Do you think it'll somehow look better?

...but when i set the fps to 29.97 fps at the out put it comes out smooth with no chopping

I don't believe you.

[zanzar]

it doesnt matter what mp4 file it is so a sample would not matter

Nonsense. Sneaker shouldn't even have had to ask. You should have posted a sample with your original post. And not only a sample of the jerky output file, but a sample from the 'source'.

And both are MP4? Why are you doing this? Just to blow it up to 'hi-def'? Do you think it'll somehow look better?

...but when i set the fps to 29.97 fps at the out put it comes out smooth with no chopping

I don't believe you.

well it does and i have other reasons i just need to know what causing the problem and ill be on my way
what a sample would help if it happends on all mp4 file i have with this scrips it goes for me like this
23.97 -> 23.97 choppy frames
23.97 -> 29.97 runs fine

all i do its change the value of fpsnum=24000 to 30000 to change it to 29.97

all i do it change the value

[hello_hello]

Don't use the frame rate conversion unless you need to. I'm not sure why (probably due to frame rate jitter), but sometimes even when the input frame rate is the same as the output frame rate it causes frames to be incorrectly dropped/duplicated. If you need to use frame rate conversion and it causes a choppy output, try ffms2 (FFVideoSource) instead. It's frame rate options are exactly the same as LSmash, although for ffms2 if you have problems try also adding threads=1. If one of them causes choppy output with frame rate conversion try the other. If none of that works, try remuxing the source file to a different container and using that as the source to see what happens. That's my first guess.

Create a script to open the source video without any frame rate conversion, check the total frame count, open the source with frame rate conversion and check again. If the total frame count doesn't change, you don't need frame rate conversion (unless you're trying to change the frame rate). If it does, make sure you're specifying the correct frame rate. That's guess number two.

Setting the frame rate to 29.970 might give you smoother output, but it'll still be choppy if the source is 23.976 as every fourth frame will be duplicated.
You could also do this:
LWLibavVideoSource("d:\4.mp4", fpsnum=30000, fpsden=1001, format="YUV420P8").TDecimate

29.970 followed by TDecimate to remove the duplicate frames should give you a smooth 23.976 if the source is 23.976, which is kinda pointless though (and I'm not sure TDecimate supports YUV420P8).
Even if MediaInfo says the source is constant frame rate 23.976, it doesn't mean it is (I'll upload an example if you don't believe me). It could be variable frame rate and MediaInfo is getting it wrong.

Is the file from your earlier post the source file?
Frame rate : 24.000 fps
Original frame rate : 23.976 fps
If so it means for some reason MediaInfo sees the video stream frame rate (23.976) as different to the container frame rate (24). Now if LSmash is decoding at 24fps and you add fpsnum=24000, fpsden=1001...... that's "no sample" guess number three as to why the output is choppy.

By the way.... the main reason I can offer those suggestions is because I use frame rate conversion regularly myself. If you'd uploaded a sample someone else would no doubt have made an effort to help. To be honest, when I saw you'd refused to upload one I almost didn't bother typing this post. Helping those who won't help you to help them and all that. Uploading a sample would probably have taken less time than I spent typing this post. Please do so next time, or this time, if none of my ideas fix the issue.

[zanzar]

Don't use the frame rate conversion unless you need to. I'm not sure why (probably due to frame rate jitter), but sometimes even when the input frame rate is the same as the output frame rate it causes frames to be incorrectly dropped/duplicated. If you need to use frame rate conversion and it causes a choppy output, try ffms2 (FFVideoSource) instead. It's frame rate options are exactly the same as LSmash, although for ffms2 if you have problems try also adding threads=1. For whatever reason if one of them causes choppy output with frame rate conversion try the other, although ffms2+AVI tends to be prone to choppy output when frame rate conversion is used. If none of that works, try remuxing the source file to a different container and using that as the source.

Create a script to open the source video without any frame rate conversion, check the total frame count, open the source with frame rate conversion and check again. If the total frame count doesn't change, you don't need it (unless you're trying to change the frame rate). If it does, make sure you're specifying the correct frame rate.

Setting the frame rate to 29.970 might give you smoother output, but it'll still be choppy if the source is 23.976 as every fourth frame will be duplicated.
You could also do this:
LWLibavVideoSource("d:\4.mp4", fpsnum=30000, fpsden=1001, format="YUV420P8").TDecimate

29.970 following with TDecimate to remove the duplicate frames and should give you a smooth 23.976 if the source is 23.976, which is kinda pointless though.
Even if MediaInfo says the source is constant frame rate 23.976, it doesn't mean it is (I'll upload an example if you don't believe me). It could be variable frame rate and MediaInfo is getting it wrong.

Is the file from your earlier post the source file?
Frame rate : 24.000 fps
Original frame rate : 23.976 fps
If so it means for some reason MediaInfo sees the video stream frame rate (23.976) as different to the container frame rate (24). Now if LSmash is decoding at 24fps and you add fpsnum=24000, fpsden=1001...... there's another "no sample" guess as to why the output is choppy for you.

By the way.... the main reason I can offer those suggestions is because I use frame rate conversion regularly myself. If you'd uploaded a sample someone else would no doubt make an effort to help. To be honest when I saw you'd refused to upload a sample I almost didn't bother typing this post. Helping those who won't help you to help them and all that. Uploading a sample would probably have taken you less time than I spent typing this post. Please do so next time, or this time if none of my ideas fix the issue.

thanks you for your post.
i didnt want to post a sample because i thought is was unnecessary as it happens to me with any mp4 file with 23.97 fps

i guess i didnt touch mp4 files for so long i forgot that i dont even need the "fpsnum=24000, fpsden=1001, format="YUV420P8" and i coult just delete it
after deleting it it fixed it right a way
strange thing is that even with the line the total frames didnt change one bit but still became imidiattly choppy when played in AVSPMOD

[hello_hello]

i guess i didnt touch mp4 files for so long i forgot that i dont even need the "fpsnum=24000, fpsden=1001, format="YUV420P8" and i coult just delete it
after deleting it it fixed it right a way
strange thing is that even with the line the total frames didnt change one bit but still became imidiattly choppy when played in AVSPMOD

My "theory" goes like this.....
The display duration for 23.976fps is 41.708333333333333333333333333333ms per frame. Depending on the timebase used by the encoder that'll be rounded some way or another. The timecodes for a 23.976fps MKV tend to look like this:

# timecode format v2
0
42
83
125
167
209
250
292
334
375

Frame durations are rounded to whole milliseconds and some are 42ms while others are 41ms.
I suspect that "jitter" can be one of the causes of choppy output when you use frame rate conversion. Sometimes frames are dropped when they shouldn't be and others are duplicated, but the total frame count remains correct. It's probably a contributing factor, although I've seen the same thing happen for 25fps where each frame duration is exactly 40ms. For some reason though, it's rare for LSmash and FFMS2 to have problems with the same video when using frame rate conversion, so if one outputs choppy video, try the other, and as I said, don't use frame rate conversion unless you have to.

Cheers.

[sneaker]

Yes, jitter could be a factor. There are different ways to calculate the dropping/repeating:
http://forum.doom9.org/showthread.php?t=165045

I tried to reproduce the issue with some jittery mp4's without result. Tried mkv => stutter due to bad decisions. But not all mkvs, depends on timecode precision. Of course this makes me even more interested in a mp4 sample that shows the same problem.

[johnmeyer]

why when i encode an mp4 file (that runs at 23,97 constant fps) the out put is choppy (i also set it to encode at 23.97 fps)
but when i set the fps to 29.97 fps at the out put it comes out smooth with no chopping

The reason you need to post a sample, and why you have already received several requests to do so, is that "choppy" is a completely inadequate description of the problem. There are at least half a dozen things that could be described as "choppy," including:

• Dropped Frames
• Pulldown (correctly done)
• Incorrect Pulldown
• Uncompressed video (many hard drives can't keep up)
• Unusual codec (some codecs are difficult to decode)
• Slow computer (background processes, etc.)
• Streaming video (many streaming connections are not robust)
• Lousy media player (some do not play certain videos smoothly)
• Reversed fields (no usually described as "choppy," but quite common, and it does produce a stutter effect)

So, you will never get a useful answer unless you post a sample because the solutions to each of these problems are completely different. And, perhaps, your video may have more than one problem

[hello_hello]

Yes, jitter could be a factor. There are different ways to calculate the dropping/repeating:
http://forum.doom9.org/showthread.php?t=165045

I tried to reproduce the issue with some jittery mp4's without result. Tried mkv => stutter due to bad decisions. But not all mkvs, depends on timecode precision. Of course this makes me even more interested in a mp4 sample that shows the same problem.

I haven't been able to make an MP4 that has stuttering problems with frame rate conversion, and I'm not sure I've ever met one as I rarely work with MP4. Sometimes I think the way a video is muxed makes a difference but I don't understand how that works. Maybe zanzar will return with a sample. I wonder if the video stream frame rate and the container frame rate being slightly different might have been the cause there (23.976 and 24).

I've attached an AVI. There's a section in the middle that stutters for days when I index with ffms2 with frame rate conversion. When I remux the entire AVI the same happens. When I remux just the section in question (which I've attached), most of the stuttering goes away. I'm attaching it though because there's still a little stutter at around 9 seconds but it's 25fps, so there shouldn't be any jitter if the timebase is accurate to 1ms.

What I don't understand though, is if I remux that partiular AVI as an mpeg4 with ffmpeg, it won't play properly in MPC-HC. I thought that might be ffmpeg being a bitch about packed bitstreams, but the mp4 plays normally in MPC-BE. There was some complaining about "timestamps being unset" in the ffmpeg log file, but I don't know if I should care. Computers....

I'll have another play around tomorrow to see if I can make an MP4 that doesn't play well with frame rate conversion.

[johnmeyer]

I see no stutter with test.avi. test.mp4 plays fine using VLC. So, no issues here with either clip.

[hello_hello]

test.avi stutters for me when I open it like this.

LoadPlugin("C:\Program Files\ffms2\ffms2.dll")
FFVideoSource("E:\test.avi", threads=1, fpsnum=25, fpsden=1)

When I say stutter, there's a couple of repeated frames at about the 9 second point, just before the woman sits down. For some reason the majority of the stuttering went away after I split off the section as a sample.

I didn't try test.mp4 with VLC. I tried it with MPC-BE and it was fine. It's not with MPC-HC, which I'd consider to be an issue.

[poisondeathray]

test.avi stutters for me when I open it like this.

LoadPlugin("C:\Program Files\ffms2\ffms2.dll")
FFVideoSource("E:\test.avi", threads=1, fpsnum=25, fpsden=1)

When I say stutter, there's a couple of repeated frames at about the 9 second point, just before the woman sits down.

I can replicate this with ffms2, it's around 8sec. But if you don't include the fpsnum/den , it's fine. info() says it's 25.0 FPS (25/1) perfect to begin with so technically fpsnum/fpsden shouldn't be doing anything. Very weird .

Doesn't affect l-smash fpsnum, fpsden .

I would suggest making a bug report but there seems to be very little interest in ffms2 anymore from the developers, only l-smash

[hello_hello]

A bug report was submitted when the ffms2/AVI issue was first discovered and reported in the doom9 MeGUI thread. At that stage the problem only seemed to effect ffms2 and AVI with frame rate conversion, but in the mean time experience has taught me the problem's not limited to that combination, just a lot more likely to occur.

Even two years ago, there was a total lack of interest.
http://forum.doom9.org/showthread.php?p=1679217#post1679217

Initially I thought it was a muxing problem, and the way an AVI is muxed may contribute to it, but I've since learned it's not just an AVI issue.
http://forum.doom9.org/showthread.php?p=1679320#post1679320

If I can find an MKV that has the same problem when decoded by lsmash with frame rate conversion I'll try reporting it in the lsamsh thread. I know it's happened, as if I re-encode an AVI I generally remux it as an MKV first (to reduce the likelihood of it happening) and I remember re-encoding a season of a TV show before noticing how jittery it all was. I'd still have the AVIs, but at the moment I can't recall which show it was. Hopefully it'll come back to me.

The main motivation for MeGUI adding frame rate conversion to scripts is because neither ffms2 or lsmash handle null frames in AVI's correctly (in my opinion). If there's a few null/dropped frames they output the average frame rate and the audio sync is lost. Given AVI is inherently constant frame rate they should decode AVIs as AVISource does, which replaces null frames with duplicates and I've not known it to cause stuttering issues. If memory serves, AVISource replaces a missing frame with a copy of the following frame, whereas ffms2 replaces it with a copy of the previous one. Not that I think it matters.

I don't know how easy it'd be to implement, but in my opinion there should be a threshold for ffms2 and lsmash to consider video to be variable frame rate. It doesn't matter what the container is, a video can be seven hours long but if there's five null/missing frames they'll both treat it as variable and output the average frame rate. It seems to me they should assume constant frame rate and replace the missing frames with duplicates, at least up to a point, and that sort of thing could maybe be implemented according to the frame durations. If there's 30574 frames with a 40ms duration and sixteen frames with an 80ms duration, treating it as 25fps constant frame rate seems logical, and then frame rate conversion wouldn't be required. Instead, they both output something like 24.95fps (I'm guessing) rather than fill in the blanks with duplicate frames. That's how I'd do it if possible, but maybe I'm dreaming.......

One more thing that bugs me about lsmash (and maybe ffms2) is by default it doesn't honour pulldown flags. I think it should (as DGDecode does). Instead, 23.976fps with pulldown is decoded as 23.976fps progressive, and 29.970fps is decoded as 29.970fps progressive, and when you have a source which contains a combination of both it's treated as variable frame rate and you get the average frame rate instead. To avoid that, I'm pretty sure you need to manually enable the honouring of pulldown flags or use frame rate conversion, or encode it as variable, whatever is appropriate. Maybe that's a clever way to do it and I just don't get it, but I'd rather have a constant 29.970fps output, even if there's lots of repeated frames, and decide for myself how best to tackle it from there.