On Mon, Nov 16, 2009 at 11:06:12AM +0100, Colin Rosenthal wrote: > Reimar D?ffinger wrote: > > You could really just try my suggestions (unless you want to learn about > > video coding, then you should say so but this is not the best place for > > it). > > If you drop or duplicate encoded frames that messes up the whole frame > > reordering code, so the frames will be displayed in the wrong order, > > thus it jitters forwards and backwards (in addition to the displayed > > frames usually being corrupted a bit). > > > I have tried your suggestion and it works fine for me. However it > doesn't really represent a solution > for all our users, many of whom will not be able to compile unfamiliar > software or be comfortable with > command-line options. I am rather confused on what you are trying to say. I only pointed out that you will almost always have to use -mc 0 -noskip with -ovc copy. Someone who is using -ovc copy obviously is already using the commandline. > It would be nice if we could > avoid heavy video transcoding and still be able to deliver a format > playable in, for example, vlc in > Windows. I will do some experimentation and probably come back with some > more detailed questions > later. VLC should be able to play almost anything (it couldn't play the other file without -mc 0 -noskip because that generated a broken file, nothing could play that no matter the amount of custom patches or command-line options). I think it would make more sense to target Adobe Flash player, if it can play it almost everything else can, too (excluding Windows Media Player, except maybe the Windows 7 version). You should not need to re-encode the video for that (except that I think Flash doesn't support deinterlacing, so it will look a bit ugly), not sure about the audio.
