Chris Petersen wrote:
nuvexport gets the output of transcode, parses it, reformats, and prints it on the screen. It appears if the framerate gets over 20 FPS then nuvexport can not process every status line guickly. The stdout buffer fills thus stopping transcode until it empties. Reading the transcode man page I came across the --print_status option in transcode. I modified the transcode.pm file in nuvexport to add a --print_status 4 option in the transcode command line. This tells transcode to only print a status line for every 4 frames processed. This fixed the problem and increased the rate back to a peak of around 50 FPS when using nuvexport!


I've added "--print_status 16" to the transcode options -- even 4 frames is probably overkill.

I suppose that will work as well. I wanted a value that would update a couple of times per second in case it slows down.


And am open to suggestions about how to do something similar with ffmpeg (nuvexport will soon be using ffmpeg for just about everything, since transcode doesn't seem to work with a bunch of mpeg type files), or even just speed up the buffering in nuvexport. In my tests with the mp3 encoder, my settings were pulling 80-100fps, which I figured would be fast enough; apparently it doesn't carry over to the other encoder types.

I also noticed nuvexport will still use the -Z option when the output resolution matches the input resolution. Transcode will still do zoom when the -Z option is specified with no change in resolution thus slowing down the frame rate for nothing.


Yeah. I apparently gave too much credit to transcode. You don't happen to have a patch for this, do you?

Unfortunely I am not a perl programmer so no patches. I have figured out enough to comment sections out or add strings. I am a C++
programmer that develops in Windows. In exchange I get money to buy computer parts and build Linux computers.


Since my computer has a HT cpu I uncommented the option to specify the number of CPUs in the transcode.pm file and gained about 1 FPS. I noticed the first parameter for this option defaults to 10 but the code in transcode.pm set it to 100. I used 10 and even tried 20 with no change of framerate so I left it at 10. I assume 100 would be overkill and may even slow it down like the comment indicated.


Interesting. On my dual athlon, I found the exact opposite -- about 1.5-3 fps slower (nuvexport has multi-cpu detection included, but deactivated). Since transcode encodes both audio and video in separate threads, the kernel sends those to separate CPU's (which is what HT works as in this case). Creating another encoding thread just causes them all to fight for resources on the lesser-used cpu.

Wouldn't be hard to add a commandline option to optionally enable this (since it would definitely help for something like a dual-xeon box)

Sounds like a difference between Athlon and Pentium that either the operating system or transcode does not take in account.

Several months ago I got a Philips DVP-642. I want to convert my
saved programs to a mpeg4 format that is playable on the Philips.
I figured out settings that gave good quality on the computer but
so far anything I try using xvid is not playable on the Philips.
It seems other people have this problem as well. I burned a movie trailer from the divx site and it played okay.


Most of the How-to information about xvid seems geared to windows users. I recently discovered the xvid4conf program for linux. I am getting stuff together slowly and may even write it down to help others. There are several pieces that need to be setup for it to work.

NUVExport is a very useful program. My main usage is when I archive shows I use it to get show information so I know what files to move. I want to use it for converting files to MPEG4 format.

73 Eric

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Reply via email to