Talk:Nuvexport

From MythTV Official Wiki
Revision as of 08:19, 17 February 2008 by R5gordini (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/ffmpeg.pm.old   2007-07-07 19:26:52.000000000 +0200
+++ /usr/share/nuvexport/export/ffmpeg.pm       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');

Questions

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)