On Saturday 24 December 2005 15:27, Andrew Stevens wrote: I've been offline due to a thunderstorm last night (Petropolis-Brazil). A surge protector has shorted after a lightning near my house, putting the dsl modem disconnected. The power lines are aerial in the streets.
> Hi Delio, > > Hmmm.... the fact that you get good sync after a FFWD or RWD suggests the > problem is not the overall multiplex strategy but something involving the > initial start-up. > > There are really not many significant significant differences between what > bbmpeg is generating and what mplex is generating... > > * Not start-up specific. > > 1. mplex is generating a stream with a mux rate of > 2137600 bps. This is very unusual in that it is *less* than the standard > SVCD mux rate. I would not be surprised if some player firmware might > have trouble with this. > > > * Start-up specific. > > 1. Start-up specific. mplex is generating a stream with a longer > 'run-in' (pause during which data is filled into buffers before decoding > starts). Hence all the mplex time-stamps are greater than the bbmplex ones > by exactly 45630 SCR ticks. Which is just over 0.5 seconds. > > * Fine details > > 1. mplex is marking the sequence header with the CSPS bit set (which is > technically correct) while bbmpeg is making CSPS=0. I don't know any > encoder which even looks at the CSPS. > > 2. bbmpeg is 'stuffing' pack headers with less than the maximum number of > fields rather than making them smaller and freeing the space for actual > data. > > > Based on my experience of problems of this kind I would suspect that it is > either the 'weird' mux-rate or the long start-up (or the combination > together) that is causing the problem. The CSPS stuffing are unlikely to > be issues since things work fine after a FFWD/RWD. > > > Unfortunately, since the problem is something that only shows up for a > specific player you'll need to try out modifications yourself as I won't be > able to replicate the issue. For the first step you'll need to checkout a > copy of the current CVS and get it to compile so you can try out the > results. > > As a very first thing you then need to try muxing with the latest mplex > using the standard mux-rate (etc). I.e use '-f 4'. In the meantime I'm > going to add special > Ok. I've mplex'd again with -f 4 with version: mjpegtools mplex-2 version 1.8.0 (2.2.4) Same result: out of sync During fading in, the sound come and go while volume is going up. As soon as the fading finishes, sound is normal, but before video. > > In the meantime I'll build into mplex a special 'work-around' flag that > will force the generation of a bbmpeg-like stream with a much shorter > run-in and (its trivial to change) CSPS=0. > I'm thinking of khexedit the mpg to put CSPS=0. Is there a simple string so that I can replace it? > If that doesn't work the next step is another 'workaround' flag that will > force fixed-size 'stuffed' headers like bbmpeg. > > cheers, > > Andrew > PS > Pls let me know a.s.a.p. once you've tested -f 4 with the current latest > mplex. > > > Can you check out a copy of the current CVS > and g I have two machines with mjpegtools: Fedora Core 1 with everything (compilers, apache, e-mail, etc) and Fedora Core 4 where there is only video related stuff (kino, mjpegtools, but no compiler). I usually use rpm through yum install, I'm not very comfortable with compiling from source, but I'll try it. Merry Christmas!!! ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
