pyTivo Discussion Forum

[Iluvatar]

so here are the changes I have made to allow pyTivo to remux any video with incompatible audio into mp4 for streaming as long as it has a compatible h264 video stream. This should detect the incompatible audio and re-encode as necessary...ex: DTS, vorbis, etc... You may still run into the non-monotone timestamp error which will still cause a full transcode. FFmpeg 0.6.3 doesn't seem to have this issue but later and earlier revisions do.

Most of this code already existed in pyTivo but I wasn't sure how to create a diff so I'll just post the affected sections.

transcode.py - I have split the mp4_remuxable into separate audio video tests and edited mp4_remux function

[jcthorne]

Your additions seem to assume that any h264 video stream is playable by the tivo as is. This is not the case. The AVC profile must be 4.1 or less, for 1080 resolution, must be 4 ref frames or less. Also, for a series 3 unit, 720p video must be full frame, ie 1280x720.

Also, audio bitrate need not be limited to 448kbps any longer. 640 seems to work fine now on both TivoHD and Premiere.

Further, the resultant files that ffmpeg creates from this command line are not IMSA standard streamable and the tivo will not accept them as is. The MOV atom must be at the front of the file.

[Iluvatar]

I understand that Tivo's will not accept higher than 4.1 AVC profile however I have done no additional checks other than what wmcbrine has programmed pyTivo to check for. If the video passed before then it will pass now (whether TiVo accepts the file or not). I am aware of the 1:1 PAR issue with S3/HD units as I frequently run up against it but pyTivo never fixed this anyways (on pushes). All I have done is moved the audio checks into the remux function in order to prevent the entire file from being transcoded which is a waste of time. Most of what you see there is from wmcbrine. He programmed the original MP4 remux function...I just made it slightly more compatible....to fit my needs.

As to the mov atom, pyTivo already checks for this once it exits the remux function and calls qtfaststart.py if necessary. I have had zero issues (except the h264 level 5 video, but pyTivo doesnt check this anyways as ffmpeg does not return this info) with streaming MKV files with DTS or other audio. I have thrown at least 30 files at my premiere and they work perfectly.

As to the audio, I have hardcoded the ffmpeg command but only because I was lazy. I'm certain it can be changed to use the user defined ffmpeg overrides in the pytivo.conf. Feel free to change it to whatever you want. To be honest it works for me and I just assumed that since I am not a programmer these are probably just ugly hacks that wouldn't ever make it into wmcbrine's GIT unless somebody took it and brought it up to standards.

[wmcbrine]

[ercdvs]

I had not seen this mentioned, but does this feature respect the settings on a global or per tivo basis ?

ie will it always attempt a straight copy if I have a _tivo_ setting of audio_ch = 2 set?

Im getting mixed results during my tests. it seems no matter what my settings, pytivo will do the .pytivo-temp version, and if i kill ffmpeg, it will restart itself using my config settings while trying to stream directly.

basically i am finding that a copy takes just a few minutes, then transfers @ 20+ Mb/sec.. while my 'lower quality' transcode stream takes a lot longer, and seems to transfer @ 6 Mb/sec max (but strangely seems to give both -ac 2 AND -acodec copy:

/usr/local/bin/ffmpeg -i /home/master/video/TV/vidfile.mkv -vcodec mpeg2video -b 8388k -maxrate 30000k -bufsize 4096k -ab 448k -ar 48000 -ac 2 -acodec copy -copyts -threads 2 -f vob -

[Iluvatar]

[ercdvs]

I was killing ffmpeg because i was testing various options out, starting a pull, then killing it after i saw what it was sending. it was just curious to see a 'backup' transcode when the main process failed.

Yeah, 99% of the time sending the full file over in a different container is much better, even though with this particular tv HD video and 5.1 audio is wasted.

All my settings and test are still valid for transcoded streams though

[lucasnz]

I've tweaked wmcbrine's code to remux using some of the standard algorithms already in transcode.py. It will also transcode the audio track if required.

See the diff here;
http://repo.or.cz/w/pyTivo/wmcbrine/lucasnz.git/commitdiff/f65a7e7d81d51eaf456e0387e7d7279c77650213

[Iluvatar]

[wmcbrine]

Note that, by using select_audiocodec(), your patch will transcode otherwise-compatible AAC tracks.

[Iluvatar]

So far works great. DTS audio and >448k AC3 is transcoded.

I would guess though that you could remove the following code which seems redundant given the function:

[txporter]

[lucasnz]

[txporter]

Is there a way to not get that by flag or something? I run my pytivo instances off of a tonidoplug, and I don't think it is really up to transcoding video on the fly.

[lucasnz]