[MPlayer-users] Some issues in FLV encoding

[John Brown]

Alexander Bokovikov wrote:
> John Brown wrote:
>
>> You can download my MEncoder binary at:
>> http://download.yousendit.com/37C2D39D4E615431
>
>
> Thanks, have got it.
>
>> I can confirm that my most recent svn version 26094 does not correctly 
>> encode
>> the video and audio together in one pass, unless you add -mc 0 to the 
>> command
>> line.  However, an earlier version 25780 does. I used this command line:
>
>
> Stop, stop... Let's go step by step!
>
> First we talk about a simple thing -- pure MP3 output. I've tested your SVN 

OK, but unless you have a specific need to encode video and audio separately,
why bother?
> buid and have found that it still produces bad (shorter) file when I use abr 
> option. Though if I use cbr option, I get good file exactly as RC1 and RC2 
> do for cbr. 

OK. Do you have a particular reason for using abr? My understanding is that it
is not what people usually do.

> So, I can conclude, that SVN's "migrate" from stable to unstable 
> versions and back :) What can I say... That's a development process... 

A newer version is not guaranteed to work better than an older one.
Sometimes when they fix a problem, they break something else.

> Though it would be great if this thread would be noticed by someone, who 
> deals with this subject...

As I said earlier, you might have better luck if you posted to the mencoder
list at mencoder-users-bounces at mplayerhq.hu

>
> I yet need to test "your" SVN build for mute video production, therefore I'd 
> like to know your opinion about how (if) -vf harddup option (as well as -mc 
> 0) could help to make MEncoder to be more stable in several video formats 
> conversion into mute FLV. Will it be better to use them always, when I 
> produce mute video using -nosound option?

-vf harddup is *required* when encoding to MPEG, or you will get desync. 
For other containers (or maybe codecs?) it apparently makes no difference.
-mc 0 is one of the options to try when you experience desync. Sometimes it
is needed, and sometimes not. I assume that including it when it is not
needed can cause problems, but I don't know that for a fact. If you search
the archives, you can find a lot of information about avoiding desync.
You will see many suggestions that encoding audio and video separately
increases the likelihood of desync, although I don't know why.

>
> I'm asking this because I still consider 3-pass encoding, (because of 
> unstable SVNs):
>
> 1. A mute FLV production
>
> 2. Pure MP3 with CBR production
>
> 3. Muxing FLV + MP3 by my own utility.
>
>> mencoder.exe -o test.flv -of lavf -oac mp3lame -lameopts abr:br=64:mode=3
>> -srate 22050 -ovc lavc -lavcopts vcodec=flv:vbitrate=300 -vf harddup
>> -endpos 100
>
> I'm afraid you just did not notice missynch for such short time. As I see 
> for MP3, it works just in the same incorrect way when ABR is used. Though 
> I'll try to use it with CBR. As for audio, it works OK. So, there is a 
> chance that we'll make it to work with video/audio too.
>

You can download an archive containing the following samples:
http://download.yousendit.com/2D22B36C0F8BEF6F

One pass svn 25780
==================
$ menc-25780 -o test-25780.flv -of lavf -oac mp3lame -lameopts abr:br=64:mode=3
-srate 22050 -ovc lavc
-lavcopts vcodec=flv:vbitrate=300 -endpos 100 *.mov

One pass svn 26094
==================
$ mencoder -mc 0 -o test-26095.flv -of lavf -oac mp3lame -lameopts
abr:br=64:mode=3 -srate 22050 -ovc lavc
-lavcopts vcodec=flv:vbitrate=300 -endpos 100 *.mov

Three-step process - 26094
==================
$ c:/progra~1/multimedia/mplayer/svn/mencoder -o silent.flv -of lavf -nosound
-ovc lavc -lavcopts vcodec=flv:vbitrate=300 -endpos 100 *.mov

$ mencoder -mc 0 -o soundtrack.mp3 -ovc frameno
-of rawaudio -oac mp3lame -lameopts abr:br=64 -srate 22050 -endpos 100 *.mov

$ mencoder -oac copy -ovc copy -audiofile soundtrack.mp3 -of lavf -o
three-step.flv silent.flv

I need -mc 0 when I use svn 26094, but not when I use svn 25780. They all seem 
to be in sync to me. Are you saying that there is desync, but I don't hear it,
or are you saying that the sample is too short to produce desync?


>> I put the endpos there to stop it before it reaches the end of the file, 
>> which
>> is about 105 secs.
>
> Really, I've forgotten about it... Thanks for mentioning!
>
>> With the most recent svn, there are a lot of "Skipping frame!" messages 
>> (without
>> -mc 0: -vf harddup did not help, neither did -noskip) and I get the desync 
>> that
>> you described.
>
> Is it your 25780 or some newer? I saw a lot of "Skipping frame!" messages if 
> I use your build with ABR option. Though all is going OK if I use CBR.
>

I noticed the skipping with the newer svn 26094. I don't think that I tried
with abr. I would really recommend that you not bother with abr.

> Thank you for your help!
>
>