I seem to be having a problem where I'm getting artifacts in a realitively high bitrate mpeg2 video.
Its encoded at nearly 9000kb/s, and really shouldn't have any artifacts at all. The source is a 1080p video that I'm converting to a dvd. The command line I was using was:
ffmpeg -i *.mkv -s 720x380 -vcodec mpeg2video -aspect 16:9 -padtop 50 -padbottom 50 -g 12 -b 9301k -bufsize 4096k -minrate 8700k -maxrate 9300k -an foo.m2v
I looked into encoding with multipass but with the above settings, ffmpeg yields an error on the second pass and just encodes the source video again.
Any ideas on what i can do?
+ Reply to Thread
Results 1 to 25 of 25
ffmpeg -i *.mkv -s 720x380 -vcodec mpeg2video -aspect 16:9 -padtop 50 -padbottom 50 -mbd rd -flags +trell -mv0 -cmp 2 -subcmp 2 -g 12 -cgop -b 9301k -bufsize 4096k -minrate 8700k -maxrate 9300k -an foo.m2v
Let me know if it's any better (or worse)
With your bitrate thresholds set so close you probably won't see much benefit from 2-pass anyway.
there must be an error in the command line you gave:
ffmpeg -i *.mkv -s 720x380 -vcodec mpeg2video -aspect 16:9 -padtop 50 -padbottom 50 -mbd rd -flags +trell -mv0 -cmp 2 -subcmp 2 -g 12 -cgop -b 9001k -bufsize 4096k -minrate 8700k -maxrate 9300k -an foo.m2v
Unable for find a suitable output format for '2'
Originally Posted by ronkkrop
I was on a Windows box when I replied with no ffmpeg to try, I've used some of those extra switches successfully with "-target ntsc-dvd" but perhaps they don't work with straight MPEG-2. I'll try again on my Linux box. What ffmpeg are you using? The variations from version to version in Linux can be quite maddening.
Try this, sorry the -cmp "2" switch was the culprit and apparently doesn't work anymore. -cgop is optional so I took it out of the mix as well.
ffmpeg -i *.mkv -s 720x380 -vcodec mpeg2video -aspect 16:9 -padtop 50 -padbottom 50 -mbd rd -flags +trell -mv0 -cmp -subcmp 2 -g 12 -b 9001k -bufsize 4096k -minrate 8700k -maxrate 9300k -an foo.m2v
Okay so i ran your command line above and it still gave me errors ...turns out -cmp 2 and -mv0 are both to blame. There are only a few scenes that are really bad, and that command line actually made them worse. Is there some way i can increase the bitrate of just those scenes? AFAIK compliant DVD's are allowed 9800kbit video, so would it be possible to encode just those scenes using -ss and -t @9800kbit? and if so, how to concatenate them?
Is there some way i can increase the bitrate of just those scenes?
decently, BUT the matrix given will not allow the MPEG-compressor
to go above 7000kbps... See what I mean?
Originally Posted by Midzuki
OK that's a little weird because I write the presets for WinFF and those switches are basically taken from the DVD presets in WinFF that work for me both in Windows and Linux, Be that as it may obviously they are not helping you so perhaps ffmpeg is not going to help you. One thing I will mention is I did not use .mkv files to test so that may play into it as well. Perhaps Midzuki's suggestion of Mencoder is the way to go.
Have you tried -target ntsc-dvd in ffmpeg? Of course you will have to reformat your cropping/padding to work within a 720x480 16:9 A/R
Initially i was using -target ntsc-dvd, but the problem as i would learn is that PAL to NTSC is a bit tough without pulldown, which eliminates that option. I thought of using -target pal-dvd, but AFAIK, pal dvd's are interlaced and this is a 1080p source.
As for why I'm not using mencoder, at least at this point, is that i dont know enough about it. There are simply too many filters and options, and switches. Worst of all, there is a such thing as too much documentation, and the people over at mplayer need to learn that, reading a novels worth of man pages is a little much when trying to do the simplest of tasks.
But Gmaq i do like your command line, it actually helps in most of the video which i can use in the future to encode certain videos at lower bitrates maintaining quality. But in these stubborn scenes, they just make it worse. To help you understand, the scenes either involve smoke or clouds or any scene that has that sort of gradient look to it.
Originally Posted by GMaq
ffmpeg did just change it's api, yet again . I actually rolled back to an older version that has always worked well for me ( FFmpeg version SVN-r10652 ). Not sure if newer versions are better or worse than that one, but for the last week I've had nothing but issues with ffmpeg's SVN releases. Plus I already happened to have that version compiled and ready to go.
Stick with a tried and true ffmpeg release version. Since GMaq is the resident ffmpeg guru , stick with a version he suggests.Linux _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Hi there again.
AFAIK, even the most recent release of ffmpeg does not support the use of
custom quantization matrices. This the reason why I recommended mencoder.
All that I've learned about CQMs comes from the threads @ the Doom9
forums --- and from many hours of trials and errors and successes @ encoding
videos as well. However I feel that the real users of Linux do appear to consider
my posts in this thread a) full of misinformation b) irrelevant c) off-topic because
you're using ffmpeg instead of mencoder d) not worth commenting e) some of the above
f) all of the above, and therefore I will not dare interfering anymore.
Don't take it so personal Midzuk. I'm just not really a big fan of mencoder, when i first started encoding videos i started with ffmpeg which makes it easier for me to use. I find mencoder difficult because of its sloppy command line syntax and over documentation.
Your first post was not so much misinformation as it was too little information. Your example was full of facts but no reason. If you maybe explained to me why it applies to my situation, i would have entertained your idea.
Is there a specific reason for this option: -bufsize 4096k ?
If the output is meant for DVD, this value is too high.
Originally Posted by Midzuki
b Yep. Doesn't matter. The op had a question about ffmpeg. Use mencoder instead isn't a productive answer. I could have replied with a long detailed answer about using mplayer to filter and resize then pipe into mpeg2enc to achieve a DVD standard compliant m2v (which is something lavc codecs have issues with) but I didn't, as this question pertains to ffmpeg. Not which one should I use, why is my m2v created with ffmpeg being rejected for authoring a dvd, or has playback issues with some DVD players
d it's worth commenting on.
f not all.
You gave the so common and yet so destructive response that is common in Linux, it's down right disappointing how often it happens. A user asks a question about program A, and instead of help with A he is prompted to just use program B without a complete reason why. This doesn't help all.
If you would have replied something like - hey, ffmpeg doesn't always produce compliant DVD mpeg2 streams*, and has issues keeping the bitrate, lacks filtering capabilities, doesn't support high bitrate matrix, and most likely won't do what you want it to do in this case. Perhaps you should look at mencoder. I can help you with the options if needed as I've come across this same issue before.
^^ Now that would of been a good post.
Why not use Mencoder and give a try to a high-bitrate quantization matrix
^^ Big difference.
* Like everything else with ffmpeg, depends on which day you checked ffmpeg out of svn
http://ffmpegx.com/summary.html <- scroll down to The following is the list of all available quick presets figured that would be easier to reference than all of the mailing list posts and bug reports.Linux _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
How's things in Arch Linux land? I couldn't agree with you more about ffmpeg versions. I have nothing against SVN versions of course, in fact if you are wanting to push the envelope with new functionalities like HD, paff support etc. then they are the only choice. But if you want stability then stick with one that works, for instance in WinFF for Windows we are still using version 9017 because it is the only build that will execute all of the stock presets. As for Linux I am by no means a "guru" but in my experiences with distro-hopping this is what I have learned:
For Ubuntu, Mint and other Ubuntu derivatives use the "Medibuntu" ffmpeg found at www.medibuntu.org (instuctions for adding the repo are there)
For Debian users my first choice would be the "Etch" ffmpeg found at www.debian-multimedia.org, The ffmpeg in "Lenny" is also good but uses a different syntax for the codecs based on Library name instead of Codec name, So if you are using WinFF then the presets all have to be altered to reflect this.
For openSUSE users the ffmpeg from the Packman repo works well but has the same naming convention as the previously mentioned Debian "Lenny" one.
Of course this doesn't cover every distro by a longshot so if others would like to add please do.
If you look at medibuntu they have -
20070307 as the newest ffmpeg. That's over a year old, same as the version included with the soon to be released Hardy.
Marillat has -
The SVN checkout I mentioned above as myself using is -
20071003 <- not for any reason other than it's what I had, maybe I'll check out 20071206
With ffmpeg newer is not always better It's a moving target, like x264, where things have a high chance of breaking day to day. x264 happens to be much more stable at the moment with hardly any breakage.
I built a new machine and put Slackware-current on it. Quite enjoyable. Haven't booted Arch in maybe a week or so. Stable, fast, install once and use the PC for some work.Linux _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Originally Posted by hank315
Is anybody else willing to comment on his statement?
It is quite large, if thats the vbv buffer rate. 224k should be the setting for standard DVD and SVCD encoding with 46k(?) for VCD. I honestly always forget if DVD is 224 or 230 and if vcd is 46 or 40? I'm sure it's documented somewhere.
0.4.9-3.pre1 was used before any of the last years worth of svn commits. http://ffmpeg.mplayerhq.hu/changelog.html quite old if your version naming is correct from mandriva.
ffmpeg -formats | grep xvid FFmpeg version SVN-r10652, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --prefix=/usr --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-pthreads --enable-libogg --enable-libtheora --enable-libvorbis --enable-gpl --enable-pp --enable-swscaler --enable-x11grab --enable-libmp3lame --enable-libfaac --enable-libfaad --enable-libxvid --enable-liba52 --enable-libx264 libavutil version: 49.5.0 libavcodec version: 51.44.0 libavformat version: 51.14.0 built on Apr 12 2008 07:35:55, gcc: 4.2.3 EV libxvidLinux _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
-bufsize 1835k, that's according to the MPEG2 spec (8 * 112 * 2048)
Originally Posted by disturbed1
FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --prefix=/usr --enable-shared --libdir=/usr/lib --enable-liba52 --enable-pp --enable-gpl --enable-pthreads --enable-libnut --enable-x11grab --enable-dirac --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-x264 --enable-xvid --enable-libamr_nb libavutil version: 49.4.0 libavcodec version: 51.40.4 libavformat version: 51.12.1 built on May 12 2007 12:39:14, gcc: 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1) EV xvid
As for the wierd naming convention, thats probably because its a penguin liberation front rpm. They offer a wide variety of rpms that mandriva wont touch because of certain violations. In this case "This package is in PLF as it violates several patents."
Also -bufsize is the video buffer verifier, and i just ran it at 224k to re-encode my stream and it looks like s**t. Giant blocks of video, if you know what i mean. Any reason why that would be?
Originally Posted by ronkkrop
See Hank's post for buffersize. Same concept, using bits instead of kbits (1835/8=229.375)Linux _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Originally Posted by disturbed1
Thanks for all your help guys...i think that answers my questions, even some i didn't.