[MPlayer-users] Possible bug in -vo jpeg and -vo png

[Jason Pfeil]

RC,

I tried to use mencoder to multiplex the audio and video and got the
exact same results.  :-(  Things are perfectly in sync before the
troublesome section and then the sync is gone.  Here are the mencoder
commands I used:

# This creates the .m2v file from a bunch of .pngs in the current directory
mencoder "mf://*.png" -mf fps=24000/1001:type=png -of rawvideo -ovc
lavc -lavcopts vcodec=mpeg2video:vbitrate=10000:aspect=16/9 -o
test.m2v

# This multiplexes the .m2v file with the .ac3 file, producing a .mpg
file as output
mencoder -audiofile test.ac3 -rawaudio
format=0x2000:bitrate=128:rate=48000:channels=6 -audio-demuxer
rawaudio -ovc lavc -oac copy -lavcopts
vcodec=mpeg2video:vbitrate=10000:aspect=16/9 -of mpeg -mpegopts
format=mpeg2:vbitrate=10000:vframerate=24000/1001 -noskip -vf harddup
-o test2.mpg test.m2v

In answer to your question about whether I have framedrop enabled in a
config file, then why would it only drop frames in these spots where
little to nothing is changing?  Wouldn't frames be dropped elsewhere?

Here is my personal .mplayer/config file:
# Write your default config options here!
vo=xv
ao=alsa

This is the only place where the string "frame" appears in my
systemwide config file -- note that it is commented out:
# Drop frames to preserve audio/video sync.
#framedrop = yes

Thanks!

--Jason

On 7/11/06, Jason Pfeil <jason.pfeil at gmail.com> wrote:
> RC,
>
> I had tried to use mplayer more often, specifically to recomposite the
> JPEGs I was generating into the .m2v elementary MPEG stream for later
> mplex-ing.  Actually, I was using mencoder for the recombination
> process but it segfaulted repeatedly, just as did jpeg2yuv.  I have
> not tried mencoder for recombining the PNGs that I produce now, since
> I have this process down pretty good except for this video transition
> period.
>
> RC, if your email can handle it, I can send you the .avi file directly
> which you can then run my commands against and verify the issue.  I
> have no other explanation other than there is a problem with either
> the way mplayer handles the transitional frames, or the reencoding
> process is also borking the transitional frames.  I will try to use
> mencoder "mf://*.png" -mf . . . to recombine the PNG frames and see if
> that corrects the problem I have found.
>
> Thank you!
>
> --Jason
>
> On 7/11/06, RC <rcooley at spamcop.net> wrote:
> > On Tue, 11 Jul 2006 18:30:58 -0400
> > "Jason Pfeil" <jason.pfeil at gmail.com> wrote:
> >
> > > All of this works like a *charm*, except when the scene crosses a
> > > portion of the DVD which is composed of "black" frames.  It appears
> > > that when mplayer is dumping the series of PNG images, it is dropping
> > > duplicate frames.
> >
> > I just tried, and -vo png output 599 frames from a 599-frame
> > all-black-frames video.
> >
> > Do you perhaps have framedrop=yes in one of your mplayer config files
> > somewhere?  MPlayer normally doesn't ever drop any frames at all.
> >
> > BTW, it seems strange that you're using everything from ffmpeg to mplex,
> > to  mpeg2enc, while mencoder is probably capable of doing ALL of these
> > steps itself.
> > _______________________________________________
> > MPlayer-users mailing list
> > MPlayer-users at mplayerhq.hu
> > http://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
> >
>
>
> --
> Jason A. Pfeil
> jason.pfeil=at=gmail.com.NOSPAM
>


-- 
Jason A. Pfeil
jason.pfeil=at=gmail.com.NOSPAM