I just wanted to drop in and say that this is a great script indeed. There are so many out there that don't even work, but this one does (at least on the avi's i tried it on).

Thanks and keep up the good work. :)

Thanks! I'm just happy that someone besides me finds it useful. If you do run into any problems, let me know!

Will do.

I guess many scripts in the past have died because the developers didn't keep up with the changes made in mplayer/mencoder/ffmpeg. It always happens, the commands or arguments get changed, and then the script becomes useless. Hopefully the same doesn't happen to this one.

As long as I keep using the script myself, I will definitely keep up on maintenance and continue to improve it. I've been doing a lot of DVD-making lately, and am using it almost every day. And of course, one of the great things about open source is that even if I stop maintaining it, someone else can take over.

True. :)

I did run into a problem (using tovid from sourceforge, non gui). Actually, i am not even sure if its even a script problem. I have someting in .asf extension. So i ran the script as usual (svcd, full), and the resulting mpeg, when played by mplayer, plays really fast, then ends. Its weird, but i have never really gotten *.asf's to ever encode into a vcd mpeg. Is there a extra step one has to do to do this correctly? I found the following:

http://www.greenspun.com/bboard/q-an...?msg_id=004IhX

And quite a few results on google that say the same thing:

Google Search.

They are suggesting to turn it into a avi first, then into a mpeg. Problem is they all say how to do it in windows, and i am not sure how to do it in linux.

mplayer exits out with the following when the resulting mpeg from tovid has finished playing:

The video was identified as the following:

Oh wow. 1000.00fps, just noticed that.

Let me know if you need more info.

Thanks.

Yeah, if there is a strange frame rate, the script will have some problems with it. This is one of the main sources of frustration I'm having at the moment - anything other than NTSC (29.97fps) or PAL (25.00fps), and sometimes film (23.796fps) for whatever reason usually does not get encoded properly. I even had a video recently that was 29.971 fps (0.001 different than 29.97) which seemed to encode fine, but the audio and video gradually got more and more out of sync in the finished movie. With weirder rates like 20fps, the output is usually complete garbage - video 10 times too fast and whatnot. I posted a thread about this recently. As near as I can determine, this is a bug with yuvfps, which is the utility doing frame rate adjustment, but it may also just be because I am not using it properly. I found one possible solution, which was to use mencoder to do frame rate adjustment, output the video in raw form, then encode that using the script - but a few tests showed that even that wasn't very reliable (not to mention it produces gigantic intermediate files - raw video is something like 4GB for 20 minutes at VCD resolution).

So, I am still working on that. I have a bunch of video sitting around on my hard drive that I don't know what to do with because of this problem. If you manage to do any tinkering and come up with possible solutions, I would love to hear about them!

alright, thx for checking. I'll try to look around and see what i find...

Tried this script on multiple files and this is usually the result - mplayer kicks in fine and then I get this error (from encoding an AVI to full-screen VCD) -


Then on a bigger file trying to encode to SVCD I get this, (full output) -

Then the script just ends and there are no files besides the original AVI. The error about "system too slow" doesn't quite make sense to me, I've got a 2.8 ghz p4 with 512 RDRAM. Also puzzling to me is the "unrecognized option -H" for mpeg2enc. So far I haven't been able to get the script to work with any video file I've tossed at it with all the various options.

Thanks for any insight.

weird. So far the only problems i have had with it are *.asf videos. Other than that it has been perfect. I have encoded maybe 4 avi files. Also, you say 'from encoding an AVI to full-screen VCD',but was the original avi full screen too? I don't think it can convert a widescreen to a full screen or vice versa.

Read_Icculus: It looks as though the "-H" option is not supported in your version of mpeg2enc. In my version (1.6.2), "-H" is the same as "--keep-hf"; looking at your output, it appears that your version of mpeg2enc wants "-h" (lowercase). At any rate, that's why it's not producing any video file (the m1v or m2v file). I'll look into patching this. In the meantime, you can fix it by editing the script in your favorite text editor. Look for these lines (304 through 306):

In the third line, you can just remove the "-H" or change it to "-h" or "--keep-hf". The option is supposed to increase quality, but it will probably be fine without it. Don't worry about the "Your system is too slow" warning - I think that only applies if you're trying to watch the video in realtime, which is not an issue when encoding.

As for sk545's comment: I've designed the script to be able to handle widescreen input with fullscreen output. If you have a widescreen video (approx. 16:9 aspect) and request "full" output, the video will be padded with letterbox bars. At least, that's what it's supposed to do! I haven't tested it too much, so if you have problems with that, let me know. DVD supports widescreen output, so there's not much sense in using it with DVD, but VCD and SVCD must always be full-screen, so the letterboxing has to be done for those.

cool. Thx for clarifying, i wasn't sure what it did exactly.

But, i guess the next 'easier' feature to implement would be to cut the resulting svcd, vcd mpegs into the proper sizes so they fit on a cd. There have been quite a few times where i run into that situation. Hopefully its easier to do, but what do i know.

Oh, and the problem that Read_Icculus had, is so typical with these scripts and is what i said in the beginning. Scripts die because of these problems.

You're right, one of the problems with this program (and many others) is the lack of robustness. Differing versions of the constituent programs can cause failure if their syntax is even slightly different from the version I happen to use. The more feedback I get from you guys, the more easily I can spot and fix these problems.

I'm hesitant to make any significant improvements to the current script at the moment, because I would really prefer to revamp it entirely to allow for PAL encoding and the other options that have been suggested (such as output size restriction, DVD authoring, and so on). This script started as a couple of commands for converting from PAL to NTSC. At the beginning, a reckless hack worked, but it's getting complicated and unwieldy (not least because I've been learning bash scripting as I go). I've considered making the script and GUI a single program in Python; it could be run as GUI, or from the command-line as always, but that would introduce a limitation for those who don't have (or don't want) Python installed. A compiled language like C/C++ would be a possibility, but I'd prefer to keep it entirely in a script or interpreted language for ease of modification. At any rate, it's not something I've had the time to devote to lately, so the current script structure will probably stick around for a bit, until I can dedicate some time to the preliminary engineering and design I probably should have done in the first place.

I don't know how easy it would be to restrict the size to CD or DVD-size. Thus far, I've been under the assumption that the script would only be used for single video files, and that there would be multiple videos on each disc, so any size limits would have to be dealt with manually. As far as I know, there is no reliable way to predict the output size until the video is encoded; restricting the bitrate limits the absolute maximum possible size, but in practice videos don't often use the max bitrate (except for VCD, where the bitrate is constant). Probably some kind of estimation algorithm would help; encode a few seconds of video and check the resulting size to get an idea of required space. I'll consider it for future releases, but it's probably a long way off, unless you or another emboldened developer would like to help implement it.

I appreciate your suggestions, and all the feedback everyone in this thread has given me! Your interest has provided good incentive for me to continue improving the script.

I see. Hrm, dunno if this will help, but i'll put it in anyways:
http://www.linuxquestions.org/questions/answers/262
I know that your script does audio and video separately too, so that above *might* be an option.

That's one option I didn't know about, but after investigating it, I'm afraid it's not a very good solution. It would split the file somewhat arbitrarily - you might end up with a movie that is split in mid-sentence - and the manual page for mplex says this option is not intended for splitting (S)VCDs into multiple discs, and will probably not even work for that purpose due to the split chunks lacking necessary parameters for (S)VCD playback.

Part of my eventual plan for authoring DVDs is to provide an easy way to locate and specify chapter breaks (I usually do it by watching the final video, skipping around to find good breakpoints, and noting chapter breaks in the dvdauthor XML specification - hardly an ideal solution), so perhaps that will lend viability to splitting in a reasonable spot. mpeg2enc (which does the video encoding) has the ability to insert sequence splits into an encoded video, which mplex can then use for the final result, so I will look into that.

Cool.

I also found these two tools:

http://mpgtx.sourceforge.net/ ( i think it only works for vcd's, well, actually it might work with svcd's too)

The other one is only gui, i think:

http://outflux.net/unix/software/GOPchop/