VideoHelp Forum
+ Reply to Thread
Page 1 of 3
1 2 3 LastLast
Results 1 to 30 of 63
Thread
  1. I had a close call recently when I authored a 52 minute, 23.97fps 352x480 XSVCD program using VCDimager.

    First, my chapter references (which were accurate to the frame) generated an exception list as follows:

    --DEBUG: requested entry point at 0.000000, closest possible entry point at 0.000000
    --DEBUG: requested entry point at 572.614000, closest possible entry point at 572.613711
    --DEBUG: requested entry point at 911.744000, closest possible entry point at 911.744167
    --DEBUG: requested entry point at 1781.780000, closest possible entry point at 1781.780000
    --DEBUG: requested entry point at 2377.792000, closest possible entry point at 2377.792089
    --DEBUG: requested entry point at 2839.920000, closest possible entry point at 2839.920422

    Small potatoes, maybe, but why should there be any difference at all between the entry points I specified and the ones that were discovered? What time base is VCDimager using to even measure the difference?

    Second, the authored XSVCD had the problem of progressive audio desynchronization. The longer the program played, the farther the audio trailed behind the video. This really scared me, because I thought at first my Pioneer DV-333 (which plays progressive [i.e., 23.97fps] sources flawlessly) might be to blame.

    Turns out it was VCDimager.

    I authored the same MPEG using Nero (sans all the fancy features of course) and it played flawlessly from end to end. Not only that, it gave me an elapsed time readout on my DVD player which no VCDimager-authored disc ever has.

    What's up with VCDimager, exactly?

    Why does it behave this way?
    Quote Quote  
  2. I experienced a couple of the same issues (audio desync, time readout) on my DV-343. As far as I could determine, Pioneers don't like the 23.976 fps framerate natively, it only works correctly if a 2:3 pulldown flag is applied (?)

    As for elapsed time readout, it seems to work on Pioneers if the disc has no PBC! I've created several simple SVCD discs with VCDEasy and VCDImager 7.11 that displayed elapsed time. The moment I author the same video in TSCV with a menu and/or PBC, though, it doesn't do it anymore. Go figure...
    Quote Quote  
  3. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    On 2001-12-28 18:58:50, KoalaBear wrote:
    First, my chapter references (which were accurate to the frame) generated an exception list as follows:
    --DEBUG: requested entry point at 572.614000, closest possible entry point at 572.613711</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    For this particular entrypoint, I presume you were putting an entrypoint at frame 13729. Both your time reference and the one found by VCDImager were the same frame. The same is true for all your entrypoints I believe.

    As for how VCDImager calculates the time for these entrypoints, I don't know -- you could always read the source code.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Small potatoes, maybe, but why should there be any difference at all between the entry points I specified and the ones that were discovered? What time base is VCDimager using to even measure the difference?</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    As before. BTW, your own time references are only accurate to three decimal places and not "exact", but it doesn't really need to be.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>Second, the authored XSVCD had the problem of progressive audio desynchronization. The longer the program played, the farther the audio trailed behind the video. This really scared me, because I thought at first my Pioneer DV-333 (which plays progressive [i.e., 23.97fps] sources flawlessly) might be to blame.

    Turns out it was VCDimager. </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    BTW, you are making an XVCD and exactly how your player handles THAT would be hardware specific. I can tell you that a standard VCD at NTSC-FILM specs plays fine (at least on my two players) -- and the elapsed time readout also works fine (with PBC or without).

    BTW, you didn't let VCDImager pad your MPEG I hope? VCDImager doesn't do a good job of it and in fact could lead to A/V sync problems. If you use VCDImager with XVCD streams, I strongly recommend you remuxing your MPEG with TMPGEnc's MPEG Tools ("Multiplex&quot with the setting on "MPEG-1 Video-CD (non-standard)".

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  4. Kinneera:

    I've not had problems playing 23.97fps on the Pioneer, except to the extent that VCDImager seems to have trouble with it. As I said, the same file authored with Nero (sans PBC) plays back fine. I wonder if that has something to do with the problem?

    I've played around with the CCE pulldown utility to insert RFF flags, but there seem to be multiplexing issues afterward. How are you accomplishing this?

    Vitualis:

    The chapter references were compiled by frame number. The frame numbers were then converted to timecode using VirtualDub (hh:mms.mmm). Figures to the left of the decimal were then converted to seconds to form an entry point reference (sss.mmm).

    While the figures were close enough, it's annoying that any time base conversion has to be done at all. The frame number alone would do just as well, in fact better, because it's an absolute reference where 'seconds to an unknown degree of precision' is not.

    I suppose I could avail myself of the source code, but I'd prefer not to. Chapter references shouldn't be this great mystery, you know? It's a basic feature of the program. One shouldn't have to reverse-engineer the system in order to figure them out.

    I'm ragging a little because I'm frustrated, but it isn't directed at you. I appreciate your suggestions.

    As for the desynchronization, VCDImager didn't make any reference to padding, so I'm sure that isn't the cause. I'm starting to think the problem is related in some way to the PBC but I'll have to try a few experiments (authoring with no PBC, multiplexing as MPEG-1 and authoring as VCD NTSC-FILM with and without PBC) to see if a pattern emerges.
    Quote Quote  
  5. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    I've not had problems playing 23.97fps on the Pioneer, except to the extent that VCDImager seems to have trouble with it. As I said, the same file authored with Nero (sans PBC) plays back fine. I wonder if that has something to do with the problem?
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    I had the audio desync problems with my XVCDs, to which I can't apply a 2:3 pulldown flag. I've honestly never tried an SVCD without the flag. In any case, I simply create the video stream (w/o audio - "mpv" ) in CCE, use the pulldown.exe tool to apply the flag, and then multiplex it to my audio in bbMPEG. bbMPEG doesn't give me any errors. Finally, I author it with TSCV (no menus, but import the chapters from Smartripper). You actually have me kind of scared, because I haven't had a chance to test a disc created this way in my Pioneer yet.

    <font size=-1>[ This Message was edited by: kinneera on 2001-12-31 17:42:15 ]</font>
    Quote Quote  
  6. @ KoalaBear:

    With regards to the time reference, I believe we may have had this conversation before...

    If you have the absolute frame number, to derive the time reference, all you need to do is (frame number / frame rate ) and in your case, the frame rate would had been 23.976. I personally don't trust any other program to work out the time reference and just use a calculator... There isn't that much of a mystery. There may or may not be some deviation from the exact time past the third decimal place and I don't know the cause of that.

    I agree with you that the ability to reference time by the absolute frame number would be highly beneficial.

    As for the desync -- I see the problem now. I misread your first post (I thought you were create an XVCD as opposed to an XSVCD).

    A framerate of 23.976 fps is not in the specs for SVCD (but it is in VCD) so it is possible (and "acceptable&quot that a player will not correctly playback a straight 23.976 fps clip. However, if you add the 3:2 pulldown flags, most people have gotten it to work (on stand-alone DVD players at least -- I don't know about stand-alone SVCD players). There is a program called 3:2 pulldown (or something like that) you can download from doom9's site ( http://www.doom9.net ) that will insert them. That may solve your problem.

    As for why Nero burnt discs will play, who knows. Furthermore, are you sure that Nero burnt discs are burnt sans PBC? Up to this point, my experience with all S/VCD authoring/burning proggies (apart from VCDImager) is that they always use PBC even for simple structures like simple multitrack.

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  7. Kinneera:

    For some reason, bbMPEG doesn't like my DirectShow audio filters, so I can't get it to multiplex for me. This may have something to do with DirectX 8. Since that can't be removed without reinstalling the operating system, I may as well pursue the PBC connection first -- I have a hunch there's a causal relationship there.

    I'll create a version using VCDImager and no PBC, and a version using I-Author with PBC, and compare the results.

    Vitualis:

    You're right. Frame 584 / 29.97 = 19.552886, which is close enough to 19.553??? that the difference is irrelevant.

    While I'm aware that 23.97 is a nonstandard frame rate for SVCD, I do know that the Pioneer handles those sources quite well by performing its own 3:2 pulldown. The desynchronization appears to be related to whether the disc is authored using PBC and/or VCDImager.

    As for the Nero disc, I don't know. Circumstantially speaking it has no PBC, but it does have two tracks.
    Quote Quote  
  8. While browsing though some of the doom9 faqs recently, he had a specific reference of using "pulldown.exe" on CCE encoded MPEG-2 files (for SVCD) when the framerate is 23.976 -- perhaps this will help.

    Although the Pioneer has the ability to do its own 3:2 pulldown (which I would presume it must do for a VCD at 23.976 which is in spec), this may not be activated when the SVCD firmware is being used (i.e., it just does not expect that it will need to). This is completely speculation, of course.

    As for Nero, I'm reasonably certain that it does use PBC for all discs -- even simple multitrack. I could confirm it by using VCDXRIP on a Nero made disc image, but since I hate Nero, I don't have it installed on my PC. If you (or someone else) could make a short SVCD disc image with Nero and use VCDXRIP on it (VCDXRIP will load Nero style .nrg images as well) and then post the resultant XML file, this question can be answered definitively.

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  9. Actually, all NTSC DVD players can perform on-the-fly pulldown of progressive sources. Whether that feature is available to you in [S]VCD mode on a particular player model is a different story, but the capability is fundamentally there.

    I'm disinclined to use pulldown.exe for several reasons: first, the desynchronization problem isn't related to the frame rate (the Nero-burned disc played back flawlessly). Second, the only multiplexer that seems to handle RFF-encoded MPVs correctly is bbMPEG, which has documented problems with DirectShow audio filters, but is no longer being supported or maintained. Third, the program itself is a hack designed to defeat a limitation imposed by certain DVD player brands. This limitation doesn't exist in the Pioneer, thus there's not much point in going out of my way to solve something that isn't a problem to begin with.

    But if we play Devil's Advocate for the moment and assume Nero always creates a PBC, then the problem definitely lies within VCDImager.
    Quote Quote  
  10. However, the "problem" is then a matter of definition. VCDImager wasn't designed to make off-spec SVCDs...

    If you can use CD-RW, I suggest you do a few experiments. VCDImager with or without PBC and your MPEG-2 stream with or without using pulldown.exe.

    If you want the superior authoring abilities of VCDImager, you might as well just take Nero out of the picture...

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  11. Well, see, that's just it.

    24fps is a valid frame rate for VCD, and I'd bet that a similar sync drift would occur if I authored the same program in that format. That's too much work to take on in order to prove a point, but if I'm right, it's a bug of some kind and not rigid adherence to the specification that's responsible for the problem.

    The sun set on [S]VCD a long time ago. It's still a useful technology for teaching important principles of digital video (the same way that LOGO is useful for teaching children how to program a computer) but it's no longer a viable format in its own right.

    Thus, what would be the point of proving that VCDImager doesn't handle 24fps materials correctly in the general case, and therefore would be a worthwhile problem to research and resolve?

    By the end of the year most of us will have a DVD burner of some flavor or another, and [S]VCD will be largely forgotten.
    Quote Quote  
  12. I've made several 23.976 fps VCDs (i.e., VCD-FILM settings) with VCDImager and they work just fine.

    Similarly, making FILM framerate SVCDs (but using 3:2 pulldown flags as 23.976 fps is not a valid SVCD framerate) with VCDImager works for many people as well. Indeed, it is a very common thing to do if you are making a NTSC DVD to SVCD rip.

    None of my NTSC-FILM VCDs have a sync drift and neither is this a reported problem from the hundreds of people who make DVD rips to SVCD with VCDImager.

    It would suggest to me that your generalisation and conclusion is incorrect.

    If VCDImager does have a problem handling 23.976 fps video, it should be resolved. However, I don't believe that there IS a problem.

    Furthermore, it should be noted that the basis of your hypothesis is on the creation of a non-standard SVCD. "Rigid adherence to specification" is not possible as rightly a 23.976 fps SVCD should not even exist. If VCDImager was truly "rigid", then it should have popped up a message saying that your MPEG-2 stream was invalid for SVCD creation...

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  13. I think you tend to trivialize problems with VCDImager when they crop up, Mr. Tam, preferring to rationalize them in terms of standards if possible and the mechanics of MPEG if necessary. This is usually the point at which our conversations become so animated and interesting.

    But let's work backward from the conclusion this time around, and see if the underlying facts are even worth the effort of arguing before wasting our time on them:

    [S]VCD is a dead format for practical and technical reasons. It's found a niche among hobbyists for the purpose of archiving movies and TV shows, but it's next to useless for most anything other than that.

    For the last few years, it was worthwhile to explore ways of extending [S]VCD's capabilities because there was no affordable alternative to the format. But now that DVD burners and media have dropped to mass-market price points, we can stop pretending that [S]VCD will ever wake up from its coma and disconnect it from the respirator already.

    From a development perspective, any tool which can be migrated to DVD usage will survive the Great Extinction, but authoring packages won't be among them. This is why there's a feeding frenzy in the recordable DVD market with Apple acquiring Spruce, Sonic acquiring Daikin and Philips giving away its [S]VCD authoring packages for free.

    Now, if it can be shown that VCDImager has a few bugs with respect to sync maintenance, it will likely not be a trivial problem to solve. But the question of whether it's worthwhile to investigate is purely academic because (a) there's a workaround and (b) the audience for [S]VCD is at the crest of its final nosedive.

    The decision is very much like choosing whether to replace a bad transmission if you know you'll be buying a new car in a few months. Considering the outcome, the question of why the transmission is bad is irrelevant.
    Quote Quote  
  14. Look, I just highlighted how YOUR conclusion on a putative problem with VCDImager was flawed in its conception. I've also described methods to elucidate to real cause of your problem... If you're not willing to work it out, it makes little difference to me but don't make a conclusion on something that (i) you are not willing to test and (ii) when your logical reasoning on its causation if flawed.

    The fact you consider SVCD "dead" is irrelevant. You don't have to justify to me why you don't want to test it out... It's your XSVCD after all.

    If there is an issue with with film framerates then it should be fixed. You may not consider it important, but many people use VCDImager and it is the only open source authoring system in existence. Furthermore, the eventual goal of VCDImager is an open source DVD authoring and any problem like this should be hit in the head -- if there is a problem of course.

    Regards.
    Michael Tam
    w: Morsels of Evidence
    Quote Quote  
  15. I read a quote somewhere in this thread that I thought needed to be addressed:

    "While I'm aware that 23.97 is a nonstandard frame rate for SVCD, I do know that the Pioneer handles those sources quite well by performing its own 3:2 pulldown. The desynchronization appears to be related to whether the disc is authored using PBC and/or VCDImager."

    My understanding was this:

    - A true 23.97 "film" VCD is encoded progressive frames at 23.97fps. "Film" VCDs play back at 23.97fps in most players.

    - A VCD can also be encoded with progressive frames at 23.97 with a 29.97 (3:2 pulldown) flag added. This would still be encoded with progressive frames, but your player would play them back at 29.97fps by either interlacing frames and doubling every third frame, or by just doubling every third frame.

    - DVDs do the same thing and in fact are encoded with progressive frames at 23.97fps. This is why it's usually best to rip a DVD by using "force film" and removing the duplicate frames.

    - SVCD cannot encode a true "film SVCD, but it can encode a 23.97 progressive SVCD with a 3:2 pulldown flag added. The program pulldown.exe simply adds that flag so that the player will know to play it back by performing a 3:2 pulldown.

    I see nothing wrong with that. You still get the advantage of better compression and video quality by encoding 23.97 progressive frames. The only difference is how the video is displayed on your TV. Instead of being played back at 23.97fps, it is played back at 29.97fps using 3:2 pulldown.


    Darryl
    Quote Quote  
  16. Darryl:

    I think I see what you're saying: so long as RFF (Repeat Field Flag, i.e. hardcoded pulldown) costs you nothing, what's the problem with using it, right? The answer is that if framerate isn't the problem, RFF isn't the solution.

    Mr. Tam:

    A 23.97fps XSVCD authored with VCDImager exhibits progressive sync drift. The same data authored with Nero plays flawlessly. Obviously, VCDImager has problems handling film sources that Nero does not.
    Quote Quote  
  17. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    - A true 23.97 "film" VCD is encoded progressive frames at 23.97fps. "Film" VCDs play back at 23.97fps in most players.
    - A VCD can also be encoded with progressive frames at 23.97 with a 29.97 (3:2 pulldown) flag added. This would still be encoded with progressive frames, but your player would play them back at 29.97fps by either interlacing frames and doubling every third frame, or by just doubling every third frame.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    Even if a VCD is encoded at 23.976 fps, it will be telecined on the fly by the DVD player. This is a limitation of the TV, which is only capable of handling interlaced video at 29.97 fps. This is why there is no 2:3 pulldown flag for VCD, all firmwares (presumably) that encounter the 23.976 framerate automatically telecine. I believe it is also true that DVDs do simply use the MPEG2 2:3 pulldown flag to produce the same result. Since SVCDs are MPEG2, is is likely that the flag also needs to be applied in them for the decoder to deal with it properly.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    A 23.97fps XSVCD authored with VCDImager exhibits progressive sync drift. The same data authored with Nero plays flawlessly. Obviously, VCDImager has problems handling film sources that Nero does not.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    Sorry, but I also disagree with you on this. It is quite possible that Nero is simply applying that 2:3 pulldown flag and you don't know it. Do it yourself using pulldown.exe and author the video in VCDImager and you will almost certainly get the same result. I author my video at 23.976 fps, use pulldown.exe, bbMPEG (with DX8.1 on WinXP - no problems), TSVC/VCDImager, and it plays back flawlessly on my Pioneer.

    <font size=-1>[ This Message was edited by: kinneera on 2002-01-07 10:46:45 ]</font>
    Quote Quote  
  18. Kinneera:

    23.976fps is a valid NTSC framerate for DVD, thus all NTSC DVD players are capable of performing 3:2 pulldown for those sources that require it. Whether this feature is available to you in [S]VCD mode is a different story, but the capability is there nevertheless.

    The suggestion that Nero might secretly be inserting RF flags during the burn phase was easy to rule out: I checked the framerate of the Nero-burned disc and it's 23.976fps.

    However, I'm curious how you came about the custom of RFF-encoding your progressive sources in the first place. Was it to solve a particular problem, or to prevent a potential problem? Was it to adhere more closely to traditional SVCD specs, or to promote cross-compatibility with brands other than Pioneer? In other words, was it an ounce of prevention or a pound of cure?

    I have a hunch that RFF, like the idea that MPEG-2 is inherently more efficient than MPEG-1, is one of those ideas that sounds so logical it must be true even if the facts suggest otherwise. I believe pulldown.exe was written as a hack to bypass the limitations of certain makes or models of DVD player and somewhere along the line it got confused as an essential coding practice.

    That's purely my own opinion, of course, and doesn't negate any success you've had with the procedure -- only to show that absence of the procedure doesn't explain the failure.

    Mr. tam:

    Scientifically, we can rule out the "RFF is fundamental" hypothesis simply because it fails to predict the observations. If frame rate were the source of the problem, we would expect the audio to be desynchronized by a constant margin from the beginning of the program to the end. The observation is that the audio starts out in sync and gradually falls behind the video in proportion to the length of the program. We would also expect two different authoring packages to produce the same result given the same source. The observation is that the VCDImager-burned source exhibits sync drift while the Nero-burned source does not.

    For what it's worth, personally I wonder whether the problem might be related to constant vs. angular sector velocity. It's just a germ of a theory but it would account for the phenomenon itself as well as the difference between the two packages. The bottom line for me is that regardless of why VCDImager behaves as it does, reliable playback performance trumps fancy authoring features.

    Adherence to the formal SVCD spec is irrelevant, really, because 29.97 is the only NTSC frame rate that standard is designed to support. Embedding RF flags to change the apparent frame rate is just as noncompliant as using a 23.976fps source to begin with; the difference is that some DVD players may like that flavor of XSVCD more than others.
    Quote Quote  
  19. my 2 Abe Lincolns

    I encoded SVCD at 23.97 with Nero, stuck in player, played choppy like VBV buffer over/underflows...

    Went back, use pulldown.exe, burn with Nero, played fine, no sync drift...then brought the file into VCDeasy (because of FF/RW issues with Nero), authored a SVCD, burn the image with Nero...played fine, no sync drift.
    Quote Quote  
  20. /me just likes to add a few words

    regarding the [S]VCD is a dead end issue: a reason more for vcdimager, since commercial interest will fade, and you'll be left just with old proprietary binaries, which may stop working some day... not so with source code...

    as to nero/vcdimager; well, if nero really does something different (maybe it modifies the mpeg stream?) this can be debugged; (and I'd be quite curious to know -- as I've done comparisions since I started development of vcdimager...

    e.g. hex-compare the mpeg stream before nero with the same mpeg stream after being converted by nero into an .nrg image and then re-extracted with vcdxrip; (you could also try to fed that extracted mpeg to vcdimager, and see whether it works now...)

    another thing you should make sure is, that you burned the SVCD with the same burning app;

    btw, one major difference with nero vs. vcdimager is, that nero adds front/end margins; (you can tell vcdimager to add those to SVCD's as well)

    another thing is, that sometimes play items behave differently when being played non-PBC'ed, as menu-item in selection lists, or as playitem in playlists...

    there are quite some details which might or might not be the cause of it; the major problem is, that there are many firmwares out there, that have a hard time with the SVCD format (caused by unhappy SVCD standardisation history)

    ps: as I've a pioneer myself, I could debug it myself, if you could provide me with an mpeg stream long enough to exhibit this problem...

    regards,
    Quote Quote  
  21. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    23.976fps is a valid NTSC framerate for DVD, thus all NTSC DVD players are capable of performing 3:2 pulldown for those sources that require it. Whether this feature is available to you in [S]VCD mode is a different story, but the capability is there nevertheless.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    I'm not sure why you mentioned this, since I never disputed this. In any case, it relates to what you asked me about using the pulldown utility. And the answer is basically all of the reasons you hypothesized. Fundamentally, I want to only encode the original frames at 23.976 fps, because this allows 20% more bits to be allocated per frame, and since the other frames aren't really supposed to be there. So I forcefilm or IVTC depending on circumstances and encode the video that way. Unfortunately, 23.97 just simply is not a valid framerate for SVCDs (whereas it is for VCDs), so regardless of whether my Pioneer can handle it anyway, I still apply the flag for compatibility purposes. It was my understanding that most DVDs are done the same way, for the same quality reasons, but I could be wrong about that. By having the nominal framerate reported to the decoder as 29.97, I avoid compatiblity problems and the decoder knows to explicitly telecine the source frames it's fed.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    I have a hunch that RFF, like the idea that MPEG-2 is inherently more efficient than MPEG-1, is one of those ideas that sounds so logical it must be true even if the facts suggest otherwise. I believe pulldown.exe was written as a hack to bypass the limitations of certain makes or models of DVD player and somewhere along the line it got confused as an essential coding practice.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    I will hold that is is essential encoding practice for SVCDs, since the progressive framerate is not supported. Even players with declared SVCD support are likely not to play such a disc or have problems with it, it makes no sense to not perform such a simple step. And as I mentioned before, I've never had any problems multiplexing the resultant stream, although I do have access to bbMPEG. I would venture to say that if you are using TMPGEnc for your multiplexing (this seems to be implied by your comments about problems with DirectShow and bbMPEG) that may be the source of the problem, as TMPGEnc is notorious for producing incorrect (or Chinese, as some may say) SVCD scan offsets. These indeed cause problems with VCDImager (whereas Nero, I believe, generates its own scan offsets anyway), and they did cause desync problems even on my Pioneer.

    In any case, I still highly doubt the problem lies with VCDImager, as I and many others appear to have absolutely no problem with it using these exact processes. It might enlightening to see every exact step you take in producing your SVCD to see other possible sources of the problem.

    <font size=-1>[ This Message was edited by: kinneera on 2002-01-09 17:59:21 ]</font>
    Quote Quote  
  22. HVR!

    Great to hear from you in regard to this issue.

    I'll send you an e-mail under separate cover. Reply with your mailing address and I'll send you a CD containing the relevant authoring materials (menus, program streams, XML and so forth) that you can use for your investigation.
    Quote Quote  
  23. Kinneera:

    If I repeat a fact I'm aware you're aware of, it's purely for rhetorical purposes: A + B = C. I'm enumerating the links in a chain of logic to expose them to closer scrutiny in the event I've overlooked something fundamental. As Bill O'Reilly[1] might say, "Am I wrong about this?"

    If you employ pulldown.exe for strategic as opposed to tactical purposes, that's perfectly legitimate to me. What I take issue with is that it's somehow more "correct" than not using it at all when both are equally noncompliant with respect to the official standard.

    At the end of the day, it's what the decoder chip will let you get away with that determines what the format is capable of, not what the standard dictates in terms of acceptable data structure per se.

    In the case of the Pioneer, it has the reputation of playing whatever you throw at it because while it may interpret the PBC in accordance to standard, it delegates stream interpretation purely to the MPEG decoder. I believe most DVD players behave similarly, as there are people who've reported that their "VCD-only" DVD players will handle SVCD (and XSVCD at that) by impersonating VCD long enough to slip past the firmware that otherwise would prohibit that stream from being played back.

    That being said, if you believe pulldown.exe is the way to go for a particular project I certainly trust your judgment. But I start to smell something fishy when I'm told that pulldown.exe is always the way to go because it's "more compliant" than the alternative, and the bullshit alarm is triggered when I'm told that an authoring program which neither recognizes nor cares about RFF doesn't work the way it's supposed to because the flavor of XSVCD I produce doesn't taste good as a result.

    For my money, I'd rather produce a miniDVD (which won't play back on the Pioneer at all) than an [S]VCD of inferior quality that will, but it's not because I can't get bbMPEG to multiplex for me. It's because in the final analysis, bbMPEG isn't really necessary at all.

    ------------
    [1] American journalist, commentator and closet conservative renowned for his habit of confronting debate opponents with a near-unassailable summation of the facts.
    Quote Quote  
  24. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    If you employ pulldown.exe for strategic as opposed to tactical purposes, that's perfectly legitimate to me. What I take issue with is that it's somehow more "correct" than not using it at all when both are equally noncompliant with respect to the official standard.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    Herein lies my issue: there is nothing "noncompliant with respect to the official standard" about using pulldown on an SVCD. The RFF flag is a perfectly standardized characteristic of MPEG2 that merely informs a decoder to repeat certain frames on the fly to achieve the appropriate framerate. Whether those extra 6 fps are actually encoded in the stream or repeated on the fly by the encoder isn't relevant to the SVCD spec., only whether the framerate is going to be 29.97 one way or another. Any MPEG2 decoder that doesn't support the RFF flag is off spec, thus any DVD player that can play an SVCD at 29.97 fps encoded can also play an SVCD at 23.976 fps encoded with the RFF flag enabled.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    But I start to smell something fishy when I'm told that pulldown.exe is always the way to go because it's "more compliant" than the alternative
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    First, I'm really not trying to be hostile, but it sounds a hell of a lot more fishy when one person encounters a problem and then tries to blame it on software that many many other people are using without issue. Again, I would ask how you are multiplexing your SVCD streams. I highly suspect that is the source of your problem, NOT VCDImager.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    an authoring program which neither recognizes nor cares about RFF doesn't work the way it's supposed to because the flavor of XSVCD I produce doesn't taste good as a result.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    I believe VCDImager does recognize that flag. Of course, only HVR would be able to provide positive verification of that.

    As for miniDVD, its actually going to be of inferior quality at equivalent video lengths because of the Mode1/Mode2 issue. Still, it has its place, just as SVCD does. Incidentally, I do my (X)SVCDs at 352x480 or 720x480, so that I have the option of porting them to DVD media in the future.
    Quote Quote  
  25. Kinneera, in your case, there is no offense (either way, I hope). I respect your opinion because you're not likely to overextend yourself in order to maintain a particular posture.

    However, I'm not pulling things to talk about out of my ass, either. I'm reporting a problem I've experienced that I can trace to a particular application and ask why it should be so. The explanations offered so far don't really cut muster in terms of engineering reality, which is why the author of the program offered to investigate.

    Why am I the only one experiencing the problem?

    I don't know, but so far I'm apparently the only one who's challenging the conventional wisdom in regard to the topic.

    There just might be a causal relationship there.

    <font size=-1>[ This Message was edited by: KoalaBear on 2002-01-10 18:49:50 ]</font>
    Quote Quote  
  26. Mainly, I'm still curious how you've multiplexed your video. The inability to utilize bbMPEG seems problematic to me, since it is the only reliable SVCD multiplexer I've encountered, and the multiplexing can have a huge impact on synchronization. Have you tried using the multiplexer in TSCV? I believe it is based on bbMPEG's multiplexing code.

    <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    Why am I the only one experiencing the problem?
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    This, of course, is exactly my concern. It points to something you're doing, not VCDImager.

    <font size=-1>[ This Message was edited by: kinneera on 2002-01-10 19:10:52 ]</font>

    <font size=-1>[ This Message was edited by: kinneera on 2002-01-10 23:34:32 ]</font>
    Quote Quote  
  27. Multiplexing in the general case?

    I use a couple of them. The muxer built into TMPGenc and the one that comes with I-Author. I'm aware that neither of them handles RFF encoding properly, which is why I turned to bbMPEG. From bbMPEG's perspective, the video filters are okay, but the audio filters are not. I suppose I could carve a free partition from my system drive and install Win2K or something to see if bbMPEG likes that environment better, but in the meantime I'll take you up on your suggestion and give TSCV a try.

    Now, I see no shame in discovering that I've made a mistake, admitting it, learning from it and moving on, but apart from defiance of orthodoxy I don't yet believe that I made one. Let's see what HVR has to say about the problem and move forward from there.
    Quote Quote  
  28. <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
    I believe VCDImager does recognize that flag. Of course, only HVR would be able to provide positive verification of that.
    </BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

    actually vcdimager does not recognize that flag... and it doesn't really need to (except for warning the user he does not do something recommended...)

    anyway, there's something interesting written in IEC62107 about this... i.e. 29.97Hz is mandatory, RFF flag 'only' recommended...:

    For 3:2 pull-down material on NTSC, the frame rate shall be set to 29.97 Hz and the use of the repeat_first_field and top_field_first flags is recommended


    Quote Quote  
  29. It was my understanding that the framerate is a field in the MPEG header, that can be set to any desired value (in theory), whether or not it is valid? Specifically, it is independent of the presence of the RFF flag? So if you encode 23.976 fps video, tag it as 29.97 fps, but don't apply the RFF flag, god knows what will happen (and it will be entirely decoder dependent). In that case, the 'recommendation' would be implied to be a fairly strong one!

    In any case, I agree that it isn't really necessary for VCDImager to read it. When I author my discs, VCDImager merely reports it as 'unknown NTSC' and reports no further errors - and that is because my res. is 352x480, not because the framerate is wrong. The framerate is of course reported as 29.97, even though I know the underlying video is only 23.976 with the flag on.

    KoalaBear: what OS are you using that doesn't like bbMPEG? I don't see any mention of it in the thread previously. I only ask because it really seems like it should be possible to get it to run without installing a whole 'nother operating system.

    <font size=-1>[ This Message was edited by: kinneera on 2002-01-11 17:41:36 ]</font>
    Quote Quote  
  30. "actually vcdimager does not recognize that flag... "

    I have to disagree here. I am not sure what version of VCDimager you are using. But the lastest version (w/ VCDeasy GUI), recognizes the pulldown flags placed into my mpeg2 streams, because it goes from detecting 23.97 to 29.97 and the only difference is me running pulldown.exe.

    Im not trying to add coal to fire. I just know when I encoded an mpeg2 w/ 23.97 fps with CCE, then use pulldown.exe on it for 29.97 fps. It is detected as such within both BBmpeg and VCDImager. My log text states (2:3 puldown detected). And when played it works fine w/o sync drift. I tested TMPG as well, using 23.97 in conjunction with both "non-interlaced" setting & "3:2 when playback setting", again both BBmpeg and VCDImager reported the Non-laced steam as 23.97 & "3:2 when playback" stream as 23.97...Doing this same method WITHOUT pulldown.exe or using a TMPG encoded 23.97 fps resulted in choppy playback when both authored straight by Nero or burn image file from VCDImager. I assume that my SVCD capable player expected 29.97 fps. While VCDs and miniDVDs play at 23.97 & 29.97 w/o any problems. Also, given that Nero tells me when given a 23.97 fps mpeg2 for SVCD authoring that it expects 29.97, I would assess that pulldown.exe is not a "hack", but a needed tool to make you moeg2 video SVCD standard for those who use CCE because it only encodes in 23.97 fps. I wish I could test your format, but again my player simply chokes on an SVCD altogether at 23.97 wether its Nero or VCDIMager.
    Just by a quick look, the only difference I see between Nero & VCDImager are the .svd files it places in its "SVCD" folder. First I know nothing of what these files do, Im just throwing this out there as a differences I see 'tween the 2, In Imager there are "Entries", "Info", & "Tracks"..now Nero has the same 3 .svd files but it also has "Lot" & "PSD"..does anyone know what these files do??..I noticed that switching PBC control on/off had no affect on creating these files.

    Looks like my Abe Lincolns are now up to George Washingtons.

    <font size=-1>[ This Message was edited by: Kdiddy on 2002-01-11 18:51:07 ]</font>
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!