On Fri, 7 Apr 2006, Nicolas wrote:
> OK. I just re-rendered the video, using 9600kbps for video and 224 for
> audio, and I still get the same result :
> mplex -f 8 -V 02.ac3 02.m2v -o 02.mpeg
It's not hurting anything (or helping ;)) but -V isn't necessary.
>INFO: [mplex] rough-guess multiplexed stream data rate : 9828000
>INFO: [mplex] target data-rate specified : 10080000
>INFO: [mplex] Setting specified specified data rate: 10080000
> ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=477476
> required(DTS)=477419
> ++ WARN: [mplex] Audio bd: buf= 11869 frame=000173 sector=00000077
> ++ WARN: [mplex] Video e0: buf= 80837 frame=000129 sector=00000447
> INFO: [mplex] STREAM bd completed @ frame 17656.
> INFO: [mplex] Scanned to end AU 14125
> INFO: [mplex] STREAM e0 completed @ frame 14125.
> INFO: [mplex] Multiplex completion at SCR=50848768.
> INFO: [mplex] Audio bd: buf= 5376 frame=000003 sector=00007848
> INFO: [mplex] Video e0: buf= 191896 frame=014125 sector=00316091
> INFO: [mplex] AUDIO_STATISTICS: bd
> INFO: [mplex] Audio stream length 15820672 bytes.
> INFO: [mplex] Frames : 17657
> INFO: [mplex] BUFFERING min 35 Buf max 9667
> INFO: [mplex] VIDEO_STATISTICS: e0
> INFO: [mplex] Video Stream length: 639098837 bytes
> INFO: [mplex] Sequence headers: 942
> INFO: [mplex] Sequence ends : 1
> INFO: [mplex] No. Pictures : 14126
> INFO: [mplex] No. Groups : 942
> INFO: [mplex] No. I Frames : 942 avg. size 67641 bytes
> INFO: [mplex] No. P Frames : 13184 avg. size 43642 bytes
> INFO: [mplex] No. B Frames : 0 avg. size 0 bytes
> INFO: [mplex] Average bit-rate : 9048400 bits/sec
> INFO: [mplex] Peak bit-rate : 9568000 bits/sec
> INFO: [mplex] BUFFERING min 15 Buf max 235543
> **ERROR: [mplex] MUX STATUS: Frame data under-runs detected!
>
> I'll rencode using 9000kbps for the video bitrate, just to be sure. But
> that's strange... :-/
Have to say that the rate control's working fine since the peak
is almost exactly 9600 - but wow, the average is right up against
(~5%) the peak. Be nice to know where that spike happens - applying
a filter over just that range of a few frames might be all that's
necessary.
Is there a lot of constant camera shake? Was this from a miniDV or
analog camcorder? Is it noisy? If it was from an analog capture
method did you blacken the edges where "VCR noise" hides?
There's something about the source that's creating files that
are right on the edge of being usable.
Maybe adding -E to the encoding parameters will help lower the peak
rate.
Maybe the default of "-b 230" (default for DVD/-f8) isn't quite enough,
and '-b 240' would work but that implies there's an anomaly in the
stream that's causing the buffer underrun.
There have been some changes to mplex since 1.8.0 was released but
none that I recall about general -f 8 multiplexing.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
