View Full Version : Stuttering problem on standalone
Roman Helmet
24th May 2004, 04:40
I just got an NEC ND-2500a dvd burner. I have been fooling around with it and finally decided to burn a video dvd. I got dvd lab and tmpeg plus. I encoded the videos of Initial D Second Stage with Constant Quality and gave them ac3 audio. I went through dvd lab and made menu's and pieced everything together like in the doom9 guide for dvd lab. Now, when I play the dvd that results in my standalone player, the Pioneer DVR 810H, the video and audio stutters. The m2v files that I get out of Tmpgenc don't stutter. What am I doing wrong? I know it's not how I am burning the disc. I burned it from an ISO, in dvd lab from the compiled folders, and in nero, and it never worked fine. I have a commercial dvd of mine that I made a 1:1 of that works fine. Does anybody have any idea what's wrong?
Have you encoded with the correct field order? Computers display video progressively, so they don't necessarily show any problems during playback of incorrectly field-ordered material, whereas playing such material back on an interlaced display unit (i.e. a television) will result in apparent stuttering.
Also check that you are using decent quality DVDR media, since poor quality media can result in an inconsistent supply of data to the player, resulting in stuttering playback (I've experienced this myself, when I first began buying DVDR disks - most notably towards the outer regions of cheap disks, where playback would stutter so much that playback would actually halt).
Also check, using BitRate Viewer (http://www.tecoltd.com/bitratev.htm) (or even DVD Lab's integrated bitrate viewer), that you do not have MPEG streams that exceed the maximum spec-compliant bitrate. I have done a massive amount of testing recently with Seamless-Branching, and these interleaved types of MPEG streams place very stringent demands on maximum bitrate. I found that TMPGEnc worked fine for 2xVBR encodes, but was not so reliable if I used Constant Quality. Having said that, I would expect DVD lab to realise if you tried to use streams with excessive bitrate spikes, but it's worth checking if the above suggestions don't reveal your problem to you.
Arky ;o)
Roman Helmet
24th May 2004, 21:03
I encoded the file with interlaced video, so I don't think that is it. Also, I believe the bitrate is okay, I fit ep 23 minute episodes on the disc.
My media is Fuji DVD+R's I got from Best Buy. They cost me a pretty penny, so I don't think they are at all cheap. I have burned other iso's i made of my dvds, and they work fine on this media.
I did use the HVS-Good matrix which I am beginnig to think might be the problem, I made a couple test videos to see.
Here is an off topic question, can dvds have video with a framerate of 23.976? DVD lab did an IVTC i think to the video when I imported it from one of my clips. (I think it was IVTC, it said it was 2:3 pullover-ing it or something like that.) I thought dvd could be that framerate.
Originally posted by Roman Helmet
I encoded the file with interlaced video, so I don't think that is it.
Interlaced, yes, but there are two field orders - my question referred to which of these field orders you had chosen when encoding. If you encoded with the field order the wrong way round, then they will be presented in the wrong order, temporarily-speaking. In other words, one will be presented before the other, when it should be the other way around. This means that, with fast-moving footage, one set of the interlaced scanlines appears to 'jump back' after it's partnering set of scanlines has been played, instead of smoothly continuing the forward motion that would have been displayed if it had been played earlier rather than later. Bit difficult to describe in words, especially with a hangover! :D I suggest you re-encode using the opposite field order to whatever you used last time. As I said previously, you probably won't notice any difference on a computer screen, since both fields are displayed progressively (i.e. at the same time). It is only when you burn to disk and view on your interlaced television display that you will see if you have got things right.
On the subject of disks, the Fujis should be fine, so yes, I think we can be satisfied that they are not the cause of your problem.
Arky ;o)
Roman Helmet
25th May 2004, 20:57
Well, I have been using the bottom field first(field b), i know what you mean, but that's not the kind of jerkyness I am talking about. The video actually stops for a fraction of a second and the audio follows suit. BTW, the tv that I am playing these on is an hdtv that is progressive scan compatible so the field order and all that shouldn't even matter. It displays the video progressive in the first place, skipping the whole interlaced problem. Or maybe I'm wrong, but I don't think so.
Well, your TV (which sounds very nice, BTW!) might be capable of displaying images progressively, but that does not mean that your DVD player is necessarily capable of feeding it with a progressive signal. Although I am unable to take advantage of it, my Limit DVD player does offer progressive scan output, but this needs to be specifically enabled in the firmware menu.
DVDlab does not currently produce projects that verify 100% error-free, but I would be very surprised if it were multiplexing your streams so as to yield the errors you have described. My feeling is that this is probably a source material issue and I still feel that you should experiment by re-encoding with the opposite field order, just to see what happens. It's a process of elimination. I am, of course, assuming that you have used the Fuji media successfully in the past with other projects...
Arky ;o)
Roman Helmet
26th May 2004, 21:23
Well, I fixed the problem. I do know my dvd player is progressive compatible, my dad just bought it. It's a Pioneer DVR 810H. It's got dvd, TIVO, and a DVD-R/W burner. Nice unit. I believe it's about $800-900. My dad wanted to finally buy himself some nice stuff. Also, the tv says when it's in progressive mode, so I know it was.
So, on to how I fixed it. I tried switching the field order because I have done just about everything else. The problem was immediately fixed. I am so glad that's all it was. Thanks for the suggestion.
BTW, I am glad it wasn't the HVS-good matrix I was using. That was something else I tried changing to see if it would make it play smoothly. With the TMPGEnc mpeg default matrix, the file encoded exactly the same otherwise was 350 megs or so larger than with the HVS-good. I highly recommend this matrix. Oh yeah, and the file is 23 minutes long, so that saves me a ton of room for an entire dvd.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.