SVCD Scan offsets... making odd behaivior on standalone!

[homerpez]

This one is a new one. At least to me.

I made an SVCD-res MPEG-2 movie, off-spec VBR (500 MIN, 880 AVG, 2350 MAX). This was using CCE to encode video, TMPGEnc to do audio (Toolame), and bbMPEG to multiplex them.

I have now tried NERO alone, NERO with the "Scandata.dat" trick, and VCDImagerEasy and burning the .bin with NERO (which works properly, but still produced the same result).

On all 3, I can play my movie nicely on my Apex, if I go straight through, beginning to end. Oddly enough, I can also do GOTO search (albeit on a wrong timescale, 78:17 for a 1:45:16 movie) and that never worked before at all!

However, this is the behaivior I see when I FF/RW:

1:00 --> 2:26 --> 14:32 --> JUMP! 44:32 --> JUMP! 60:00 --> End of movie. At 1x FF speed.

60:00 --> 58:46 --> JUMP! Start of movie. At 1x RW speed.

Something is clearly wrong, maybe at the encode step, and maybe at the multiplex step.

Can someone who is doing this perfectly (C'mon, there must be someone out there) give some advice as to how to multiplex the right way for SVCD, while adding the correct offsets, while allowing it to play on standalone, and maybe even at the right timescale?

[adam]

I'm not sure this would be caused by the svcd scan offsets, unless it only happens when they are present of course. The offsets are just one way that a dvd player can use to maintain sync during playback and specifically when playback is interrupted, ie: ff, rw, pause etc. Different dvd players work better with different methods. So if you start losing sync a good thing to try is to uncheck add svcd scan offsets and uncheck allign sequence headers in bbmpeg while muxing.

Do you have any entrypoints in your svcd? Its clearly jumping to specified points throughout the movie rather than actually ff'ing.

This might be a long shot but it could be jumping to sequence headers. As a test try running your video stream through mpeg sequence maker (tools section.)If it is jumping to sequence headers then it should ff correctly now, since there will be a sequence header roughly every sec. Its basically just a workaround to trick your dvd player into ff'ing, rw'ing in a way that appears correct.

To prevent the need for mpeg sequence maker make sure the sequence header output is set to 1 and close gops is checked. This applies to both cce and TMPGenc. This is not necessary to be a compliant svcd BUT some dvd players require this to play the disk correctly, ff, rw etc...

I also have an apex..AD600a and I use cce or TMPGenc to encode and bbmpeg to mux. I always use the svcd default settings in bbmpeg, which means add svcd scan offsets and allign sequence headers are checked. Then I use I-Author to author menus and chapters and cdrwin to burn. All of my svcds ff and rw correctly and never lose sync. As far as the timescale, I have few svcds that are over 60 mins per disk, so I've never noticed before but Ill let you know. Again, all dvd players are different and even the same dvd players can have different firmware, so you might have to play with your proccess to fine tune it.

[homerpez]

I think maybe it was something odd with the way bbMPEG was doing offsets... I tried once again, using that tool I can never get to work the same way twice: VCDImagerEasy.

I this time remuxed the source streams with bbMPEG, but did not use it to create the offsets, I let VCDImager do that. I ran it through, burned it, and of course, it would no longer auto-play. Had to trick it into working

HOWEVER, it seems at though it fixed the FF/RW problem, at least in that it no longer skips violently like it did. But no GOTO search.

And as for timescale, still reports as being "too long" and it cuts displayed length to 100 minutes MAX... yet another problem, but I'll deal.

Apparently with PBC on (during VCDImager settings), it causes the disc to need to be "tricked" into working (won't play on ENTER, won't auto-play, or open with the "menu" function) so I'm trying another .bin without PBC mode.



EDIT: Mental note for everyone. Don't rely on bbMPEG to do your SVCD Scan offsets.

I burned the Disc again, no PBC this time, and it now auto-plays, runs nicely, no massive jumps. All because I used bbMPEG to apply the offsets, instead of VCDImager.

<font size=-1>[ This Message was edited by: homerpez on 2001-09-04 08:58:10 ]</font>

[homerpez]

Or not. HERE'S A RE-WORDED QUESTION FOR THE EXPERTS (please answer):

Just why would a VCDImager-generated SVCD cause my Apex player to REWIND when I press the RW button, and REWIND when I press the FF button! Yes, you read right.

On another movie, I ran the source streams through bbMPEG (SVCD mux, auto, align sequence headers but no offsets), then through VCDImagerEasy, non-standard format, and updating offsets using VCDImager. PBC unchecked (since this is the only was I got the last one to work) To this point, it is the same settings as the movie in my last post, which appeared to work properly.

OK. This time I burned the ".cue" file, using CDRWin 3.8D. It worked nicely, I put it in my Apex, and it played. GOTO even worked! However, when I pressed the FF/RW buttons... well... (SEE 2 PARAGRAPHS ABOVE).

What was the cause? Not using PBC this time, with a cue? Using CDRWin to burn? VCDImagerEasy going nuts? Are the offsets screwy with VCDImager too? (Isn't there ONE PERFECT SOLUTION for making VCDs)?...

Any and all help will is appreciated...


<font size=-1>[ This Message was edited by: homerpez on 2001-09-04 23:55:50 ]</font>

[hvr]

not an easy question.... but I'll try to answer it

regarding scan offset embedded in the MPEG video stream as user data:

there are two formats; asian and philips/IEC; the asian is expressed as a (unsigned) relative offset from the actual position, whereas the other variant is expressed as offset relative to the MPEG stream beginning in SMPTE format...

depending on which variant your player interprets (if it does interpret the scan offsets at all); it might do strange things if confronted with the wrong format...

regarding the GOTO issues...
as to nero vs CDRWin; it's always better to use CDRWin, as nero burns the MPEG tracks displaced by 150 sectors, thus making the scan points defined in SEARCH.DAT/SCANDATA.DAT invalid... that's why GOTO doesn't work sometimes with nero burned BIN/CUE's

this may also affect FF/RR if your device uses those scan point files for FF/RR;

wrong time display....

due to tracks.svd differences in format between asian and IEC/philips SVCD specs; the displayed times may have strange readings (this usually shows up only when you have more than one track)

this may also happen if your MPEG streams have GOP timecodes not being in sync with the PTS values... but it depends on the firmware used...


there are also a few other reasons, why a SVCD may not work properly, including firmware bugs/limitations;

as you see; it's not something that's just a bug in the authoring software, but more of a problem with having 2 slighly different specs for the same product name...

pioneer players solve this problem by not depending on the control files too much; and implementing FF/RR w/o the need for any scandata...

[homerpez]

But what I don't understand... why would one movie, encoded with the same program, multiplexed the same way, and run through VCDImagerEasy the same way to update offsets, react differently than a movie that worked?

The only difference between the working and non-working is that the non-working one was burned using CDRWin (cue), the working was burned using NERO (bin only).

I guess the question is... how can I get the scan offsets to work consistently? I'm not going to worry about timescale for now, I know the Apex has problems with that... but what's the exact proceedure for multiplexing with bbMPEG, and using VCDImager to author an off-spec SVCD?

I'd like to get the "better" way, CDRWin, to work properly for me...