Xvid encoding in 11.1 KDE4 64bit

Hey-all:

I am having some serious issues with encoding in 64 bit OpenSuse 11.1. I run a mythbackend on it, and I’d like to be able to save shows via nuvexport. Unfortunately, nuvexport seems to pass bad commands to ffmpeg, because I get command errors when I run “nuvexport --debug”. The most common one is ffmpeg doesn’t know what option “-r29.97” is. I don’t know what it is either, but that is what nuvexport is passing to ffmpeg.

Nuvexport seems to run fine with mencoder, with the exception of the purple-splotch problem.

If I use mencoder, transcoder, or ffmpeg from command line, I get large amounts of purple splotches in the encoded movie. It’s usually around corners of objects when the camera is moving, but it is prevelant all over.

Lastly, I cannot rip dvds and encode them into Xvid either using k3b. K3b gives me this error:

Used versions
-----------------------
transcode: 1.1.0

transcode
-----------------------
e[31;1mtranscodee[0m]e31;1m criticale0m: Invalid argument for --progress_rate

ARGH! For a mythbackend, I really need something that will convert stuff to Xvid. Anyone know have any fixes to any of these problems?

BTW: The only extra repos I enabled were the:
libdvdcss repo
nvidia repo
packman repo

Thanks!

It sounds like you know a little about what you are doing. Have you checked these threads:

Multi-media and Restricted Format Installation Guide - openSUSE Forums

Check your multimedia problem in ten steps - openSUSE Forums

Have you tried avidemux - works for me

You can rip a title from a dvd like this:

mplayer dvd://1 -dumpstream -dumpfile movie.mpg

You may have better luck checking with a mythtv forum, to see if this is mythtv specific:
MythTV :: MythTV talk.com

Else you could try saving in another format, and then use a 3rd party app to convert to xvid. For example, microchip’s xvidenc script is packaged by packman and works well.

Thanks for all your replies!

I can convert outside of the nuvexport scripts, which is ok but not optimal. I can put nuvexport on the backburner for now, and also I will check MythTv::Discussion.

The main issue with Xvid is no matter how I convert to Xvid on this OpenSuse machine, it has the purple splotches. I have tried avidemux, and I get the same result as mencoder and ffmpeg on the command-line. I’ve also tried other’s scripts, with the same result.

Is there some library both ffmpeg, mencoder, & transcode all call when they do xvid? I’ve already blown-away this installation once and started from scratch (for unrelated reasons), and it did the purple splotch thing in both. So, I think it is something to do with 64bit OpenSuse.

that’s very odd. I’ve never had such issues with the listed encoders. Yes, all encoders call the Xvid library libxvidcore.so.*

I’m not sure about ffmpeg/transcoder, but mencoder uses the static Xvid library libxvidcore.a

I would say you compile mplayer (which includes mencoder) yourself from SVN (a lot of time, the packaged mplayer from Packman is screwed). It’s very easy to compile mplayer. If the problem still persists, then something is very wrong with your system/lib

64bit SUSE has nothing to do with this. I use 64bit SUSE and versions of these encoders for years and never had such a problem. (I always compile mplayer/mencoder/ffmpeg/x264/xvid from source though)

Thanks guys, that’s what I will do then. I’ll compile xvid and mplayer from source. I probably should’ve done that in the first place.

I will update the thread when I am done, in case anyone else has this issue.

Microchip8, is there any flags I should pass or anything, or will it install where I need it to go for OpenSuse to know where it is. I only ask because I know some distros use “/usr/local” and some don’t (for example). I’m pretty new to Suse when it comes to compiling.

Thank you all, again, for your help.

by default, if you don’t specify --prefix, both Xvid and MPlayer install in /usr/local and I think for you it will be a good idea to use /usr/local so, if you want, you can still have/run the older MPlayer from /usr/bin

no compilation CFLAGS are required either for Xvid or MPlayer. Just configure, compile and install Xvid first, then configure, compile and install MPlayer later. It will pick up the headers and libs of Xvid from /usr/local automatically (for sanity, remove xvid-devel package if you have it on your system)

All right, it’s mostly worked. I had to compile and install Lame, Xvid, nuvexport, and Mplayer in order to get it. And, mplayer still isn’t working correctly. BUT, mencoder is. I can use VLC for viewing, I don’t mind.

There is a trick to it though, especially using it with nuvexport. First, you’ll need to compile both Lame and Xvid with the flag:
–prefix=/usr/local/lib64

Otherwise, mencoder can’t find them, and will turn xvid and mp3 off.

I still can’t get ffmpeg to compile, it has all sorts of problems finding the libraries it needs. That’s fine though, as long as mencoder installs, I should be able to use ffmpeg from Packman for ogg and theora.

Oh, one more thing - MythVideo demands xvid, libmp3lame, mplayer and mencoder be installed for it to be installed (if you use Yast). So, I let them install and then renamed /usr/bin/mplayer and /usr/bin/mencoder to /usr/bin/mplayer.bak and /usr/bin/mencoder.bak so when the nuvexport script calls mencoder or MythTV calls mplayer it would call it from /usr/local/bin.

It’s an odd setup, but it works for me! No more purple-splotches when I encode Xvid. Thanks! :stuck_out_tongue:

Come to think of it, going forward, does anything think this is a Xvid package problem? I’m willing to be it is a packman-repo Xvid problem and not a mplayer/ffmpeg issue…

Just a thought.

I don’t use mythtv. I do exclusively use Packman. I encode to xvid a reasonable amount. I have never observed the effects you noted. Either the effects are too subtle for me, or this is not a Packman packaging problem.

That’s good to know. Possibly it’s just a combination of how things install on my specific hardware then. I can’t think of anything else.

Since both ffmpeg and mencoder call the same xvid libraries, and I had the same purple-splotch issue on each - and I had the issue on two clean installs of 11.1, I can’t think of anything else it could be than how it went on my specific hardware.

thanks!

I had the same exact issue with the purple splotches. I compiled xvid from source, and it solved the issue, only now xvid encoding is very slow. (15fps vs. 50fps for the same file) Have you noticed the same thing, or is your xvid encoding as fast now as it was with the purple problem? If it is as fast, what flags/options did you use when encoding that I may try in order to get it to work properly?

It is definitely slower, although how much slower I can’t say. I don’t think my computer ever hit as high as 50 fps, but it’s down to 20 fps or slower now.

I will say that even ignoring the purple splotches, the xvids made with packages from source look a lot better. Again, ignoring the purple splotches on the old xvids, I think the new xvids look a lot sharper and the color seems better. So, I do think I sacrificed speed for looks - and they all end up around the same relative size.

Thankfully I am not encoding a ton of stuff all the time. If you do figure out how to optimize xvid encoding, could you drop another line in this thread?

Thanks!

Will do. It’s frustrating for me because when I use the same programs in Windows XP32 on my dual-boot (FFmpeg and avidemux) the fps is up at 45. It should be faster in SUSE becuase it’s 64bit.

Thank you for responding. I had started another thread before posting here, so I’ll link to it if a solution is found.

Just wanted to say I have the same problem with my 64 bit opensuse 11.1. I didn’t have the purple dots with any suse version before. I noticed this error by using avidemux2_gtk and it seems to happen only with Xvid encoder.

I would be totally happy with other encoder options too but because I’m using lengthy scripts to convert my videos automatically, it’s not straightforward to change the encoder. In the moment I use another PC for Xvid encoding as I don’t do it much really. I hope it will be fixed in a couple of mouths or so. Otherwise I will compile from source too to get rid of this problem. :expressionless:

Compiling Xvid from source does seem to get rid of the problem. At least it did for queequeg and I, but YMMV. If you do compile it and it doesn’t fix it, let us know in the thread. We’ll localize the issue yet. :slight_smile:

Good news! – Kinda.

The latest xvid version in Packman gets rid of the purple-splotch issue, so you don’t need to compile from source anymore.

Unfortunately, it’s just as slow as the source-compiled one, so I’m beginning to think that the new version of xvid is just slow…

That is really good news, in one sense. At least someone realized there was a problem and they fixed it, albeit with the same results we had. :stuck_out_tongue:

Just to fully answer a question you asked me before, I was encoding a DVD to a xvid avi, and I was getting 5.9 fps for quite a while. I was doing other stuff at the same time, but this was on a AMD 5000+, and I’d think I would get a little better fps out of that.

Oh well, like I said, I don’t do a ton of encoding, and if I need to do something in a hurry I’ll do it on my Arch Linux machine.

Thanks for the update. Hopefully this will all blow over as time goes on.

Found a page that explains the issue here.

Basically it’s like this:

When you compile xvid 1.2.1
-if you have yasm installed - you get purple splotches (“old” packman repo)
-if you have nasm 2.03 or lower installed - xvid encodes very slow because it defaults to the c compiler (current packman repo)
-if you have nasm 2.04 or higher installed - xvid runs faster (can do yourself, see below)

Unfortunately, the SUSE repos don’t have anything higher than nasm 2.02 right now. I installed nasm 2.05 (here), recompiled, and am now getting about 23fps on my “test” file. (About a 40% increase).

This is still a lot slower than the previous version of xvid and slower than my WinXP32 xvid for some reason. I still don’t think this should be, so if somebody smarter than me knows what is going on please let me know.