View Profile
View Forum Posts
Private Message
Kinneera: I don't think it's my operating system (Win98 SE) that's the problem per se, more that there's no way for me to know which component (capture card, video editor, media player, etc.) was responsible for installing the audio filter that bbMPEG doesn't like. It would be easier for me to isolate that particular program in order to find an MPEG-2 decoder it can live with than it would be to troubleshoot the system as it stands.
Hassle aside, though, my reluctance to do this has less to do with a few hours of labor than this near-superstitious conviction that VCDImager is rightfully punishing me for my blasphemic disregard of pious ritual.
You asked me how I made the MPEG in question. Here are the details:
Source: Commercial DVD, 52 minute TV program, film source
Capture: 480x480 PicVideo MJPEG, 29.97fps, 44KHz stereo, 0 drops
Process: AviSynth, IVTC plugin, bicubic resize to 352x480
Encoder: CCE 2.50, frameserved from AviSynth
Video Settings: progressive frames, zigzag scanning, luma 16-235, auto DC, GOP 1/3/2, 6 chapter marks
Pass 0: 23.97fps CBR 1780 Kb/S MPV, 44KHz 128Kb/S mono MPA[1]
Pass 1 - 3: VBR 1150 / 1780 / 2472 Kb/S
-----------
[1] Original soundtrack was dual-channel mono. I saw no reason not to drop the superfluous second channel if I could recover a few extra Kb/S by doing so.
Multiplex: I-author MPV+MPA -> MPS, no errors reported.
Nothing outside the ordinary. Well, encoding the audio as mono was probably a tad impudent of me, but I trust it's not enough to provoke a plague of locusts by itself.
+ Reply to Thread
Results 31 to 60 of 63
-
-
Multiplexing handled by CCE? It is known that CCE doesn't multiplex streams for SVCD correctly either. Also, I have seen (but not verified) reports that Pioneers, for all of their non-standard video capabilities, have sync problems with non-standard audio bitrates. If you're having audio problems, the fact that you (a) used mono sound and (b) it was at a nonstandard bitrate are huge red flags to me. A methodical way of testing would be to eliminate all extraneous variables, and I would start with those. Keep (convert) the audio to stereo, and keep it at 224Kbps. Even if you don't want to ultimately use those parameters, it will allow us to verify whether that is the source of the problem. Also, I still want to hear whether TSVC's multiplexer produces any better results. Finally, if you are using TMPGEnc's multiplexer, DON'T!! I experienced the exact same problem you are describing, before I started using bbMPEG for multiplexing.
-
<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>
Hassle aside, though, my reluctance to do this has less to do with a few hours of labor than this near-superstitious conviction that VCDImager is rightfully punishing me for my blasphemic disregard of pious ritual.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
Now with all due respect, it is hardly disregard of pious ritual, it is failure to take the steps necessary to conform to the standard. Such "pious rituals" are created precisely to avoid the kinds of problems you are having. 23.976 fps is not in the SVCD standard, so whether or not your specific DVD player could handle it in theory does not afford you any sympathy from me if you have problems with it. I would suggest committing yourself to the few hours of work that would allow you to use the only tool that properly multiplexes so that you can (a) use the pulldown tool to obtain a standard framerate and (b) resolve any incorrect multiplexing issues, before you blame a program that everyone else uses with absolutely no problems. Try starting with the standard, then deviating from it piece by piece to find out what the limits really are. I sincerely hope this problem can be resolved, cheers!
<font size=-1>[ This Message was edited by: kinneera on 2002-01-11 22:21:39 ]</font> -
Multiplexing by CCE?
No. Multiplexing by I-Author. The audio file was generated by CCE during pass 0. Elementary streams always. With CCE it's customary to do your zeroth pass using CBR, have a look at the statistics under the "advanced" tab and strategize additional passes according to the quality you want to achieve versus the bitrate available to you.
I wasn't aware the Pioneer had issues with nonstandard audio bitrates. Sounds reasonable to me, but it doesn't explain why the VCDImager-compiled disc exhibited the same sync drift when played back on the PC, or why the Nero-compiled disc played back correctly on the Pioneer.
This is a possibility I'd be glad to test, but it's a little late for me at this point as the original capture file was deleted once the encoding was finished. (If only I'd have known what a controversy it was destined to be!)
At any rate, I made arrangments to borrow a friend's broadband connection to FTP the file to HVR. Given the same file with the same software and similar hardware, the answer will lie in whether he's able to reproduce the result. -
<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 2002-01-11 18:45:42, Kdiddy wrote:
"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.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
no, they don't; vcdimager only reads the framerate code(!); which happens to be changed as well by pulldown.exe
-
To rake the coals...
I didn't think a mono stream at 128 kbit/s WAS off-spec for a SVCD... Of course, with all the dodgey SVCD firmwares around, it could make a difference.
In any case, KoalaBear: have you actually tried using pulldown.exe yet? I can't remember from the thread whether you have or you have not...
As others have mentioned, it is a highly recommended procedure as it does seem to work ("more" compliant is an irrelevant concept here as a 23.976 fps SVCD is in no way compliant anyway).
Also, exactly what problems are you having with bbMPEG in the context of muxing? bbMPEG is probably one of the only few muxers that does it right. The I-Author muxer has its own problems...
Regards.
Michael Tam
w: Morsels of Evidence -
Well, Vitualis, yes and no...
Pulldown.exe works fine, but bbMPEG doesn't. It complains that my audio filter is unsuitable, and refuses to load the MPA. Under the circumstances it would be easier to give bbMPEG a partition of its own than to troubleshoot the drivers as they stand, but that's beside the point because in reality I had no intention of using pulldown.exe in the first place.
It just so happens that the VCDImager version of the disc exhibited a synchronization problem that the Nero version did not. None of the theories suggested so far can account for that difference, which is why the cause of the problem remains a mystery.
At this point, the RFF theory is purely a matter of faith. People are urging me to get the problem with bbMPEG worked out as soon as practicable because NTSC-FILM is the devil's frame rate and flirtation with sorcery can only lead to damnation, but I'll wait until HVR can review the data before I officially repent.
Speaking of heresy, I was at a friend's house earlier today and brought my discs to try on her DVD player (a weirdish Samsung combo). Both discs worked substantially the same as they do at home, except that the Samsung's MPEG-2 decoder isn't as fine as the Pioneer's and the playback mechanism is far more sensitive to dust and scratches.
I suppose I should add to the DVD player database here and drop HVR a note for his records as well.
-
Hmm... so your problem with bbMPEG is with it accepting your audio? Maybe putting a mono audio track in is more trouble than it's worth.
If you encode the mono audio as joint stereo, the way joint stereo works should ensure that there is little loss of relative bitrate (i.e., for a mono source, 128 kbit/s mono MP2 should be very similar to 128 kbit/s joint-stereo). Perhaps this may help the next time around...
Also, thanks for the info on the Samsung... I've wondered for a while if it would be possible to get some sort of objective testing of the quality of picture (i.e., decoding +/- hardware filtering) from DVD/SVCD/VCD of the various stand-alone players. There's a lot of rumours on what's good and what's not but hardly reliable...
Regards.
Michael Tam
w: Morsels of Evidence -
Earlier this afternoon I figured "Oh, what the hell" and reinstalled my primary OS from scratch in an effort to fix the bbMPEG problem. I installed a snapshot utility that allowed me to undo each step of the configuration as necessary to troubleshoot the problem.
Prior to the installation of a video driver, bbMPEG wouldn't load an MPA because it said my color depth was too low (go figure). So I installed my video driver, tried again and *BING*, got the audio filter error again.
For the record, my video card is an ATI AIW 128. It's not just a capture card but a tuner, TV-out board and so forth with a number of virtual device drivers that tie those functions together at the system level. If I disable these virtual devices, bbMPEG won't load an MPA file at all. If I enable them, I get the usual error.
Since I'm not going to structure my system around a piece of abandonware no matter how well it multiplexes, let's consider bbMPEG to be a dead issue.
<font size=-1>[ This Message was edited by: KoalaBear on 2002-01-13 16:01:49 ]</font> -
<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>
At this point, the RFF theory is purely a matter of faith. People are urging me to get the problem with bbMPEG worked out as soon as practicable because NTSC-FILM is the devil's frame rate and flirtation with sorcery can only lead to damnation, but I'll wait until HVR can review the data before I officially repent.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
I'm going to admit, you're starting to frustrate me here with this ridiculous rhetoric "devil's frame rate... flirtation with sorcery". So I will say it again, 23.976fps IS NOT AN ACCEPTED FRAMERATE FOR SVCD. It is not the devil's framerate, nor is it flirtation with sorcery to take the simple and neccessary steps to make your encoding standards compliant!!!! If your non-standard methods don't work, don't come bitching until you've tried making your disc conform to standards. I would also add that this includes regular stereo sound, at the preferred bitrate of 224Kbps. Then start deviating from the standard to find the source of the problem. You also still haven't indicated whether you've tried TSCV's multiplexing (with pulldown.exe applied to the elementary video stream prior) to see if the results are improved. Also, once again, if you are using TMPGEnc to do your SVCD multiplexing, it will never work. The offsets are generated incorrectly, and produced for me the exact same problem you described. It might also explain the authoring tool difference, as it is my understanding that Nero substitutes its own offsets, whereas VCDImager does not.
Now as for the AIW 128, that is exactly the same card I am using. With the latest drivers from ATI (note - drivers, not necessarily MMC), the most recent DirectX8.1, and no codecs other than Windows defaults and Huffyuv installed, I have had no problems with bbMPEG in either Win2K or WinXP. So it seems very likely that there is still something fundamentally wrong with your system, ATI drivers, or reinstall method. As for it being abandonware, this seems to me to be irrelevant (and a cop-out), as it is the only known multiplexer that produces SVCD streams correctly, including the scan offsets. Abandonware is still bestware if it is the only software that does the job right.
Honestly, I would also love to have a shot at a shorter, more bandwidth friendly clip of the video stream in question.
<font size=-1>[ This Message was edited by: kinneera on 2002-01-13 22:49:51 ]</font> -
To which I would reply, Kinneera, that there seems to be a double standard here.
NTSC-FILM is a nonstandard frame rate for SVCD. A mono 128 Kb/S soundtrack is a nonstandard audio spec for SVCD. 352x480 is a nonstandard frame size for SVCD. Guilty as charged on all three counts.
But if the objective were to build a disc in strict compliance with the SVCD standard, what the hell does anybody need VCDImager for? Philips SVCD toolkit would do just as well for this, in fact better, because it permits no deviation from the standard whatsoever.
The benefit of VCDImager, or so I'm told, is that it's open and extensible whereas the Philips product is proprietary and fixed. Do you recognize the contradiction here? Why do we need yet another authoring tool, particularly an extensible one, for compiling video discs in strict compliance to a standard that's already dead?
Frame rate, real or nominal, is not the root cause of the problem. The religious references are a joke to defuse some of my frustration with people who keep bringing the discussion back to RFF when that possibility can be ruled out on empirical and practical grounds.
I don't know what revision of the ATI software you're using, but I'm at 6269 (driver) and 6.2 (MMC) under Win98SE. The combination has given me good performance as long as I've owned the card. BbMPEG appears to be the sole program not compatible with this configuration that I'm aware of, so while I might install a more up-to-date driver and MMC combo considering I can undo those changes at this point fairly easily, that's going to be the last straw because bbMPEG just isn't that ******* important.
But the stream in question isn't going to be helpful to you in a shorter, more bandwidth-friendly form. The sync drift isn't present in the MPEG, it appears only after the file has been compiled and burned, and even then only when it's handled by VCDImager. That's why I sent the stream to HVR for analysis. Let's just put a lid on that for a little while, give HVR time to work the problem, and listen to what he has to say about it afterwards. -
OK, fair enough, but there are still a few points which I think it is worth extracting from this discussion:
You have changed so many variables from the standard at once, that it is impossible to fairly isolate the point of breakdown. The fact that no one else experiences these problems with the software in question is further evidence that the whole discussion would be better served if you started from compliance and deviated more gradually.
<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>
Frame rate, real or nominal, is not the root cause of the problem. The religious references are a joke to defuse some of my frustration with people who keep bringing the discussion back to RFF when that possibility can be ruled out on empirical and practical grounds.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
This has never been ruled out on either empirical or practical grounds since you refuse to try it...even just encode the thing at 29.97 native if nothing else. And framerate is the cause of desync issues more often than any other cause.
Also, you don't have to do anything you don't want to, but it would greatly mollify me if you would use another tool, any tool, other than TMPGEnc or I-Author to multiplex your video (ie TSCV) and indicate the results. You have continually ignored this suggestion/request for comparison. So I will say it one more time, if you are using TMPGEnc for multiplexing, it will never work right in VCDImager, and it isn't VCDImager's fault!
Regards, and I definitely look forward to seeing the results of HVR's testing as well.
<font size=-1>[ This Message was edited by: kinneera on 2002-01-14 00:25:31 ]</font> -
You have continually ignored this suggestion/request for comparison.
I'm not being pig-headed about this, I'm just not interested in performing an endless series of meaningless experiments until I arrive at a result that's consistent with random speculation.
I need more to go on than that.
Give me a good rationale that not only takes the facts into account but predicts an unambiguous outcome that an experiment can be designed to test, and I'll accomodate your request.
So I will say it one more time, if you are using TMPGEnc for multiplexing, it will never work right in VCDImager, and it isn't VCDImager's fault!
Bingo.
I think I see what you're getting at now:
The only multiplexer that works with VCDImager is bbMPEG and possibly TSCV. TMPGenc and I-author produce files that play back correctly before they're compiled by VCDImager, but not afterward. These multiplexers still work well with Nero, however, just not VCDImager, yes?
If so, that's a very good theory because it accounts for the difference in outcome between the two programs, doesn't assume that the data is flawed per se, and it's easy to test experimentally -- if I remux with bbMPEG and compile with VCDImager, the sync drift problem should disappear, right?
I'll buy that, and it's worth a few hours of tedious debugging time to boot. This is a possibility that I'm sure HVR will also want to explore.
Good thinking!
-
Woohoo! That was mainly what I was trying to get at the whole time! Sorry if it got obscured in the middle of some of the other discussion!
Just in case you're curious, my basic reasoning throughout this has been basically the following - there are only two factors that can really affect a/v sync: framerate, and mux-rate. That is because these are the only two factors that have any impact on the playback timing of the streams in the MPEG. The corollary of the mux-rate issue is of course the sector read rate off of a physical medium (ie. CD). Soooo, when a/v sync issues come up, I tend to think framerate first and multiplexing second.
In the general case, I still hold that keeping the framerate at 29.97, using pulldown if necessary, is optimal, if only because there's no real reason not to. This is because your encoded framerate is of course still 23.976, giving you all the associated quality benefits, but your playback is compliant, using a facility conceived by the authors of the MPEG standard for precisely that purpose. Of course, this assumes your software tools are behaving as they are supposed to, so it's unfortunate that you have had so much difficulty with bbMPEG in this regard.
Multiplexing is of course equally crucial, as it is the heart of the stream synchronization issue...determining how the video and audio data is linked and at what data rates. A failure at this stage will cause nothing but frustration. The corollary to this issue is the SVCD offsets, which of course is SVCD specific, which are very important to standalone DVD-player behaviour (but not computer based software). And of course, it is well documented that TMPGEnc does not generate these offsets correctly for DVD players marketed in the US. bbMPEG (and I'm pretty sure Nero as well) generates its own offset data. VCDImager does not correct them (but will warn you). So this would explain the difference in authoring software.
Anyway, I hope this mini-novel is useful in the general sense, and I look forward to hearing whether it helps solve your problem (as well as from HVR of course)!
-
One more thing to consider while using VCD Imager, is the app used to burn the cd image.
VCD Imager doesn't create correct bin/cue files. This has been passed off in the past as a problem with Nero (even I have done work to prove Nero's fault). But as it turns out, VCD imager doesn't create the needed ECC's for the mode2 image. That's why many people complain of PBC issues, and premature endings.
CDRWin (maybe CDRDAO too) correct this error, Fire Burner, and Nero do not. Nero simply does as it's told, it's given an image, and burns it. CDRWin adds the necc. buffers for you.
One more thing to consider is the compatibilty of your Pioneer. Some players require an empty Segment directory, and you could also switch between using Mpeg2/EntryVCD and Mpegav/EntrySVD.
If you believe TMPG multiplexing is the fault, have VCD Imager update scan data offsets. This will correct for the chinese specfication. -
<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>
VCD imager doesn't create the needed ECC's for the mode2 image
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
Again, this is sort of in HVR's court, but I believe this is perfectly legitimate. VCDs and SVCDs are burned in Mode2 raw, which doesn't have ECC anyway.
<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 believe TMPG multiplexing is the fault, have VCD Imager update scan data offsets. This will correct for the chinese specfication.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
This is a quick fix for a/v sync problems, but there have been many reports that FF/RW/Goto, time counters, and other functions of PBC will not work properly if this is done. -
<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 2002-01-14 18:40:19, kinneera wrote:
Again, this is sort of in HVR's court, but I believe this is perfectly legitimate. VCDs and SVCDs are burned in Mode2 raw, which doesn't have ECC anyway.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
This format is used almost exclusively to store digital video data, thus requiring only moderate read accuracy. The user blocks size is 2324 bytes. The remaining bytes are used to store sync patterns, block headers and error detection codes (EDC).
http://www.cdrinfo.com/Sections/Glossary/Details.asp?RelatedID=489
VCDImager's error is that it output's a RAW bin file. -
Well, they're probably not supplied because the defaults that will be substituted by the recorder probably suffice. In any case, premature endings and PBC problems are almost certainly user errors in creating the XML files or PBC structure in pre-authoring. I've not had any such problems with VCDEasy, TSCV, or even my own hand-written XMLs. Either that, or people are trying to burn bin/cues with EZCD creator or Nero, neither of which even handles the bin/cue format itself correctly.
-
I too, have no problems with burning the bin files that VCDeasy/imager creates..Nero likes them just fine.
-
I'm glad that you haven't noticed any problems. But, if you burn an image created by VCDImager with Nero, then burn that same image with CDRWin, they are different.
You can see the findings below.
http://www.hvrlab.org./~hvr/vcdimager/nero_bug.html
If you read the whole document linked above, it states:
--------------------------------------------------------
Caused problems
XA multitrack images are most commonly used for (Super) Video CD's, (S)VCD's for short. VCD's contain sector addresses in the first track which point to the following tracks recorded for addressing the track starts in addition to the redundant information recorded in the TOC of the CD-ROM. SVCD's also make use of scan point tables, which contain sector addresses for playing time related access to the VBR mpeg-2 streams.
Now, if the sector addresses become invalid, because the following tracks are not recorded as they were supposed to be, the following effects may be seen:
entry points will point to wrong locations or even outside the MPEG stream
fast forward/fast reverse operation may not work properly
GOTO may not work properly
MPEG tracks may not play at all
MPEG synchronisation problems
--------------------------------------------------------
-
<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 2002-01-14 21:12:05, kinneera wrote:
or people are trying to burn bin/cues with EZCD creator or Nero, neither of which even handles the bin/cue format itself correctly.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>
Nero does burn bin/cue format correctly if the bin/cue is correctly made. I've made many disc rips with CDRWin (bin/cue) that have been burnt with Nero, and have identical sector maps.
It just doesn't handle VCDImager bin/cue's correctly. -
fyi, just a few clarifications
nero versions prior to 5.5.6.4 definitely had no real bin/cue support (if you wonder why nero supports them now officially at all; that's because I've been in contact with ahead for a few months, urging them to fix bin/cue support... it wasn't that difficult, after showing them the nero_bug URL)
-- it just happened to work for simple bin/cue images in the past...
vcdimager does create the necessary ECC and EDC data;
just remember, that the space for ECC data is only present on mode2 form1 sectors, which are used for non-realtime data... (i.e. non-mpeg data)
and btw, vcdimager does also create 'correct' bin/cue images...
using vcdimager's update scan offsets facility is just a hack to converting existing scan offsets to the official SVCD standard (not to chinese-svcd syntax!)
-
Update
1. TSCV -- I downloaded the program, checked it out and multiplexed with it. The result is sort of strange: in sync for half the file, then one word off for a quarter, then two words off for the remainder. Does this sound normal? Haven't burned it yet, just wanted to know what to expect.
2. bbMPEG -- Still no progress, though I did post a message on the bbMPEG forum at Delphi. Maybe someone there will be helpful in resolving the problem.
-
That definitely sounds strange. You mean it abruptly becomes out of sync at a certain point, and then abruptly becomes worse at another point after that? Almost sounds like a bad frames problem, but I can't imagine how that would happen from a captured source. Also, just to make sure, did you select the disc type, framerate, and video system appropriately in the settings page? I think it uses these to determine how to perform a number of other tasks. (ie, if you left it at the default VCD setting, it might run the multiplexer in VCD mode).
-
Update
I've done a good deal of research since my last posting, which has lead to some interesting discoveries you may be interested to know about.
First, to follow up on Kinneera's question, the program appears to remain synced for about 20 minutes, then the audio starts dropping behind the video. The phenomenon is very similar to the sync drift observed when the I-author-muxed stream is compiled by VCDImager, except that it's present in the program stream prior to compilation. Hmmm.
It turns out that TSVC acts as a shell for a program called MPLEX, which like VCDImager, is a GNU-type utility that runs in a Win32 environment via the Cygwin dll. The settings on the multiplex page are the only ones that get passed to MPLEX, which detects parameters such as resolution and frame rate on its own. I did change the settings on other pages to conform, but this was just a formality. Several attempts at multiplexing inside and outside of TSCV yielded the same (incorrect) result.
bbMPEG
It occurred to me that AVI2MPG2 is just a shell for accessing bbMPEG outside Premiere, so if I were to install Premiere to act as a shell for bbMPEG instead, would that work? Indeed it does. A ludicrously inefficient solution perhaps, but a solution just the same.
Multiplexing with bbMPEG gave me a program stream that was in-sync from end to end, that remained in sync when compiled with VCDImager. The outcome predicted by Kineera's theory was the one I actually observed. Well done, Kineera!
Note to HVR: Most authoring packages (VCDTK, I-author, et al) include a multiplexer specifically designed for that package. Being open source and all, would it be feasible to extract bbMPEG's multiplexing algorithm into a standalone CLI-based binary that could be distributed along with VCDImager?
Pulldown
Naturally I created a second MPV using 2:3 pulldown and multiplexed with bbMPEG, but the result was absolutely bizarre.
Previewing the file in MediaPlayer, for the first 35 seconds the program runs smoothly but quickly, as if the cast were on amphetamines. After that, the program morphs into a bad episode of Max Headroom with the frames playing out-of-order and sometimes repeating and jumping forward to the next GOP. Comical, really.
Now, I don't consider this to be a problem because I never intended to use pulldown.exe in the first place. But for extra bonus points in the brainteaser category, would someone like to opine as to why this happened? I think I can explain it, but I wanted to hear a few other takes before delivering the punchline. -
So bbMPEG delivers!
As for the your other observation, I have no idea... One of the privileges of living in the PAL world is that I don't have to worry about the whole NTSC-FILM vs. NTSC thing.
Regards.Michael Tam
w: Morsels of Evidence -
well, actually mplex is supposed to become the offical vcdimager multiplexer...Originally Posted by KoalaBear
(the mjpegtools and the vcdimager project have had knowledge exchange going on since the beginning...)
but it won't be included into vcdimager, since it doesn't belong there and I don't have the time to maintain 2 code bases; I'd rather want to see mplex maintained independently from the vcdimager package....
regards, -
HVR:
In the first paragraph of my most recent posting I noted this:
If VCDImager and MPLEX share a common codebase, that code in some way is implicated in the sync drift observed using either program. The I-author multiplexer (and others I would suspect) handle NTSC-FILM sources correctly, but MPLEX does not. To the extent the programs are interwoven with one another the end user has only one viable choice: multiplex with bbMPEG or don't use NTSC-FILM at all.The phenomenon is very similar to the sync drift observed when the I-author-muxed stream is compiled by VCDImager, except that it's present in the program stream prior to compilation. Hmmm.
However, NTSC-FILM is a compliant VCD framerate and to the extent that VCDImager is designed to compile both kinds of disc, the underlying problem remains the same.
Until MPLEX is fixed, VCDImager will be broken. -
Hmmm, well it sounds like the timestamps and such definitely got completely hosed!Originally Posted by KoalaBear You didn't try to apply a 2:3 pulldown to a 29.97 fps stream, did you? If you use the pulldown.exe tool, you want to tell bbMPEG to automatically detect the sequence header, otherwise it will probably all go to hell like you described. If you use pulldown.exe and tell bbMPEG to use 2:3 pulldown, I think it will actually double the pulldown, producing some bizarre framerate like 34 and totally destroying the timestamps in the sequence. Just a thought.
-
Aaaaaaaaah. I was waiting for you, Kinneera. :)
Actually the answer is similar to the Zen koan, "What is the sound of one hand clapping?" which is similar to the question, "what is the field rate of NTSC-FILM?"
The NTSC-FILM field rate is equivalent to the frame rate: 23.976fps in both cases. Progressive encoding is atomic: there are no "fields" per se, so breaking the picture in two for the purpose of display-rate matching is impossible from the decoder's point of view. You can route the decoder's output to a meta-circuit who's purpose in life is to ask, "Okay, if this is what the decoder is giving me to output, how do I bring that in line with the NTSC field rate I'm supposed to display," but a software encoder is ignorant of the difference.
Rather than repeating fields it repeats entire frames, outputting them at the nominal frame rate (29.97fps) until the decode buffer is saturated and it literally has no idea what to do next, so the entire system breaks down in an unpredictable way.
Had I planned on using pulldown.exe, the smart move would have been to encode the frames in an interlaced fashion so the decoder would know what to do with them when it came time to interpolate the fields into frames for display. But since I coded them as progressive, i.e., zigzag scanning, they were presented to the decoder wholistically upon reconstruction and it failed because it didn't know how to handle that (admittedly perverse) case.
At least that's my theory, which is wholly consistent with the observed result. I could be wrong, but in this case I don't think so: the theory fits the observation too well to not have a causal relationship.
Quote
Visit Homepage
