# pyTivo FFMPEG bug?



## DiGNAN17 (Jan 17, 2002)

So I'm encountering the following bug, as stated in the pyTivo web configuration screen:


> A bug in ffmpeg will sometimes move the center audio channel to the left or right speaker. Setting this option to 2, on an as needed basis, or permanently, will correct this at the loss of 5.1 audio. But this should only be necessary on rare occasions where the source file is an mkv or xvid with ac3 5.1 audio bitrate above 448k.


"rare occasions"? I've hit this twice in the past week. I think if a file is using ac3 for 5.1 audio, it's very likely that it will result in a bitrate that size or greater. The file I'm dealing with at the moment is 1536Kbps, for example. Is there any solution out there yet? I have a pretty recent version of FFMPEG in the plugins folder. I'd really like to watch this movie with full surround...


----------



## DiGNAN17 (Jan 17, 2002)

My apologies for replying to my own post, but if anyone else uses pyTivo and runs into this problem, I've found the answer.

If you weren't aware, you can update FFMPEG in pyTivo. The default location of the files is "C:\Program Files\pyTivo\plugins\video", and all you need to do is to download the second archive in this thread, and unzip the contained files to that folder. If you don't want to worry about reconfiguring pyTivo, you can just delete the file "ffmpeg_mp2.exe" and rename the new file ("ffmpeg.exe") to match the deleted file. Then you're done!

I can't tell if there are any negative effects of this yet, but I tried transferring my problem file before and after replacing the files, and now it works perfectly.

ps- make sure you download the second archive in that thread. The first one fixes the problem when transcoding AC3 > AC3, but not DTS > AC3, which is what my particular file needed.


----------



## wmcbrine (Aug 2, 2003)

Your "in this thread" points to c:\Program&#37;20Files\pyTivo\plugins\video.


----------



## DiGNAN17 (Jan 17, 2002)

Oops! Sorry about that! It's fixed now...


----------



## TishTash (Jan 24, 2008)

DiGNAN17 said:


> If you weren't aware, you can update FFMPEG in pyTivo. The default location of the files is "C:\Program Files\pyTivo\plugins\video", and all you need to do is to download the second archive in this thread, and unzip the contained files to that folder. If you don't want to worry about reconfiguring pyTivo, you can just delete the file "ffmpeg_mp2.exe" and rename the new file ("ffmpeg.exe") to match the deleted file. Then you're done!


One thing: I'm queasy about this because the old file (to be replaced) is nearly twice the size of the new file. If the new one solves those sound issues, how is it half the size of the old file? (Or did someone rewrite it from scratch.) For the record, old file is about 7.6 gigs, the new one about 4.9 gigs. I'm afraid.


----------



## Rdian06 (Apr 12, 2008)

This thread is out of date. After my ffmpeg Windows build went through some testing, it was eventually incorporated into the pyTivo downloads. If you have a pyTivo fork version after 8/1/2008, you already have the fixed ffmpeg version.

However wgw posted lastnight about a new problem with the fixed ffmpeg that I need to track down. He's reverted the ffmpeg build in his fork back to the original with the broken 5.1 audio as of lastnight.

Seems the updated ffmpeg code is more strict about posting an error for files with strange timestamp orders. The older code seemed to just ignore them and continue.

My ffmpeg builds are now being housed in this thread:
http://pytivo.krkeegan.com/rdian06-s-ffmpeg-builds-t468.html

The version that was most recently included with pyTivo is 0.93.


----------



## TishTash (Jan 24, 2008)

(See below.)


----------



## TishTash (Jan 24, 2008)

Rdian06 said:


> This thread is out of date. After my ffmpeg Windows build went through some testing, it was eventually incorporated into the pyTivo downloads. If you have a pyTivo fork version after 8/1/2008, you already have the fixed ffmpeg version.


Thanks for the info. Since I have your attention, here's a quick question: I had a widescreen AVI file on my laptop that I downloaded via pyTiVo to my TiVo. The resultant file on the TiVo is squeezed into a 4:3 format; no biggie, since I can easily fix it by altering the "aspect" from "panel" to "full" via the TiVo remote.

HOWEVER, is there a way (perhaps through config) that the original widescreen ratio be preserved in the resultant TiVo, instead of vertically compressed (as above?) Also, an MKS file run through piTiVo to a TiVo lost a lot of resolution; would adding or editing parameters improve things? Thanks!


----------



## Rdian06 (Apr 12, 2008)

TishTash said:


> TishTash said:
> 
> 
> > Thanks for the info. Since I have your attention, here's a quick question: I had a widescreen AVI file on my laptop that I downloaded via pyTiVo to my TiVo. The resultant file on the TiVo is squeezed into a 4:3 format; no biggie, since I can easily fix it by altering the "aspect" from "panel" to "full" via the TiVo remote.
> ...


----------



## TishTash (Jan 24, 2008)

Rdian06 said:


> Do you have an S2 or a Tivo S3/HD? Assuming you have a widescreen TV, for the aspect ratio to work correctly, you have to tell the Tivo you have a widescreen through one of the settings menu options and then configure your resolution in your pyTivo.conf. I think there also is a toggle for 16:9 in the pyTivo.conf, but since I have S3's I believe they are defaulted to 16:9. pyTivo detects what model Tivo it's sending to and has different default settings per unit type. All of which can be overriden through the conf file.
> 
> If you mean sending an MKV, the Tivo S3/HD presets default to 1280x720. You can override to 1920x1080, but I'm not sure what happens if you try to send 1080p to the Tivo.
> 
> ...


I only have an HD (well, two HDs) hooked up to the pyTiVo. Does this automatically render everything 16x9 and 1280x720 in the transfer? If so, I wonder why the AVI file was "smushed" horizontally; do I need to specify parameters to "force" format the AVI?


----------



## TishTash (Jan 24, 2008)

Well, I figured this one out: If you want HD quality on a TiVo HD from an HD video file, you need to change the width and height parameters to 1280 and 720. I thought that since pyTiVo knows what type of TiVo it sends to, it would automatically send 1280x720 to an HD unit (as Rdian6 implied), but this is untrue: It defaults to 544x480. Setting things to the higher numbers does increase the encoding and transfer time, but results in a true HD TiVo file. (Tell me if I'm going over well-trod territory.)

That explains the fuzzy results of a default transfer, and how to correct it. The aspect ratio discrepency still baffles me: Do I need to set optres to true? PAR to 1.0? (It's not addressed in Rdian6's link.) I'll experiment and get back here.


----------



## Rdian06 (Apr 12, 2008)

Strange, I thought it was supposed to do the right thing for TivoHD units. I'll go stare at the code later to double check.


----------



## gonzotek (Sep 24, 2004)

TishTash said:


> Well, I figured this one out: If you want HD quality on a TiVo HD from an HD video file, you need to change the width and height parameters to 1280 and 720. I thought that since pyTiVo knows what type of TiVo it sends to, it would automatically send 1280x720 to an HD unit (as Rdian6 implied), but this is untrue: It defaults to 544x480. Setting things to the higher numbers does increase the encoding and transfer time, but results in a true HD TiVo file. (Tell me if I'm going over well-trod territory.)
> 
> That explains the fuzzy results of a default transfer, and how to correct it. The aspect ratio discrepency still baffles me: Do I need to set optres to true? PAR to 1.0? (It's not addressed in Rdian6's link.) I'll experiment and get back here.


What version of pyTiVo are you using (which fork and the approximate download date)? Also, can you please post your pytivo.conf?


----------



## TishTash (Jan 24, 2008)

gonzotek said:


> What version of pyTiVo are you using (which fork and the approximate download date)? Also, can you please post your pytivo.conf?


I'm using krkeegan's fork, around 052208. I was using the barebones config file, save the latest change to 1280/720 mentioned above.

BTW, when I use optres=true, I get the native resolution of the source file, which happens to be 720x480. However, when I force it to 1280x720, I get a _much_ better-looking mpeg2 at the cost of a _minor_ increase in file size (like 15%). Which makes no sense on two fronts: Why such a small increase in filesize despite a noticeable increase in quality, and why such a noticeable increase in quality from an mpeg at its native resolution (720x480) to essentially an upconverted version (1280x720) of the exact same file. (The only thing I can think of is that ffmeg's upconversion is very good at interpolating, and doesn't add many bytes in the process. 2g2bt [too good to be true.] :-D)

Here's another issue: I actually tried to delete the frame rate parameter (-r 29.97), but whenever I put the ffmpeg_pram line in pytivo.conf and attempt a transfer, the console spits out "unrecognized option '-maxrate,'" which makes no sense. (Even without the -r deletion, it still chokes on that 'maxrate' problem.) I even tried to edit the template, but that didn't affect the forced fps. Not a big deal -- the file's frame rate isn't retained; big deal -- but I'm wondering why the choking. (I tend to prescribe to the theory of "where there's smoke, there's fire.")


----------



## Rdian06 (Apr 12, 2008)

TishTash said:


> I'm using krkeegan's fork, around 052208. I was using the barebones config file, save the latest change to 1280/720 mentioned above.
> 
> BTW, when I use optres=true, I get the native resolution of the source file, which happens to be 720x480. However, when I force it to 1280x720, I get a _much_ better-looking mpeg2 at the cost of a _minor_ increase in file size (like 15%). Which makes no sense on two fronts: Why such a small increase in filesize despite a noticeable increase in quality, and why such a noticeable increase in quality from an mpeg at its native resolution (720x480) to essentially an upconverted version (1280x720) of the exact same file. (The only thing I can think of is that ffmeg's upconversion is very good at interpolating, and doesn't add many bytes in the process. 2g2bt [too good to be true.] :-D)


Now I'm confused. Do you consider the 720x480 file to be an HD source? Is that what you were feeding to pyTivo and wondering why it was using 544x480 as the output resolution?

As for the better quality, it just means that the software scaler inside ffmpeg is better than the scaler chip inside your TV.

As for the file size, MPEG2 and most of the other video codecs compress by looking at the difference between frames. Motion (i.e. changes between frames) are the major things that will contribute to large file sizes. So just upping the resolution doesn't necessarily mean the file will be much larger.



TishTash said:


> Here's another issue: I actually tried to delete the frame rate parameter (-r 29.97), but whenever I put the ffmpeg_pram line in pytivo.conf and attempt a transfer, the console spits out "unrecognized option '-maxrate,'" which makes no sense. (Even without the -r deletion, it still chokes on that 'maxrate' problem.) I even tried to edit the template, but that didn't affect the forced fps. Not a big deal -- the file's frame rate isn't retained; big deal -- but I'm wondering why the choking. (I tend to prescribe to the theory of "where there's smoke, there's fire.")


Strange, my HD transfers on to my S3 don't seem to be mucking with the framerate. I wonder if there is something wrong with krkeegan's old code that isn't recognizing your Tivo HD as a Tivo HD unit and applying the proper defaults. krkeegan's fork is way out of date because he hasn't been active lately. Try wgw or wmcbrine's forks.

The Configure wiki is wrong. "ffmpeg_pram" tacks extra options onto the END of the ffmpeg command line used by pyTivo, it doesn't replace the full command. To override the full command line, you have to properly craft an "ffmpeg_tmpl", which is quite difficult to do correctly.


----------



## TishTash (Jan 24, 2008)

Rdian06 said:


> Now I'm confused. Do you consider the 720x480 file to be an HD source? Is that what you were feeding to pyTivo and wondering why it was using 544x480 as the output resolution?


No. The 720x480 file is the anamorphic AVI file that I was trying to un-squish. The HD source is different (MKV) file at 1280x720 that was losing a lot of resolution after transfer. However, _both_ were being output as 544x480 unless I specified 1280 as the pixel width and 720 as the pixel height in the pyTiVo.conf file, so for some reason, my fork defaults to 544x480 despite transferring to an HD unit.



Rdian06 said:


> As for the better quality, it just means that the software scaler inside ffmpeg is better than the scaler chip inside your TV.
> 
> As for the file size, MPEG2 and most of the other video codecs compress by looking at the difference between frames. Motion (i.e. changes between frames) are the major things that will contribute to large file sizes. So just upping the resolution doesn't necessarily mean the file will be much larger.


Thanks for the great answers. I would just add that this is not consistent across-the-board: When I choose Native pass-through on the TiVo, the picture is consistently better than if I choose Fixed 1080i or 720p (in effect using the TiVo rescaler), which implies that the TV scaler is superior. (The inexorable wait for my TV to switch resolutions forces me to use Fixed, unfortunately.) However, you appear correct in stating the ffmeg upconverter may be even superior.



Rdian06 said:


> Strange, my HD transfers on to my S3 don't seem to be mucking with the framerate. I wonder if there is something wrong with krkeegan's old code that isn't recognizing your Tivo HD as a Tivo HD unit and applying the proper defaults. krkeegan's fork is way out of date because he hasn't been active lately. Try wgw or wmcbrine's forks.


Well, to clarify, the HD transfers stay at 29.97 fps, as (I suppose?) they should. The fps I wanted to remain untouched was the non-HD 720x480 file, but no matter what I did, my pyTiVo kept converting it to 29.97 (despite protestations in the console about how the framerates differed).



Rdian06 said:


> The Configure wiki is wrong. "ffmpeg_pram" tacks extra options onto the END of the ffmpeg command line used by pyTivo, it doesn't replace the full command. To override the full command line, you have to properly craft an "ffmpeg_tmpl," which is quite difficult to do correctly.


I figured. Nothing's easy. Like I said: The native frame rate isn't maintained; no great loss.

Once again, thanks for your considered and considerable answers and patience.


----------

