Hi everybody, After reading the doc and the archives, I chose these command lines: mencoder "$INPUT" -o /dev/null -really-quiet -demuxer 35 -of lavf -lavfopts format=flv -oac mp3lame -lameopts abr:br=64 -srate 44100 -ovc lavc -lavcopts vcodec=flv:vbitrate=1000:vqscale=5:acodec=mp3:abitrate=64:mbd=0:v4mv:keyint=125:trell:autoaspect:turbo:vpass=1 -sws 0 -vf harddup mencoder "$INPUT" -o "$OUTPUT" -really-quiet -demuxer 35 -of lavf -lavfopts format=flv -oac mp3lame -lameopts abr:br=64 -srate 44100 -ovc lavc -lavcopts vcodec=flv:vbitrate=1000:vqscale=5:acodec=mp3:abitrate=64:mbd=2:v4mv:keyint=125:trell:autoaspect:vpass=2 -sws 2 -vf harddup And, for a mp4 version: mencoder "$INPUT" -o /dev/null -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=dia:keyint=125:trellis=1:global_header:turbo=1:pass=1 -sws 0 -vf harddup mencoder "$INPUT" -o "$OUTPUT" -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=umh:keyint=125:trellis=1:global_header:pass=2 -sws 2 -vf harddup I am trying to balance quality and size. Do you see any problem? Something illogical? The -demuxer 35 solves many out of sync problems. What are the side effects? Less recognized video formats? Thanks, JD.
Hello, On 5/21/08, John Doe <jdmls@yahoo.com> wrote:
And, for a mp4 version:
mencoder "$INPUT" -o /dev/null -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=dia:keyint=125:trellis=1:global_header:turbo=1:pass=1 -sws 0 -vf harddup
mencoder "$INPUT" -o "$OUTPUT" -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=umh:keyint=125:trellis=1:global_header:pass=2 -sws 2 -vf harddup
I am trying to balance quality and size. Do you see any problem? Something illogical?
Well, there's already suggested "encoding profiles" here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html#menc-feat-x264-exam... Also, you shouldn't have to manually change the "me=" option between 1st and 2nd pass, "turbo" option already takes care of that. Guillaume -- I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom. -- George S. Patton
John Doe <jdmls@yahoo.com> writes:
And, for a mp4 version:
mencoder "$INPUT" -o /dev/null -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=dia:keyint=125:trellis=1:global_header:turbo=1:pass=1 -sws 0 -vf harddup
mencoder "$INPUT" -o "$OUTPUT" -really-quiet -demuxer 35 -of lavf -lavfopts format=mp4 -oac faac -faacopts mpeg=4:object=2:raw:br=96 -srate 44100 -ovc x264 -x264encopts bitrate=2000:vqscale=5:me=umh:keyint=125:trellis=1:global_header:pass=2 -sws 2 -vf harddup
(1) You don't need to encode audio on the first pass. To save cpu cycles, rather use -oac copy (2) last time I checked, lavf mp4 muxing was broken, although I don't recall right now the exact issues it had. Either way, most ppl including me use mp4box for muxing. You can for example first encode both streams into avi (default), then dump both streams and remux (3) -sws isn't really needed as long as you don't scale the video (4) "raw" in faacopts prevents remuxing and doesn't have any obvious advantage; I wonder how you came up with this (5) if you aim for (hard/software) playback compatibility, your x264 encoding options do matter; your's seem kind of arbitrary, I recommend checking out the MeGUI profiles (needs Windows though) for quicktime/ps3/xbox/whatever compatible profiles (6) faac generally isn't that great an encoder; I currently use nero, which isn't open source but "free as in beer" and runs on linux Apart from those, your options should be OK for PAL (resp. not otherwise interlaced or telecined) video exclusively. You might want to ask yourself though what the pressing reason exactly is for resampling the audio to 41kHz.
On Wed, 21 May 2008 17:45:29 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
(1) You don't need to encode audio on the first pass. To save cpu cycles, rather use -oac copy
Quite the contrary. Changing the audio encoder will very likely cause different frames to be dropped, resulting in lower quality 2-pass encoding, and potentially the second-pass crashing as well.
(4) "raw" in faacopts prevents remuxing and doesn't have any obvious advantage; I wonder how you came up with this
Necessary for direct output to mp4 with mencoder/lavf, as explained in the man page. No wonder you think that muxing to mov/mp4 is broken...
RC <cooleyr@gmail.com> writes:
On Wed, 21 May 2008 17:45:29 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
(1) You don't need to encode audio on the first pass. To save cpu cycles, rather use -oac copy
Quite the contrary. Changing the audio encoder will very likely cause different frames to be dropped, resulting in lower quality 2-pass encoding, and potentially the second-pass crashing as well.
I don't see that. Frame dropping/duplication will happen only to sustain the output frame rate, to which audio is synced at it's respective pcm sample rate, independent of any audio target encoding format. Especially, the audio encoding should not matter whatsoever regarding video frame handling. If you know more about algorithms at work deviating from this common scheme, please elaborate in detail. Apart from that, I've used those proceedings on many encodings, straight PAL or NTSC IVTC'd, and nothing ever crashed. Also, from my logfiles, I can't corroborate the statement that frame skipping/duplication differs on passes when a simple audio copy is done on the first pass.
(4) "raw" in faacopts prevents remuxing and doesn't have any obvious advantage; I wonder how you came up with this
Necessary for direct output to mp4 with mencoder/lavf, as explained in the man page. No wonder you think that muxing to mov/mp4 is broken...
Didn't find anything of what you say in the lavf section. In the faac section it rather says on "raw": "Do not set this flag if not explicitly required or you will not be able to remux the audio stream later on." Again, it'd be helpful if you pointed to the exact section where this requirement is supposedly made explicit.
On Wed, 21 May 2008 20:12:24 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
I don't see that.
That is, never the less, how mencoder works. It has been endlessly discussed on these lists before.
Again, it'd be helpful if you pointed to the exact section where this requirement is supposedly made explicit.
My mistake. It's in the HTML docs, not the man page.
RC <cooleyr@gmail.com> writes:
On Wed, 21 May 2008 20:12:24 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
I don't see that.
That is, never the less, how mencoder works. It has been endlessly discussed on these lists before.
Renders it pretty much unusable for that kind of 2 pass encodings I'd say.
Again, it'd be helpful if you pointed to the exact section where this requirement is supposedly made explicit.
My mistake. It's in the HTML docs, not the man page.
Still didn't find it. Link?
On Thu, 22 May 2008 10:27:38 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
Renders it pretty much unusable for that kind of 2 pass encodings I'd say.
I fail to see why. It isn't ideal, of course.
Again, it'd be helpful if you pointed to the exact section where this > requirement is supposedly made explicit.
My mistake. It's in the HTML docs, not the man page.
Still didn't find it. Link?
Hmmm... See -lavcopts vglobal / aglobal in the man page. That should help explain -faacopts raw and -x264opts global_header . aglobal / vglobal are also briefly mentioned in the HTML docs 13.4.
RC <cooleyr@gmail.com> writes:
On Thu, 22 May 2008 10:27:38 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
Renders it pretty much unusable for that kind of 2 pass encodings I'd say.
I fail to see why. It isn't ideal, of course.
Well, apart from burning considerable cpu time for nothing, with the knowledge that video is synced not to a time line, but rather to the audio stream - including the particular choice of audio encoder - and likely vice versa, let me ask the following question: how would you then proceed if, when performing a high quality dvd backup, you would like to save 2 or more audio streams into your backup? With all I learned from you, it'd be pretty much idle to even attempt this with mencoder and hope to get a sane result. Moreover, even if you were aiming only for a simple style one shot a/v encoding, if you found out something was wrong with the audio (not downmixed or normalized the way you wanted, maybe the bitrate was wrong etc) you could start over with a full a/v encoding right away. Which after all might take serious hours in case of a high profile encoding. Sorry, but calling that "not ideal" appears to be kind of an understatement to me. Unusable with respect to AVC/AAC encoding seems more to the point. Safe the simplest use cases maybe.
Again, it'd be helpful if you pointed to the exact section where this > requirement is supposedly made explicit.
My mistake. It's in the HTML docs, not the man page.
Still didn't find it. Link?
Hmmm...
See -lavcopts vglobal / aglobal in the man page. That should help explain -faacopts raw and -x264opts global_header .
aglobal / vglobal are also briefly mentioned in the HTML docs 13.4.
OK, from "it's in the man page" we now got down to "there's some info spread over the docs, and albeit the docs never explicitly mentioning the faac 'raw' requirement for lavf mp4 muxing, if you read through all of it and properly memorized every line, you might be able to infer that you need it". Just to put it into perspective. Apart from that, I still tend to consider the lavf mp4 muxer requiring raw aac and not allowing e.g. adts - well, limiting, if you will.
On Thu, 22 May 2008 20:40:17 +0200 "Raimund Berger" <raimund.berger@gmail.com> wrote:
Well, apart from burning considerable cpu time for nothing,
Audio encoding time is miniscule, compared to video, and a few options can speed it up further (eg. lame aq=9).
how would you then proceed if, when performing a high quality dvd backup, you would like to save 2 or more audio streams into your backup?
With all I learned from you, it'd be pretty much idle to even attempt this with mencoder and hope to get a sane result.
Quite the opposite. In fact, mencoder is likely the only program you'll ever come across that can handle such a task, while maintaining proper A/V sync. A pass through mencoder results in the audio and video streams being exactly the same length, and so an arbitrary number of audio and video streams can be seperated and re-multiplexed as needed. With just about any other encoder, the loss of time-stamps due to demuxing would cause severe desync.
RC <cooleyr@gmail.com> writes:
Well, apart from burning considerable cpu time for nothing,
Audio encoding time is miniscule, compared to video, and a few options can speed it up further (eg. lame aq=9).
We were talking about AAC. And I don't consider over half an hour full load on a single E6600 cpu miniscule.
how would you then proceed if, when performing a high quality dvd backup, you would like to save 2 or more audio streams into your backup?
With all I learned from you, it'd be pretty much idle to even attempt this with mencoder and hope to get a sane result.
Quite the opposite. In fact, mencoder is likely the only program you'll ever come across that can handle such a task, while maintaining proper A/V sync. A pass through mencoder results in the audio and video streams being exactly the same length, and so an arbitrary number of audio and video streams can be seperated and re-multiplexed as needed. With just about any other encoder, the loss of time-stamps due to demuxing would cause severe desync.
Which directly contradicts what you said and has been proven valid earlier. I.e. that syncing logic doesn't just involve the demuxer and muxer, but encoder choice and likely encoder settings up to the point of one stream depending on another in these regards. Just recall the frame skipping discussion above for reference. Furthermore, I don't see at all how the iterations needed for an encoding like outlined above could look like, given what I learned. Maybe you to want skip that advertisement lingo for a second and give a sketch of the commands you would use to perform a 2 audio stream dvd rip. Without detailed encoding options but still recognizable if you really encode or just stream copy, and with mentioning where you think encoding options have to be exactly the same.
On Wednesday 21 May 2008 17:40, John Doe wrote:
Hi everybody,
After reading the doc and the archives, I chose these command lines:
mencoder "$INPUT" -o /dev/null -really-quiet -demuxer 35 -of lavf -lavfopts format=flv -oac mp3lame -lameopts abr:br=64 -srate 44100 -ovc lavc -lavcopts vcodec=flv:vbitrate=1000:vqscale=5:acodec=mp3:abitrate=64:mbd=0:v4mv: keyint=125:trell:autoaspect:turbo:vpass=1 -sws 0 -vf harddup
vbitrate and vqscale at the same time makes no sense. Also, two pass makes no sense if you have vqscale. Here's the simplified explanation: vqscale controls how much to compress a frame, the more it is compressed, the less size it will use, and the less quality will be left. Some frames are complex and have a big size after compression even with high vqscale, some frames are simple and have a small size after compression even with low vqscale. With vqscale you sort of select how much to compress each frame. The resulting filesize is unknown, but you have a rough idea of how much quality you lose. vbitrate does this: it changes vqscale all the time, to make frames take roughly the same amount of space, so that over the entire file, it will only have used 1000kilobits per second, as in the example of vbitrate=1000. This makes it possible to aim for a specific filesize. two pass improves on this by collecting statistics during first pass, so that it can assign more bits to frames that are complex, and keep quality more even over the entire file. So, choose either vbitrate or vqscale, and if you use vqscale then you only want to do one pass, with the better options as below...
mencoder "$INPUT" -o "$OUTPUT" -really-quiet -demuxer 35 -of lavf -lavfopts format=flv -oac mp3lame -lameopts abr:br=64 -srate 44100 -ovc lavc -lavcopts vcodec=flv:vbitrate=1000:vqscale=5:acodec=mp3:abitrate=64:mbd=2:v4mv: keyint=125:trell:autoaspect:vpass=2 -sws 2 -vf harddup
...
bitrate=2000:vqscale=5:me=dia:keyint=125:trellis=1:global_header:turb o=1:pass=1 -sws 0 -vf harddup
I think x264 will even refuse to do anything when both bitrate and vqscale is specified :)
participants (5)
-
Guillaume POIRIER -
Jan Knutar -
John Doe -
Raimund Berger -
RC