pyTivo Discussion Forum

wmcbrine · Joined: 04 Jan 2008 Posts: 2008 Location: Maryland

For files with MP4-compatible video and audio, but the wrong container type -- like your typical Matroska (MKV) file, as well as AVCHD, and perhaps others -- I've added a quick-and-dirty remux before push, instead of having to reencode these to MPEG-2. It works, but it's a bit rough -- you'll see a long delay on the web interface before you get the "Queued for Transfer" page, for instance, because the remuxing is done before the request is submitted to the mind server. Files that can't be remuxed, for whatever reason (as determined by a non-zero return code from ffmpeg) will be reencoded to MPEG-2 on the fly as usual instead.

Since streamable MP4s can't be built in one pass, temporary files are written to the location of the original, but with the added extension ".pyTivo-temp". These are then processed by qtfaststart* during the transfer, and removed at the end. Transfers using this system may not be resumable, and if the same file is pushed to more than one TiVo at a time, only the first will get the remuxed version.

I've only tested this with a small set of files. My first was the first episode of Pioneer One, which worked fine. But the second episode failed with the infamous "non-monotone timestamp" error. That will probably come up a lot.

* Incidentally, I updated qtfaststart the other day based on a new upstream version, and so far it seems to work much better than before. Some things that were garbled by the old version now come out perfect.

rdian06 · Joined: 12 Apr 2008 Posts: 1420

Sounds very cool.

jcthorne · Joined: 30 Jan 2008 Posts: 243 Location: Houston, TX

Really cool. Glad to see you adding features etc to pytivo again. Will give it a try.

raghu1111 · Joined: 28 May 2009 Posts: 46

very nice update. pulled the changes. will report if there are any issues.

Do you think using a pipe rather than ".pyTivo-temp" might work? qtfaststart seeks around the file, that could be the problem. One of the debug messages in qtfaststart says "directly streamable..." if ffmpeg output is streamable, then pipe would work.

raghu1111 · Joined: 28 May 2009 Posts: 46

rdian06 · Joined: 12 Apr 2008 Posts: 1420

Transport streams (TS) are a container format just like MP4 and VOB. US Tivos can handle h264 in MP4 containers and MPEG2 in VOB and TS. US digital broadcasts are sent as MPEG2 in TS and the Tivo pretty much captures them as is.

New Zealand/Australia Tivos support h264 in TS because some of their broadcasts use that format.

wmcbrine suspects that the US Tivos either already support h264 in TS containers and we just haven't discovered the right command to trigger the transfer OR that some future software update will incorporate some of the New Zealand/Australia code and allow it. The Tivo software from down under has higher version number than the US Tivos, but much of the system is the same.

Iluvatar · Joined: 29 Feb 2008 Posts: 335

Would it also be possible to re-encode the audio stream if necessary to be compatible? I would think should add minimal overhead to the remux process on most systems and can be integrated into a single ffmpeg command. If we are going to start working with MKV files then it needs to be taken into account that many files wont be compatible based on the audio stream alone due to >448kbps AC3 or other codec.

wmcbrine · Joined: 04 Jan 2008 Posts: 2008 Location: Maryland

Are there actually files with an audio stream that's too high a bitrate, but a video stream that's OK? BTW, the Premiere can apparently handle full Blu-Ray rate audio, so that's something to tweak in the future.

Meanwhile, I just added a bit that says files with a ".mov" extension are using an incompatible container, which allows them to be remuxed to MP4 and pushed (if h264 video/AAC or AC3 audio). Previously these would be pushed as-is and fail. I was hesitant to do this, since for the most part the extension is ignored in pyTivo, as it's more reliable to check the file itself. But I couldn't see a better way.

Iluvatar · Joined: 29 Feb 2008 Posts: 335

raghu1111 · Joined: 28 May 2009 Posts: 46

Iluvatar · Joined: 29 Feb 2008 Posts: 335

--Edit: Never mind I reinstalled latest version again and its gone. I may have been one revision off, although I could have swore I just got the latest. Oh well.

-------

I am receiving an error on 'vCodec' that I believe is related to this new code.

Happens on push only. Pull works fine. FFmpeg lists the video codec as

wmcbrine · Joined: 04 Jan 2008 Posts: 2008 Location: Maryland

Surely that's not the whole log? The actual error doesn't appear.

Iluvatar · Joined: 29 Feb 2008 Posts: 335

wmcbrine · Joined: 04 Jan 2008 Posts: 2008 Location: Maryland

Well, thanks, but it's not useful... like I say, the actual error doesn't appear. It should be at the end of the traceback.

Iluvatar · Joined: 29 Feb 2008 Posts: 335

I have worked a bit on this and finally managed to get pyTivo to transcode the audio if it does not meet codec requirements while copying the video codec. It's not as fast as a straight codec copy but still 5 times faster than transcoding the entire file unnecessarily. So this means all compatible h264 video regardless of audio codec (as long as ffmpeg recognizes it) is compatible now and can still be streamed.

60% of my content was DTS audio but contained compatible video, unfortunately it was being kicked out into the normal transcode function slowing everything down.

It's probably not up to wmcbrine's standards (i'm not a programmer and it took forever to figure out what was going on) but I will post the changes for others once I test it a bit more.