[MEncoder-users] Re: forcing encode of lost frames as duplicates

Corey Hickey bugfood-ml at fatooh.org
Wed Aug 9 07:15:34 CEST 2006

Josh Sutton wrote:
> Corey Hickey <bugfood-ml <at> fatooh.org> writes:
>>> I'm trying to produce a video from a video server stream running 
>>> across a lossy wireless link.  The problem is that time needs to 
>>> be preserved even if frames are lost.  ie if I'm receiving nominally 
>>> 30 fps and say 20 frames are lost, then the remaining 10 frames should
>>>  be duplicated such that they still occupy 1 second. 
>>> The duplicate frames work fine using mplayer and displaying on the screen.
>>> If I start mplayer displaying on the screen and disconnect the ethernet to 
>>> simulate frame losses, then mplayer holds the last frame.  However when I
>>> use mencoder to either copy or reencode the stream to disk, the missing
>>> frames are skipped (not inserted), and the playback shows time 
>>> discontinuities.
>>> I've also tried using mplayer with the -vo jpeg option.  But skipped frames
>>> are not encoded.
>>> the mencoder.exe harddup switch does not work.
>> You mean '-vf harddup', right?
> Yep.  Reading between the lines, I don't think this is what the harddup is
> actually meant for, so it's not totally suprising that it doesn't do what 
> I want it to do.
> What I'm looking for is a tool that will blindly write new frames to disk even
> if they weren't received.  So that frame rate and hence playback time is
> preserved.   Perhaps there is a better way to achieve this than using these
> tools, but so far I have not found it.

Yeah, I was afraid that's what you meant.

>>> I suspect because the frames are
>>> missing, not duplicates.
>> What exactly is the video data you're feeding mencoder? Is it an MPEG,
>> or a series of JPEGs, or what?
> The input stream is an mpeg stream from an rtsp session.  The mencoder command
> line and output is below.  If frames are not received, then the transmit time
> stamp on the encoded video jumps from say 11 seconds to 13 seconds.  What I want
> is for the the encoded video to hold the frame received at 11 seconds for a full
> 2 seconds and then move on to the frames received at 13 seconds.

I can't think of any way to do that with mencoder, short of making a
patch for either the demuxer or muxer to generate those blank frames. I
don't have the time to figure out how to do that, though.

If anybody else has any good ideas then he or she should chime in.
Perhaps there is some creative use of mencoder or another program I
can't think of.

Good luck.


More information about the MEncoder-users mailing list