pyTivo Discussion Forum

[mhurwood]

Hi all,

I've got young kids, and you can never have too much material on the TiVo ready to show to give yourself 20 minutes break. But in MPEG2 format, all these preserved kids shows start to take up quite a bit of space.

To save space on the drive (I don't have a setup where I can stream reliably) I've been copying the programs to my computer, trimming the beginning and end, adding some metadata, and then sending them back again. But this of course is still in MPEG2 format and quite large.

So to save even more space, I've been using FFMPEG to convert the files to MP4 format first, which (at high quality) halves the file size, before I send them back. pyTivo continually show log messages suggesting that it's going to have to do a transcode, but at the last minute, because I have an Australian Series 3 which can handle MP4 format files, the files transfer with no transcoding just fine.

But it is a bit tedious that I have to do a manual step of transcoding to MP4 format myself before doing the push, when it seems to me that basically it should be possible for pyTivo to construct a different command line which is passed to FFMPEG so that it happens automatically.

I guess a short description of what I'm after is an option to have pyTivo "prefer" sending in MPEG4 format rather than MPEG2. All the existing logic for frame rates and sizes, etc. should theoretically be able to remain the same.

I've tried picking through the code myself, but I'm no Python expert and very easily end up breaking things.

Can somebody with more knowledge either:

a) Tell me I'm wasting my time (with some supporting evidence),
b) Reasure me that I should keep plugging away at it,

or

c) Do it for me and produce a quick change list? (As I suspect that so long as I was not trying to make this an option, then there's probably only a dozen or so lines that will need changing.)

Cheers,


Michael

[wmcbrine]

No, it can't be done with quick changes. For one thing, to make a TiVo-compatible MP4 would require running qtfaststart on the encoded file. This means that it can't be done in a pipeline, the way it is for MPEG-2; and that means the whole thing would need to be restructured.

Rather than have pyTivo encode MP4s, I'm looking at doing transport streams with h.264, because I think they can be done in one pass. But even that is pretty hairy.

[mhurwood]

So its basically the "streaming" or "converting on the fly" bit that breaks my idea? Fair enough.

And theoretically it's the ffmpeg guys and gals that have to eventually solve this problem for us?

Otherwise, the only way around it is to redevelop the entire queuing system, so the files get converted to MP4 before the "push" is even sent to the mind server? I can see how that change is a bit bigger than I was hoping!

Cheers,


Michael

[wmcbrine]

[JonMikelV]

I realize this is going to sound very basic, but could python read the moov atom from the end of the video file and feed it out at the beginning when the fetch request comes in from the TiVo basically re-arranging the existing binary file on-the-fly?

[wmcbrine]

That's what it does now, yes. But that's with pre-existing MP4 files. What we're talking about in this thread in transcoding to MP4 on the fly, the way pyTivo currently transcodes to MPEG-2 PS. The catch there is that "existing file" part. It can't skip to the end of the file to find the moov atom when the "file" is being streamed from standard input.