From MythTV Official Wiki
Revision as of 11:52, 27 May 2008 by Tlefevre (talk | contribs)

Jump to: navigation, search

Cleanup - page needs formatting properly (no idea if you can create seperate pages for stuff with a main page index or not) and just generally going over all my spelling mistakes and everywhere I used "encode" instead of "transcode" when I had no idea what either really meant... --Pepsi max2k 22:14, 9 October 2006 (UTC)

Needs clarification on what unit the video bitrate is in. I can't figure it out myself. In a 28 minute file... VBR, multipass 3000 for video bitrate => 91MB file 15000 video bitrate => 99 MB file I'm assuming the unit is just bits/sec, but if that is so, you really need to change the default from 960, because no one is going to encode video at 960 bits/sec and is misleading. --Aboutblank 22:21, 25 October 2006 (UTC)

Sorry about that - it should be all in Kbps. I skipped adding the Kbps part on occasions as nuvexport doesn't actually give you a choice, you literally just enter "960" so as far as the user interface goes, it doesn't actually matter what rate it is, just what the number is, and adding Kbps or bps could possibly give someone the idea that they had the choice, which they don't. But yeah, if you know what you're doing, could be confusing. It's gonna be hell to check/update it all though :oP --Pepsi max2k 09:45, 11 November 2006 (UTC) EDIT: Ok I added a bold red note near the top to say they're all in Kbps, as it seems kinda clear to me where I've talked about bitrates, usually i stick a kbps with at least one of the values and don't make any mention of using anything but with later ones. And when I say to enter "1000", I mean just that. If that's changed to say "enter 1000 Kbps" and people start entering the "Kbps" part, that could get em in to trouble. But feel free to change them all if you want. Have fun ;o) --Pepsi max2k 09:57, 11 November 2006 (UTC)

There seems to be an issue with the audio bitrate parameter with ffmpeg 20070329 on Debian. When invoking nuvexport-xvid (Release 0.4.0-0.20070630.svn) ffmpeg bails out with "Error while opening codec for output stream #0.1 - maybe incorrect parameters such as bit_rate, rate, width or height". Debugging revealed that the given audio bitrate (128) was passed as Kbps (-ab 131072) to ffmpeg. Unfortunately, this caused above error, because changing this to 128000 or 128k worked fine. --Jdelker 17:28, 7 July 2007 (UTC)

--- /usr/share/nuvexport/export/   2007-07-07 19:26:52.000000000 +0200
+++ /usr/share/nuvexport/export/       2007-07-07 19:04:42.000000000 +0200
@@ -138,7 +138,7 @@
         my $value = shift;
     # Which version?
         if ($self->{'ffmpeg_param_vers'} >= 2) {
-            return param_pair('ab',             $value * 1024) if ($param eq 'ab');
+            return param_pair('ab',             $value."k") if ($param eq 'ab');
         if ($self->{'ffmpeg_param_vers'} >= 1) {
             return param_pair('ac',             $value)        if ($param eq 'channels');


Er - question: Where would it be appropriate to give feedback/suggestions about the tool?

Thanks, R5gordini 16:57, 16 February 2008 (UTC)

Well - here goes - I'll put it here:

I find that encoding often fails with

"mythtranscode died early.Please use the --debug option to figure out what went wrong."

Now, this seems to happen right at the end of recordings (perhaps 5 secs before the end), and it nearly always happens...

Rather frustrating, since I don't care about the last 5 secs, and it causes multiple encodes to fail. When running debug I found that mythtranscode was segfaulting. Presumably this is because the transport stream was slightly damaged at the end of the recording.

So, in order to stop the script dying, I edited it and changed the relevant "die" to just a "print". This means that the error is printed but it doesn't halt processing. Processing will continue, and the only adverse effect is that you get lots of the messages...

Perhaps this could be implemented in the original source? Maybe some logic around dying - such that multiple encodes can continue if there's an error with just one encode? Or if mythtranscode dies just at the very end it's not reported as an error?

Thanks, R5gordini 08:19, 17 February 2008 (UTC)

More questions

Just noticed that ffmpeg no longer knows "aac", but instead offers "libfaac". I personally haxor'd my file, but the next time there's a nuvexport release, this should probably be fixed. Would anyone like some assistance in maintaining nuvexport? I don't know the first thing about submitting patches and whatnots, but I can always learn that. --DirkGecko 18:39, 5 March 2008 (UTC)


Should this page mention that it is not relevant for those using DVB-[st] inputs because those are stored in raw mpeg-ts?

Question from tlefevre, May 27, 2008

In France DVB TV is broadcast using 720x576, when 4:4 the pixel ratio is 1/1, when 16:9 the pixel ratio is 64/45 (most often). When using nuvexport to transcode the MythTV recordings into Xvid avi files, there are 2 kinds of problems. How to fix them in nuvexport?

1) nuvexport assumes that the pixel ratio is constant, but it is not: a recording may begin with ads in screen ratio=4:3 and the movie may be in 16:9, or a movie is cut by ads with another ratio. Nuvexport takes the ratio it finds at the beginning of the recording, regardless of the cutlist. A change provokes an abnormal end.

2) I did not find the notion of "pixel ratio" in nuvexport, as it seems to be forced to 1/1, the real size being deducted from the width and height only. But when you have a 720x576 and 16:9 recording and you tell nuvexport 1024x576, it generates an Xvid avi file readable with a computer but unreadable with a Divx/ DVD set (limited to 720). I had to manually cut and transcode the MythTV mpg files into Xvid avi files with avidemux, with some choice of parameters in order to keep a compatibility with the Divx/ DVD sets, and through choosing a pixel ratio = 64/45 (configure) and a width = 720 (filter).