Nico Sabbi wrote:

Nicolas Hesler wrote:

...

Can anyone offer any input to the following command line? I've been trying to refine for the highest possible quality of MPEG-2 while staying DVD compliant. The source is 24fps. (Note: format=mpeg2, because format=dvd does not work with Adobe Encore 2.0).

From what I understand, keeping GOP open, improves quality. Is this true? Is it 100% DVD compliant?

I'm not sure, but IIRC gops should be closed in dvds

...

Do I want to introduce B frames in my encoding? (The vb_strategy part of my command line is currently useless, right?) If parts of my video are reaching into 9-10 Mbs bitrate, would it beneficial to introduce B-Frames? Will it improve quality?

no, they will only harm quality

...

(This is probably a stupid question)

Are the sync issues with bframes only relevant to mpeg4 or lavf?

with lavf managed by mencoder: always

...

mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:tsaf:telecine / -vf scale=720:480,harddup -mc 0 -noskip -srate 48000 -af lavcresample=48000:0:2 -lavcopts / vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:keyint=12 / :trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=1:lmin=1 / :dc=10:vpass=1:vb_strategy=2:acodec=ac3:abitrate=224:aspect=16/9:vstrict=0 -ofps 24000/1001 -o $output $input

this -mc 0 -noskip is a myth, as far as I'm concerned: it may do some good with -ovc copy, but not when encoding video

Really??? Good to know. So, get rid of the vb_strategy thing too? This doesn't affect the GOP on 2pass without B frames right?

Nico Sabbi wrote:

Nicolas Hesler wrote:

...

Really??? Good to know.

So, get rid of the vb_strategy thing too? This doesn't affect the GOP on 2pass without B frames right?

vb_strategy affects only the placement of b-frames, and it's damn slow too _______________________________________________

So why have a b frames option in the first place, if it only degrades the quality? For smaller encodes? So as a rule, never use B-Frames unless you're concerned with space?

Nico Sabbi wrote:

Nicolas Hesler wrote:

...

Nico Sabbi wrote:

...

Nicolas Hesler wrote:

...

Really??? Good to know.

So, get rid of the vb_strategy thing too? This doesn't affect the GOP on 2pass without B frames right?

vb_strategy affects only the placement of b-frames, and it's damn slow too _______________________________________________

So why have a b frames option in the first place, if it only degrades the quality? For smaller encodes?

supposedly for encodes targeting a low bitrate, but even in cases like that I've only seen overall image degradation with b-frames, both with lavc and with xvid, at any bitrate

...

So as a rule, never use B-Frames unless you're concerned with space?

I never use b-frames _at_all_ , although with x264 b-frames maybe aren't so harmful (or maybe they are even beneficial, but I never tested the encoder extensively to say for sure) _______________________________________________

Thank you very much for all of your help.

On 6/7/07, Nico Sabbi <nicola_sabbi@fastwebnet.it> wrote:

Nicolas Hesler wrote:

...

Nico Sabbi wrote:

...

Nicolas Hesler wrote:

...

Really??? Good to know.

So, get rid of the vb_strategy thing too? This doesn't affect the GOP on 2pass without B frames right?

vb_strategy affects only the placement of b-frames, and it's damn slow too _______________________________________________

So why have a b frames option in the first place, if it only degrades the quality? For smaller encodes?

supposedly for encodes targeting a low bitrate, but even in cases like that I've only seen overall image degradation with b-frames, both with lavc and with xvid, at any bitrate

...

So as a rule, never use B-Frames unless you're concerned with space?

I never use b-frames _at_all_ , although with x264 b-frames maybe aren't so harmful (or maybe they are even beneficial, but I never tested the encoder extensively to say for sure)

Why would you never use B-frames in your encodes? Isn't that the whole point of encoding to MPEG-4? To save space without sacrificing quality?? I understand why you don't use B-frames on MEncoder because support is b0rked as far as I know (has this changed?) but for x264 MPEG-4 AVC etc. B-frames are great! If you're encoding for Quicktime with x264 I know it supports up to 2 B-frames, and generally I encode with 3 B-frames. It's great for compression and does not sacrifice quality at all (I can't speak for XviD or ASP compression, but I know from experience that B-frames on x264 and AVC compression is awesome).

Nico Sabbi <nsabbi@email.it> wrote:>my eyes scream against b-frames, at least in mpeg1/2/4 encodes :)

I've always seen many more artefacts with b-frames than without, at any bitrate

Bitrate should matter. This is one of the last things I tried mencoder.exe tey.avs -o MPHQ1.m2v -ovc lavc -lavcopts vcodec=mpeg2video:threads=2:ilme:ildct:alt:top=1:vpass=1:turbo:vqmin=1:lmin=0.01:vqblur=0:vqscale=2:vrc_maxrate=9800:vrc_buf_size=1835:keyint=15:vqcomp=0.75:vmax_b_frames=2:vb_qfactor=1.25:vb_qoffset=0.0:vi_qfactor=1.0:vi_qoffset=0.0:me_range=128:preme=2:mbd=2:aspect=16/9:inter_matrix=20,21,22,23,24,25,26,27,21,21,22,23,24,25,26,28,22,22,23,24,25,26,28,30,23,23,24,25,26,28,29,32,24,24,25,26,28,31,33,35,25,25,26,28,31,34,36,39,26,26,28,29,33,36,41,43,27,28,30,32,35,39,43,48:intra_matrix=8,16,16,16,17,17,18,19,16,16,16,16,17,18,19,20,16,16,16,17,18,19,20,22,16,16,17,18,19,21,23,26,17,17,18,19,21,24,27,31,17,18,19,21,24,28,33,40,18,19,20,23,27,33,42,51,19,20,22,26,31,40,51,64 -of rawvideo -ffourcc MPG2 mencoder.exe tey.avs -o MPHQ2.m2v -ovc lavc -lavcopts vcodec=mpeg2video:threads=2:autoaspect:ilme:ildct:alt:top=1:vpass=3:vqmin=1:lmin=0.01:vqblur=0:vbitrate=3580:vrc_maxrate=9800:vrc_buf_size=1835:keyint=15:vqcomp=0.75:vmax_b_frames=2:vb_qfactor=1.25:vb_qoffset=0.0:vi_qfactor=1.0:vi_qoffset=0.0:me_range=128:preme=2:dia=3:predia=3:mbd=2:mbcmp=256:precmp=256:cmp=256:subcmp=256:mv0:trell:cbp:dc=8:psnr:aspect=16/9:inter_matrix=20,21,22,23,24,25,26,27,21,21,22,23,24,25,26,28,22,22,23,24,25,26,28,30,23,23,24,25,26,28,29,32,24,24,25,26,28,31,33,35,25,25,26,28,31,34,36,39,26,26,28,29,33,36,41,43,27,28,30,32,35,39,43,48:intra_matrix=8,16,16,16,17,17,18,19,16,16,16,16,17,18,19,20,16,16,16,17,18,19,20,22,16,16,17,18,19,21,23,26,17,17,18,19,21,24,27,31,17,18,19,21,24,28,33,40,18,19,20,23,27,33,42,51,19,20,22,26,31,40,51,64 -of rawvideo -ffourcc MPG2 extremely slow, but good, and metric wise, unparalleled. Could you send me your commands so I might try them. ty --------------------------------- Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta.

Nicolas Hesler wrote:

Justin Randall wrote:

...

I understand why you don't use B-frames on MEncoder because support is b0rked as far as I know (has this changed?) but for x264 MPEG-4 AVC etc. B-frames are great! If you're encoding for Quicktime with x264 I know it supports up to 2 B-frames, and generally I encode with 3 B-frames. It's great for compression and does not sacrifice quality at all (I can't speak for XviD or ASP compression, but I know from experience that B-frames on x264 and AVC compression is awesome).

How is support broken ?? I certainly can't seem to create a mpeg2 with b frames with MEncoder 1.0rc1-4.1.2. Am I doing something wrong? It continually crashes mencoder when I try to use vmax_b_frames=2:vb_strategy=2.

we need a gdb backtrace for cases like this

Nicolas Hesler wrote:

...

...

How is support broken ?? I certainly can't seem to create a mpeg2 with b frames with MEncoder 1.0rc1-4.1.2. Am I doing something wrong? It continually crashes mencoder when I try to use vmax_b_frames=2:vb_strategy=2.

I can't reproduce it with SVN. You should use a build of mencoder from recent SVN; by now, 1.0rc1 is old.

...

we need a gdb backtrace for cases like this

what does that mean?

See this page: http://www.mplayerhq.hu/DOCS/HTML/en/bugreports_what.html#bugreports_crash If you for some reason cannot make a backtrace, then a sample command line and a sample source video will often suffice. Having a backtrace too is still nicest, though. -Corey

On Thu, 7 Jun 2007, RC wrote:

On Thu, 7 Jun 2007 Nicolas Hesler wrote:

...

So why have a b frames option in the first place, if it only degrades the quality? For smaller encodes? So as a rule, never use B-Frames unless you're concerned with space?

You're _always_ concerned about space. Otherwise you wouldn't be compressing the video. B-frames improve quality-per-bitrate at all bitrates except lossless, but not on all content. Sufficiently high motion can make B-frames useless, but a good codec can disable B-frames in just those regions.

B-frames are a tricky issue. At lower bitrates they help significantly with gradual scene transitions (fades), but they can hurt the overall quality even more in some cases.

It seems they mainly exists in (hardware) encoders for simple, single-pass ratecontrol, and so lots of standards mandate their use.

As the author of x264's ratecontrol, I can say that B-frames make 1pass CBR ratecontrol harder (both in implementation complexity and in chance of violating VBV), and have no effect at all on the difficulty of unrestricted VBR. The only reason I can think of that any standard might mandate the use of B-frames is to allow fast-forwarding by skipping the B-frames, if you don't have a fast enough decoder to process all frames at greater than realtime. --Loren Merritt

Nicolas Hesler wrote:

Nicolas Hesler wrote:

...

Nico Sabbi wrote:

...

this -mc 0 -noskip is a myth, as far as I'm concerned: it may do some good with -ovc copy, but not when encoding video

Really??? Good to know.

I just did a quick test removing the -mc 0 and -noskip. I get more errors than usual

what errors?

and the A-V deviates from 0.0. With -mc 0 and -noskip, I wasn't getting that deviation.

Pos: 10.5s 253f (13%) 8.53fps Trem: 3min 35mb A-V:0.052 [3818:223]

-mc 0 -noskip disables mencoder's synchronization code; that combination may work for some type of files, but not for many other types (e.g. digital tv broadcast that typically have a large amount of audio preload). You should test the actual synchronization in the final encode rather than relying on those figures

Nicolas Hesler wrote:

I typically get these messages when encoding with -mc 0 -noskip:

ERROR: scr 0.940, dts 0.909, pts 0.951

BUFFER UNDEFLOW at stream 0, raising muxrate to 2635 kb/s, delta_scr: 167857

Without -mc 0 -noskip I get the same type of messages but also duplicate frame errors :

1 duplicate frame(s)! ERROR: scr 1.642, dts 0.000, pts 1.266

and the out of sync messages:

Pos: 0.6s 15f ( 1%) 11.85fps Trem: 1min 11mb A-V:0.058 [0:0]

Note: If I were to use format=dvd with the -mc 0 -noskip, I don't get any messages, which I take as a good sign. (But as I mentioned before, I have to use format=mpeg2 for Adobe Encore to accept the files)

to fix those errors just add :muxrate=10080 to -mpegopts

If I use format=dvd without the -mc 0 -noskip, I get :

1 duplicate frame(s)! Pos: 0.9s 22f ( 1%) 10.83fps Trem: 2min 8mb A-V:0.084 [0:224] Skipping frame!

Also, I'm transcoding from high bitrate MPEG-2 of 18.5 Mbs 1280x720 to my current avg of 6-7 Mbs at 720x480.

So, is -mc 0 -noskip still unnecessary, eventhough I'm getting these out of sync and duplicate frame messages?

if adding those options keeps sync use them, but generally they don't magically fix asynchrony

My understanding is that the "Skipping Frame" message is a bad sign.

if they are many yes, it's a bad sign, but not necessarily if they are few. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: In REGALO 'All the Good Thing' di NELLY FURTADO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6617&d=8-6

Nicolas Hesler wrote:

...

Thanks again for your prompt help. Why do you say magically? What is controversial with those options?

as I wrote, -mc 0 -noskip disables mencoder's mechanism to keep synchrony -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Pioneer112d 29,90� - Dvd TDK da 0,299� - Cdr Verbatim printable da 0,29� - Stampa Foto da 0,06� � Cdr Verbatim super azo da 0,216� Questo e molto altro ancora lo trovi su atomicshop.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6577&d=8-6

Nicolas Hesler wrote:

Nico Sabbi wrote:

...

Nicolas Hesler wrote:

...

...

Thanks again for your prompt help. Why do you say magically? What is controversial with those options?

as I wrote, -mc 0 -noskip disables mencoder's mechanism to keep synchrony

I guess what I meant to ask was : so mencoder's mechanism for keeping synchrony doesn't always work and disabling sometimes keeps sync?

yes

So even if I get 1 duplicate frame (which seems to be case, in all my videos), it could still be in absolute sync?

yes

How is it that the A-V sync info is not always an indicator of sync?

sometimes, with some crazy containers used in horrible manners (think of mpeg*, H264 of avi, packed mpeg4 in avi and other amenities) mencoder doesn't even know the correct timestamps of the original streams, thus you can't expect it to do a good job in the output stream -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vacanza in Grecia: 7 giorni con trattamento all inclusive in albergo 4 stelle a soli 479 Euro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=8-6

On Fri, 8 Jun 2007 10:13:53 -0400 "Justin Randall" <jrrandall@gmail.com> wrote:

I was under the impression that using -harddup at the end of the filter chain will preserve A-V sync thoughout the steam,

harddup resolves one issue that can cause desync. There are many others.

Nicolas Hesler wrote:

Nico Sabbi wrote:

...

Nicolas Hesler wrote:

...

So even if I get 1 duplicate frame (which seems to be case, in all my videos), it could still be in absolute sync?

yes

I just ran another test using a couple of different clips with -noskip and -mc 0 removed and noticed the following:

The duplicate frames happen at the same intervals on different clips. It seems as though they always happen at 1.0s (25f), 83.4s (2002f), 166.8s(4004f), and so on until near the last frames. Can you explain why it says it's skipping frames in such a pattern? (Because my current clips are small, I'm compiling a large clip to see if the pattern continues).

ENABLED SOFT TELECINING, FPS=29.97, INITIAL PATTERN IS TFF:0, RFF:1

1 duplicate frame(s)! Pos: 1.0s 25f ( 0%) 5.39fps Trem: 10min 120mb A-V:0.085 [7292:224] Skipping frame! Pos: 83.4s 2002f (39%) 6.01fps Trem: 8min 157mb A-V:0.061 [5998:224] Skipping frame! Pos: 166.8s 4004f (79%) 6.01fps Trem: 2min 158mb A-V:0.061 [5996:224] Skipping frame! Pos: 208.5s 5005f (99%) 5.99fps Trem: 0min 157mb A-V:0.060 [5963:224] Skipping frame! Pos: 210.7s 5058f (100%) 6.04fps Trem: 0min 156mb A-V:0.028 [5908:224] Flushing video frames Writing index...

Overhead: 1.496% (2416636 / 161523716) Writing header...

Video stream: 5908.883 kbit/s (738610 B/s) size: 155632964 bytes 210.710 secs 5058 frames

Audio stream: 224.000 kbit/s (28000 B/s) size: 5911808 bytes 211.136 secs

OK, So now I've refined my command line a little more, I've added the muxrate to mpegopts (which removed the error messages I was getting) and I've removed the -mc 0 and -noskip until I can figure out if I have a sync problem or not. The curious thing about the skipping frames is that my input is exactly 24fps (not 23.976) and my output is 23.976. If you take the difference (0.024 x the seconds where it was skipping frames, you end up with almost exact integers of 2,4,6, etc.) any ideas on that? BUT, I've got another problem (that it appears I've had all along with mencoder encodes), which I've only just discovered and that is that I have pulsating (grain/artifacts) frames at what I'm guessing is every keyint. It's not noticeable on every video I've encoded but some become unwatchable. I've tried encoding with b frames and closed gop, but to no avail. I've tried simplifying my command line to make testing for manageable but had no luck with ( mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:keyint=12: trell:mbd=2:vpass=1:acodec=ac3:abitrate=224:aspect=16/9:vstrict=0 -ofps 24000/1001 -o $output $input) Any ideas on how to resolve the pulsating??? current command line: mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:keyint=12: trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=1:lmin=1:dc=10: vpass=1:acodec=ac3:abitrate=224:aspect=16/9:vstrict=0 -ofps 24000/1001 -o $output $input

Nicolas Hesler wrote:

Nicolas Hesler wrote:

...

The curious thing about the skipping frames is that my input is exactly 24fps (not 23.976) and my output is 23.976. If you take the difference (0.024 x the seconds where it was skipping frames, you end up with almost exact integers of 2,4,6, etc.) any ideas on that?

I've just completed another test on a longer video to confirm my findings. Ok, So If you take the exact frame location where the frame was skipped and divide it by the incoming frame rate (exactly 24fps (not 23.976...)) and then multiply that by the difference in frame rate between the input (24) and the output (24000/1001), you end up with exact integers (2,3,4,5,6,7), although sometimes it does not report skipping a frame at a given integer (see below...it doesn't report at 6, 8, 11, 13). Another number that is recurrent is the difference between skipped frames which is usually 1001 frames. This must all somehow make sense. But I don't know how. Anyone?

it's pretty basic arithmethics with - probably - some added rounding error. Why don't you remove -ofps and use -mpegopts :tele_src=24:tele_dest=3000/1001 ?

Nicolas Hesler wrote:

I get the following message when using tele_src and tele_dest. I assume it isn't supported in my version of mencoder but more recent versions don't allow for the creation of Encore compatible mpegs, which for the moment, I'm stuck with. Good to know there's another option... So I would use those options instead of :telecine or in addition to for a soft telecine?

instead of. Use an svn checkout to use them

Nicolas Hesler wrote:

...

BUT, I've got another problem (that it appears I've had all along with mencoder encodes), which I've only just discovered and that is that I have pulsating (grain/artifacts) frames at what I'm guessing is every keyint. It's not noticeable on every video I've encoded but some become unwatchable. I've tried encoding with b frames and closed gop, but to no avail. I've tried simplifying my command line to make testing for manageable but had no luck with

( mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:keyint=12: trell:mbd=2:vpass=1:acodec=ac3:abitrate=224:aspect=16/9:vstrict=0 - ofps 24000/1001 -o $output $input)

Any ideas on how to resolve the pulsating???

current command line:

mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:keyint=12: trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=- 10:cbp:mv0:vqmin=1:lmin=1:dc=10:>vpass=1:acodec=ac3:abitrate=224:aspect=16/9:vstrict=0 -ofps 24000/1001 -o $output $input

vstrict should be set to 1 and dc=10 looks very suspicious to me when targeting dvd. Someone suggested some variation on vi_qfactor and vi_qoffset to reduce the pulsating effect, but unfortunately I don't remember the values he adviced. Another parameter I always use is sc_threshold=-1500 to increase lavc's sensitivity to scene changes

I've tried setting the vi_qfactor and vi_qoffset suggested here: http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2006-April/002770.html -lavcopts vi_qfactor=0.1:vi_qoffset=1.5: but it didn't improve the pulsating or "pumping" as some people have described it elsewhere on the keyframes (keyint). I've changed the keyint parameter a few times to confirm that the pulsating coincided in frequency and it does. Can anyone suggest which parameters might have some influence over the pulsating on keyframes? Are the keyframes being compressed differently so much so that they "pulsate"? Any ideas on what I should experiment with to begin more tests? Note: My source content is cartoon, is 24 fps and soft-telecined, and the pulsating is most visible in darker areas but that is probably just a perceptual thing.

On Thu, 07 Jun 2007 22:25:38 +0200 Nico Sabbi <nicola_sabbi@fastwebnet.it> wrote:

I'm not sure, but IIRC gops should be closed in dvds

Only multi-angle DVDs need closed GOPs. I just happened to be reading-up on DVD GOP specs yesterday...

Hey Dude, you can post the code in: http://rafb.net/past/ and send the link to us see! 2007/6/8, Nico Sabbi <nsabbi@email.it>:

RC wrote:

...

On Thu, 07 Jun 2007 22:25:38 +0200 Nico Sabbi <nicola_sabbi@fastwebnet.it> wrote:

...

I'm not sure, but IIRC gops should be closed in dvds

Only multi-angle DVDs need closed GOPs. I just happened to be reading-up on DVD GOP specs yesterday...

can you post a link to such specs?

-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor: Mouse Nortek usb 1,44€ - Dvd Verbatim 16x da 0,32€ - Cdr Memorex 52x da 0,16€ - Pioneer112d a 29,90€ - Stampa Foto a 0,06€. Solo su atomicshop.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6575&d=8-6

_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

-- -~----------~----~----~----~------~----~------~--~-------~-------~-------~----- ◊ Luciano Marinho (Programador PHP/C++) ♠ Meus sites: www.lucianomarinho.com.br ♣ www.racaboxer.com.br Linux Registered User #433536

On Fri, 08 Jun 2007 10:37:54 +0200 Nico Sabbi <nsabbi@email.it> wrote:

can you post a link to such specs?

Probably not what you're looking for, but fairly detailed: http://www.mediachance.com/dvdlab/helppro2/ Also if you're not already familiar: http://www.dvd-replica.com/DVD/productinfo.php http://dvd.sourceforge.net/dvdinfo

Does nobody have any idea about this problem, how to fix or avoid it? Lukas

Hi.

I'm trying to convert to flv, however I get the following error:

[flv @ 0x89b8c60]dimensions not set Floating point exception

This is the command I used: mencoder sourcevideo.mkv -of lavf -lavdopts fast:threads=4 -oac faac -faacopts br=96 -channels 2 -srate 44100 -ovc lavc -lavcopts vcodec=flv:vbitrate=500 -vf scale=800:448 -o destvideo.flv

I don't know what i'm doing wrong - in fact I am not even sure I am doing something wrong. Thre is a similar command exampl mentined here: http://blog.save-privacy.de/index.php?/archives/10-Flash-Videos-mit-dem-Menc... that is working according to the auther, but the same is not working for me (i only changed input and output filenames).

I checked out the latest version using git and compiled it.

Can you help?

Also, Is ther a way to encode to .mp4 directly using x264 and aac codecs (without other programs, since i want to stream the output over the internet eventually instead of storing on disk)?

Thanx in advance, Lukas

Btw, when using the x264 codec I had to use a version from November 2011 so that encoding works properly and does not give me this error: mencoder: encoder/slicetype.c:1632: x264_rc_analyse_slice: Assertion `cost >= 0' failed.

_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

-- Mit freundlichen Grüßen Lukas Österreicher mailto:lukas.oesterreicher@inode.at