Print

[dakidark]

Ok, so using placebo3681's suggestion of encoding with a framerate of 25 and having no issues if the source is 25, I decided to see what would happen if I encoded at 25 fps with a source of 23.976. The results were pretty good. I did still notice one glitch with my movie, but it may have been the source or network. As far as I can tell there is no reoccuring glitch every 41 seconds. I'm going to try with another source and see what happens again, but if you all get some time and want to try this out, I'd be much appreciative to hear of your thoughts.

[xobx360]

First, thanks to impimpin and to chrislynch. These tutorials have been great, and I've read every page in both tutorials.

On the skipping issue, I changed the 23.976 to 24 on my input clip (even though it was auto-found to be 23.976), and on the format tab I set my output to 23.976. I'm noticing the skipping every 41-42 seconds as well.

I'll toss this out there to see if anyone can find a way to use it...
Notice that 24 - 23.976 = 0.024 seconds.
Now, notice that 0.024 * 41.667 = 1 second.

So, it would seem that every 41.667 seconds the frames are 1 second off where they should be, and either the key frames or some other mechanism is causing the video to skip back to where they should be.

[xobx360]

Alright, so at least for me, if my source is 23.976, then I get no skipping if I leave my input and output as both 23.976, not changing anything to 24. So until I run into some other problem, that's what I'm doing.

[zLensman]

QUOTE(dakidark @ Feb 8 2008, 11:51 PM)

Ok, so using placebo3681's suggestion of encoding with a framerate of 25 and having no issues if the source is 25, I decided to see what would happen if I encoded at 25 fps with a source of 23.976. The results were pretty good. I did still notice one glitch with my movie, but it may have been the source or network. As far as I can tell there is no reoccuring glitch every 41 seconds.

I tried this with a video encoded at 23.976 fps.  When I set the input fps to 25 in TMPGEnc Xpress, it does indeed make the 42 second glitch go away.  However, the motion is still not perfectly smooth for me.  It's different with this setting and hard to describe.  I would say it's smooth for a couple seconds, then there is a mild stutter, then it is smooth again.  Smooth, smooth, stutter, smooth, smooth, stutter.  I saw this in WMP11 on the PC and playing from a DVD-R on the Xbox 360.

This new stutter is less disruptive than the 42 second glitch when the input is set to 24 fps, but it happens more often.  It's watchable, but no good for archiving.  There is a problem here and changing the input fps fixes one thing but breaks something else, for me.  As mentioned before I'm not using CoreAVC, but I will be giving it a try soon.

Also, I've started calling that glitch a 42 second glitch, because it seems to be closer to 42 than 41.

[dakidark]

QUOTE(zLensman @ Feb 10 2008, 03:31 AM)

I tried this with a video encoded at 23.976 fps.  When I set the input fps to 25 in TMPGEnc Xpress, it does indeed make the 42 second glitch go away.  However, the motion is still not perfectly smooth for me.  It's different with this setting and hard to describe.  I would say it's smooth for a couple seconds, then there is a mild stutter, then it is smooth again.  Smooth, smooth, stutter, smooth, smooth, stutter.  I saw this in WMP11 on the PC and playing from a DVD-R on the Xbox 360.

This new stutter is less disruptive than the 42 second glitch when the input is set to 24 fps, but it happens more often.  It's watchable, but no good for archiving.  There is a problem here and changing the input fps fixes one thing but breaks something else, for me.  As mentioned before I'm not using CoreAVC, but I will be giving it a try soon.

Also, I've started calling that glitch a 42 second glitch, because it seems to be closer to 42 than 41.

I too noticed the glitch that is really hard to explain. It seems like it definitely is better, but still not where it should be. There should be some sort of fix for this.

[zLensman]

QUOTE(xobx360 @ Feb 9 2008, 10:16 PM)

I'll toss this out there to see if anyone can find a way to use it...
Notice that 24 - 23.976 = 0.024 seconds.
Now, notice that 0.024 * 41.667 = 1 second.

So, it would seem that every 41.667 seconds the frames are 1 second off where they should be, and either the key frames or some other mechanism is causing the video to skip back to where they should be.

Good catch!  I made the same calculation before and drew the same conclusion.  Just one thing that I have to point out: your math is correct, but your units are not.  I'm an engineer, so this was drilled into me in college.  Not to dis you, but if I didn't correct this, I would bring shame on my teachers and my father (also an engineer).

In the first equation, the units are fps - fps so the resulting units are still fps (or f/s) => 0.024 f/s
In the second equation the units are f/s * s so the resulting units are frames => 1 frame

So, every 41.667 seconds, the video is off by exactly 1 frame.  Like you, I believe that something is trying to correct this error and that correction results in what we have called the 41 or 42 second glitch.  I would like to know what is making the correction: TMPGEnc Xpress?  the DirectShow filter?  Knowing that might help resolve this issue.

[jacanuck]

Alright, I've done 2 encodes and watched them fairly carefully.  You guys are absolutely correct, approx every 40-42 seconds, it looks as though the frame rate is corrected.

I've just done a sample encode using the detected input frame rate (23.976) as the output frame rate, and so far, I don't see any corrections.

Why again did we chose "24" fps as the output method for this tutorial?  It doesn't make sense to adjust the frame rate from the source.

[xobx360]

QUOTE(zLensman @ Feb 10 2008, 02:52 AM)

Just one thing that I have to point out: your math is correct, but your units are not.  I'm an engineer, so this was drilled into me in college.  Not to dis you, but if I didn't correct this, I would bring shame on my teachers and my father (also an engineer).

No offense taken. I was once an engineer, so I should have gotten that right myself, but it was late last night when I calculated it and I was more focused on the numbers than the units. That makes more sense though, being off by one frame than one second. Getting off by a second would make a much bigger skip in the playback. The actual skip is a much quicker event.

To follow up on my last post, I tried encoding at 23.976 input and 23.976 output, to match my source, but now I have the constant stuttering issue for the first five minutes. It seems to be almost exactly five minutes. The rest of the video, including the 42 second skip, is fixed.

I may go back and get impimpin's method running again, since his avs script seemed to correct both the 42 second skip, and the 5-minute stutter. (I was having audio problems with his method before, but I think I have that corrected now.)

The other options I'm tempted to try: (1) playing with the prefetch video cache settings in TMPGEnc, under Options, CPU, multithread settings (right now both prefetch caches are unchecked; and (2) add 5 minutes of video to the front of my encode which I can trim back off after it's complete, to get rid of the stuttering in the beginning.

Anyone else have any experience with either of those?

[dakidark]

QUOTE(jacanuck @ Feb 10 2008, 01:18 PM)

Alright, I've done 2 encodes and watched them fairly carefully.  You guys are absolutely correct, approx every 40-42 seconds, it looks as though the frame rate is corrected.

I've just done a sample encode using the detected input frame rate (23.976) as the output frame rate, and so far, I don't see any corrections.

Why again did we chose "24" fps as the output method for this tutorial?  It doesn't make sense to adjust the frame rate from the source.

I think xobx360 summed it up in the last post about the video having that constant stutter for the first 5 minutes. It's not the normal 42 second stutter, but more along the lines of the one I get if I set all the framerates to be 25 , ie much smaller but constant.

In response to xobx360's post, I haven't fooled with the pretetch video settings, but my gut tells me that just prefetching the video and audio won't do it because I believe the issue falls under TMPGEnc trying to correct that framerate hole. I believe it is a TMPGEnc issue because the issue appears to be present for both those using coreAVC as well as ffdshow.

I know having the skip is good in the long run because it prevents the video from getting out of sync with the audio, but I think the overall issue at this point is what is causing the issue when encoding a 23.976 source to a 23.976 video. If the 5 minute stuttering issue can be fixed, the whole issue goes away and we don't have to deal with the 42 second stutter.

[xobx360]

QUOTE(dakidark @ Feb 10 2008, 02:21 PM)

In response to xobx360's post, I haven't fooled with the pretetch video settings, but my gut tells me that just prefetching the video and audio won't do it because I believe the issue falls under TMPGEnc trying to correct that framerate hole. I believe it is a TMPGEnc issue because the issue appears to be present for both those using coreAVC as well as ffdshow.

My thought with the prefetch goes back to someone's comment in the middle somewhere of impimpin's thread. Someone mentioned it and then no one followed up on it.

It seems that encoding at 23.976 for a 23.976 is the way to go to fix the 42-second skip, but that causes the 5-minute stutter in the beginning. It seems TMPGEnc might have a cache which takes about 5 minutes to get up and running, I'm wondering if using a video/audio prefetch might build up that cache from the very beginning and fix the early stutter. Of course if that were the case, then the 5-minute stutter should happen all the time, which it doesn't for me - only when using 23.976fps, not when using 24fps.

I agree, I'm increasingly convinced that this is a TPMGEnc issue, so I'll check with their support as well.

Anyway, that's my next trial-and-error test for tonight, I just haven't had time yet to check it out.


This post has been edited by xobx360: Feb 10 2008, 08:56 PM

[chrislynch]

Well, I am back from vacation, and I'm glad to see people posting.

I firmly believe this to be an issue with TMPGEnc, and not any other source.  If you use WMP11 or MPC (with the internal filters disabled), you are in affect using DirectShow, which is what TMPGEnc will use.  I believe that their internal video render is trying to compensate NTSC and PAL video with time shifting.

I wonder if anyone can please chime in with how they are viewing the final product.  Are you viewing it on your local PC?  Streaming it from your PC to your 360?

24FPS always works for me, and I stream my video across an 802.11n wireless network without issues.  I do make sure that Diskeeper is not set to auto-defrag my 1TB drive (where my video content is stored.)

I will be posting an update to the tutorial later this week.  I had some time to put some new things together.  I'm also thinking about adding other apps like Microsoft Web Impressions (the replacement to Windows Media Encoder), and quite possibly WME itself.  Let me know if that would help anyone.

[xobx360]

QUOTE(chrislynch @ Feb 10 2008, 03:37 PM)

I wonder if anyone can please chime in with how they are viewing the final product.  Are you viewing it on your local PC?  Streaming it from your PC to your 360?

Welcome back, Chris. I'm viewing my finished product locally an my PC using WMP11, locally with VLC, and streaming to my xbox over a wired connection, and I get the same 42-second skip and 5-minute stutter using all three playback methods.

I get the quick skip every 42-seconds throughout the entire video when I choose 24fps as my input while using a source with 23.976fps. Easy to notice if I encode a quick sample of a movie's scrolling credits, because it's easy to see the skip as the text scrolls by.

If I encode using 23.976fps to match my source, then I don't get the skip every 42-seconds, but the first few minutes of my video stutter. It's almost constant, just a very un-smooth playback for the first five minutes, as if it's playing every other frame (though VLC says I'm not dropping any frames). Then after that first few minutes everything is smooth for the rest of the video.

Neither of these issues creates any problem with audio-video synch. My audio remains synched and smooth throughout.

Finally, the 5-minute stutter seems harder to troubleshoot - if I do a short sample clip from the middle of my source, I get no stutter in the sample. It needs to be a full encode (or maybe a clip from the beginning of my source?) to see the stutter. Happens with all of my sources, though.

This post has been edited by xobx360: Feb 10 2008, 10:41 PM

[chrislynch]

QUOTE(xobx360 @ Feb 10 2008, 01:39 PM)

Welcome back, Chris. I'm viewing my finished product locally an my PC using WMP11, locally with VLC, and streaming to my xbox over a wired connection, and I get the same 42-second skip and 5-minute stutter using all three playback methods.

I get the quick skip every 42-seconds throughout the entire video when I choose 24fps as my input while using a source with 23.976fps. Easy to notice if I encode a quick sample of a movie's scrolling credits, because it's easy to see the skip as the text scrolls by.

If I encode using 23.976fps to match my source, then I don't get the skip every 42-seconds, but the first few minutes of my video stutter. It's almost constant, just a very un-smooth playback for the first five minutes, as if it's playing every other frame (though VLC says I'm not dropping any frames). Then after that first few minutes everything is smooth for the rest of the video.

Neither of these issues creates any problem with audio-video synch. My audio remains synched and smooth throughout.

Finally, the 5-minute stutter seems harder to troubleshoot - if I do a short sample clip from the middle of my source, I get no stutter in the sample. It needs to be a full encode (or maybe a clip from the beginning of my source?) to see the stutter. Happens with all of my sources, though.

I saw above that you were using ffdshow to decode x264 video.  I do not support, nor work with ffdshow to decode x264 video.  Please use CoreAVC if at all possible.  The 5-minute stutter has been linked to ffdshow in the other post with impimpin's tutorial.  If you cannot, jacanuck has a reg file posted on his site that should fix the stuttering issue.  Again, I do not help you further with ffdshow.

As for the intermittent stutter every 42 seconds, I have not experienced that at all, except where I have Diskeeper 2007 (and upgraded to 2008) where if I left Autodefag enabled, I would get lousy playback.  If you do have any sort of automatic defrag tool, or real-time virus scanning tool, I highly suggest you disable or exclude the directory where you host your video.

[xobx360]

QUOTE(chrislynch @ Feb 10 2008, 05:04 PM)

I saw above that you were using ffdshow to decode x264 video.  I do not support, nor work with ffdshow to decode x264 video.  Please use CoreAVC if at all possible.  

I previously used ffdshow under impimpin's method, but I have since uninstalled everything and only installed the items in your tutorial. ffdshow is no longer installed, nor has it been since I began posting in your thread. So this shouldn't have anything to do with ffdshow.

QUOTE(chrislynch @ Feb 10 2008, 05:04 PM)

As for the intermittent stutter every 42 seconds, I have not experienced that at all, except where I have Diskeeper 2007 (and upgraded to 2008) where if I left Autodefag enabled, I would get lousy playback.

I don't have autodefrag, and my virus scan doesn't seem to be the issue. The 42-second stutter isn't intermittent. It's every 42 seconds; I can sit with a stop watch and hit it every time. I'm positive this is an issue with 24fps vs 23.976fps, and only happens when I choose 24fps as my input even though my source is 23.976.

I'm going to do some more troubleshooting on my end, though, and will post back if I ever track anything down.

Thanks again

[dakidark]

QUOTE(xobx360 @ Feb 10 2008, 06:32 PM)

I previously used ffdshow under impimpin's method, but I have since uninstalled everything and only installed the items in your tutorial. ffdshow is no longer installed, nor has it been since I began posting in your thread. So this shouldn't have anything to do with ffdshow.
I don't have autodefrag, and my virus scan doesn't seem to be the issue. The 42-second stutter isn't intermittent. It's every 42 seconds; I can sit with a stop watch and hit it every time. I'm positive this is an issue with 24fps vs 23.976fps, and only happens when I choose 24fps as my input even though my source is 23.976.

I'm going to do some more troubleshooting on my end, though, and will post back if I ever track anything down.

Thanks again

I've been having the exact same issues with the same setup. The issue appears in local playback on the PC, wired network streaming, and with USB playback (HFS+) on the xbox. I too am using coreAVC along with only the items mentioned in the tutorial. I currently have no program setup to defrag (it's two 10000 RPM HDDs in RAID 0, so speed shouldn't be a factor) and no antivirus installed. To simplify, the issues are listed below:

23.976 Source (treated as 23.976), outputted to 23.976-> Stuttering for first 5 minutes, perfect afterwards
23.976 source (treated as 24), outputted to 24 -> A skip every 42 seconds in the playback. Very subtle, but definitely there