Thanks for this app! I'm following these (first tivostream now this) closely as they are very interesting, albeit very "techie" still. I can handle the techie, though I'd rather not as I'm a lazy user... in fact, I have a couple of usability requests (I'm a designer-type, albeit for mobile software)

* Preview pics location and size - I like the size, but I'd trade off some of the size (a bit smaller of a window, esp. since this'd also increase the effectiveness of a small/middle preview quality setting) for better placement. In other words, there's a reason Netflix preview images are next to the timeline and are small - so you don't have to look in 2 places at once

* Would be great if, while a movie was playing, the last thumbnail preview image was displayed instead of the Please Wait image over the top of the video when play is resumed. I could see how this adds complexity, but it also helps increase the comfort-level of users because they can see approx where they're going to land... perhaps even the selected frame could be rendered for where the user was in the timeline even if it wasn't auto-generated, specifically to show where the user will land in the video

* [Future] Compatibility. As a "late-comer" (albeit a rising start for sure), this app, after stability is at a place you are comfortable with, ought to focus on compatibility with the old-school apps, namely: Tivo Desktop (work alongside, if not already... I can't test), Galleon (should be an app in best case scenario), and pyTivo.

* [Future] Front-end GUI - while the .ini commands are well-documented and well-suited to the tech-heavy crowd typically frequenting these forums, it's clearly not the most usable solution vs. even a simple j2me UI, nor does it encourage broader adoption

* [Future] Windows installer, Mac installer - again, me = lazy user and I'd rather double-click and go read a blog than extract files, customize an .ini file and double-click on a .bat (unless I want to run as a service, then I have to click on folders first) ;-)

Again, thanks for the hard work. Once someone can provide instructions on how to use this alongside/inside Galleon in Windows I plan to use it regularly, probably instead of pyTivo.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

1) I believe it only has one audio stream (sorry, I just tracked down an mp4 to view, my rips are generally mkv's).
2) I have never tried tivostream, so don't know. What I can say for sure is that I can get 6 channel audio from transcoded streams in streambaby.

I truncated the file to 40M and uploaded it here:http://yoav.org/files/test.mp4
It's definitely a 5.1 channel ac-3 audio stream in the source, and yet
when I stream to the tivo, I end up with a 2-channel stream (according to
the amplifier). Other streams that are sent (mkv files that are converted
by streambaby) work as 5.1 fine.

note: can you tell me once you've downloaded the file so I can delete it? Thanks...

NOTE: What you have in your mp4 file is 6 channel aac audio (Apple Audio) which is not ac3 (Dolby). I don't have surround sound system enabled myself so I don't know if Tivo can even pass through 6 channel aac audio. If it does, your receiver also would have to know how to deal with it.

The transcoded streams obviously are set to transcode to ac3 audio, hence the difference.

Thanks for input Vito, I'll take a look at your suggestions (and probably implement some of them, though I'm not sure it will be the next release. I will probably make the default preview quality higher in the release)

There have been a bunch of other suggestions/issues in the last couple of days that I didn't bring up specifically, but in the next few days I'll go through this thread again and try to prioritize them.

But I did want to talk about a couple of the things vito mentioned:

Quote:

Originally Posted by vitocorleone

* [Future] Compatibility. As a "late-comer" (albeit a rising start for sure), this app, after stability is at a place you are comfortable with, ought to focus on compatibility with the old-school apps, namely: Tivo Desktop (work alongside, if not already... I can't test), Galleon (should be an app in best case scenario), and pyTivo.

I'll have to look at Galleon more closely at some point and try to make it easier to integrate. I had problems in the past getting 3rd party apps (I think I tried tivostream) running in Galleon, but I'm pretty sure I was just not doing it right, and now that there have been some easy instructions posted in this thread I'll try again at some point.

But as far as coexisting, I have been thinking about changing the default HME port from 7288 to 7290 so it doesn't conflict as much. Does anyone think changing it from 7288 to 7290 will cause problems for anyone?

Quote:

* [Future] Front-end GUI - while the .ini commands are well-documented and well-suited to the tech-heavy crowd typically frequenting these forums, it's clearly not the most usable solution vs. even a simple j2me UI, nor does it encourage broader adoption
* [Future] Windows installer, Mac installer - again, me = lazy user and I'd rather double-click and go read a blog than extract files, customize an .ini file and double-click on a .bat (unless I want to run as a service, then I have to click on folders first) ;-)

I definitely see your point, but I think I will leave these things up to other people, who may want to repackage streambaby. Not trying to bag-out (well, maybe I am ;-) but I'm mostly a backend guy, and creating user interfaces is not "my thing". I've never written a Swing app, and for that matter haven't really had to deal with a GUI since I was working with Windows 3.1

Yoav for instance integrated streambaby into his pyTivo mac distribution, pyTivoX which (I believe, since I am not able to try it) has a full install program, allows people to add/remove directories to the ini, all from a nice GUI.

As for clicking on multiple folders to install as a service, that I may make easier at some point. I actually wanted to make it a little difficult to start with, as if it is installed as a service it is much harder to figure out what's going on if it won't start/has problems/etc. I was also afraid people would start "clicking like crazy" on the install/remove service bat files, and I'm pretty sure that if you install and then remove, you can't reinstall without a system reboot.

NOTE: What you have in your mp4 file is 6 channel aac audio (Apple Audio) which is not ac3 (Dolby). I don't have surround sound system enabled myself so I don't know if Tivo can even pass through 6 channel aac audio. If it does, your receiver also would have to know how to deal with it.

The transcoded streams obviously are set to transcode to ac3 audio, hence the difference.

Woops, my bad. I mentioned in a previous post that it was AAC and not AC-3, and then completely forgot about it.

The point remains though. When I stream this mp4, I get 2-channel audio instead of 6-channel. The fix might be to have streambaby check that the audio in an mp4 file is ac-3 to stream as-is, otherwise it should transcode?

good news: I took that file, and used ffmpeg to convert it to ac-3 (using copy for the video). ffmpeg now reports:

And it streams the mp4 as-is, and it shows up as 6 channel (ok, not perfect, it looks as though center channel got mapped to the left speaker.. but that I'm happy to worry about later).

So it definitely sounds like there's gonna be some more parsing required before streaming an mp4 to ensure that it is valid (so aac is not valid, ac-3 -- even though the mp4 spec requires aac support, and not AC-3.. go figure .

__________________
Don't pay for Tivo Desktop / Roxio on the mac: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts..

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

So it definitely sounds like there's gonna be some more parsing required before streaming an mp4 to ensure that it is valid (so aac is not valid, ac-3 -- even though the mp4 spec requires aac support, and not AC-3.. go figure .

I have to disagree. AAC certainly is valid as the Tivo will accept it natively. Transcoding is always good to avoid if not necessary. I think the mp4 spec just recently was amended to allow AC3 and you will see more encoders adding AC3 support in mp4 container as a result and it's nice that Tivo supports it.
It would still be good to understand exactly what Tivo does with 6 channel AAC - is it passing it through or is it converting to PCM?
Perhaps best compromise is to have a setting that defines what to do in case of > 2 channel AAC - leave it alone (default) or transcode to AC3 (config option).

The point remains though. When I stream this mp4, I get 2-channel audio instead of 6-channel. The fix might be to have streambaby check that the audio in an mp4 file is ac-3 to stream as-is, otherwise it should transcode?

And sorry to be obsessive, but you're positive its not playing in 6 channel? It may not be enough to see what the audio system is displaying (again, I know very little about these things), as it may only be able to detect what the format is for AC3 pass-through (and thus display it), but not display it for AAC. (but play it correctly).

I'd try to test this myself, but I'm really not sure how to go about doing it.

As far as transcoding, I'd be very hesitant to make this the default option, but I guess I could try to make this some kind of option. (But it may be a rev or 2 before I get to it). Transcoding for a lot of people is resource intensive, and things that would stream well without transcoding would not stream well with on-the-fly-transcoding. (Both because of CPU intensive operations and also because MP4 files usually take up less bandwidth for the same quality as MPEG2, which is what it would transcode to)

And sorry to be obsessive, but you're positive its not playing in 6 channel? It may not be enough to see what the audio system is displaying (again, I know very little about these things), as it may only be able to detect what the format is for AC3 pass-through (and thus display it), but not display it for AAC. (but play it correctly).

I can't be 100% positive, since my audio system tries to map any input to 9 speakers, so I hear something out of all of them, but it definitely sounds 'flatter' than it sounds when it's transcoded to 5.1 and played as such.

The receiver is telling me that it is getting input. The input is not DD or DTS (specific lights are not on). It believes it is getting a 2-channel PCM digital stream. It is mapping to all-stereo. If there's a way I can get you more accurate info from the tivo I'd be glad to check.

Would the tivo be able to map the 6-channel aac to a 2-channel stereo? Otherwise, it *is* certainly possible that the tivo is just passing the audio through and the amp (which can play aac music files) is doing some sort of conversion. I really don't know, but if anyone else wants to try.. I've left the test file up (so people can mention if they hear nothing, hear something in stereo, or hear 6-channel).

__________________
Don't pay for Tivo Desktop / Roxio on the mac: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts..

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I have to disagree. AAC certainly is valid as the Tivo will accept it natively. Transcoding is always good to avoid if not necessary.

I'm not going to pretend I know what should be done here.

I definitely have a clear symptom: a 6-channel mp4 encoded with AAC audio is being streamed as-is by streambaby. when the Tivo S3 plays it through my amp, I'm only getting 2-channel audio. When a similar mp4 but with ac-3 audio is sent, it plays it back in 6 channels.

I could be my amp downgrading it. It could be the tivo downgrading it. Or it could well be something else . I would like to know what others are seeing...

__________________
Don't pay for Tivo Desktop / Roxio on the mac: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts..

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I was thinking about adding a new feature to streambaby (because I ran into the need for it earlier today...) so that users could select a "quality" on the play screen. So if they select "default" everything gets passed through as normal and I use the sameq option for transcoding. If they select something other than default (high/low/medium/etc) it would force transcoding, and I would tell ffmpeg what quality to generate it.

Now because I'd also like to (at some later date more than likely) be able to "test" the bandwidth and set the quality based on how much bandwidth is available, I'd like to tell ffmpeg to base it's quality on a "target" bit rate (preferably VBR).

My question is what are the correct params to pass ffmpeg to do something like this. I really haven't done too much of this in the past, I usually just use the -qscale parameter. My problem is not that I can't find documentation with google, more that I find way too much ;-)

I'll have to look at Galleon more closely at some point and try to make it easier to integrate. I had problems in the past getting 3rd party apps (I think I tried tivostream) running in Galleon, but I'm pretty sure I was just not doing it right, and now that there have been some easy instructions posted in this thread I'll try again at some point.

Hmm ... that might be a fun little project, writing a little GUI app that plugs into Galleon and takes care of the .ini file settings and steps I've documented and such.

I am by no means a good java programmer, but I've tinkered with Galleon's front-end in the past (changes to the Weather app) so I might be able to pull something like that off.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

keary - I have used FFMPEG for years and to be honest, it still gives me lots of grief. It's nothing short of voodoo and magic to make it work right. It requires immense amounts of babysitting and knowledge. All this is fine and dandy for us geeky types (although I personally have a love/hate relationship with FFMPEG), it will never fly with your avg user. I'm not saying to scrap the FFMPEG aspect of your project, but considering the last 6 pages of the forum all concerned issues with FFMPEG, I am wondering if maybe you should re-evaluate its importance in your project. I think its great to have that transcoding ability, but I personally would get frustrated with the whole deal if I had to put up with ffmpeg issues every time I went to play something. Why exactly does transcoding play such an important part in streambaby? tivostream either played the video or not - it was the KISS (keep it simple...) at work. You went into using tivostream KNOWING you might have to do some transcoding on the side beforehand. Thats fine - the enduser transcodes using whatever means they want.

Maybe at the very least and to cause yourself the least amount of tech support (read ffmpeg support), you should make the ffmpeg transcoding turning OFF by default.

Oh yeah - and the other thing about ffmpeg - it comes in so many varieties in the wild it seems it would be hard to build your project to match. For example - on the Ubuntu machine I am running streambaby on, I have a VERY custom built FFMPEG that I am NOT ABOUT TO MESS WITH. Took me forever to get it built tp do the things I want it to do and if it came down to a battle between streambaby and my custombuilt ffmpeg... I can guarnatee my ffmpeg would stay. Heck it even makes me nervous THINKING about futzing with that ffmpeg on that machine.

Maybe at the very least and to cause yourself the least amount of tech support (read ffmpeg support), you should make the ffmpeg transcoding turning OFF by default.

The biggest issue is that I need ffmpeg to generate the thumbnails for the "outside of buffer" preview. I'm not sure what other people think of the preview mode, but for me it's the "sexy" part of streambaby (and it's why I started the project in the first place)

I actually think that for 90% of the people there won't be too many ffmpeg problems, as on Windows I control which version of ffmpeg ships/installs with streambaby, and I believe the Yoav's Mac distribution pyTivoX does the same. (Although Yoav's ffmpeg is probably updated more frequently than I plan on updating the windows version).

I also tried to "ship" the first testing versions of streambaby with transcode turned off, and it didn't really go over well. It's the feature a lot of people wanted.

(Replying to bluehz):
Even if you get totally frustrated with ffmpeg, please don't drop the transcoding. Given the option of telling users "only the following very specific files are supported" or transcoding everything, I would choose to transcode everything. Feel free to stop worrying about the previous stuff if it is too much work (I thought the code already detected all these things, so I was simply trying to help build a list of 'what actually can be streamed as-is').

That said, the idea of modifying the bitrate of the video stream to respond to network quality seems like a really cool idea if it could be made to work. Unfortunately I too am not so helpful on the ffmpeg front... I'm learning about it as I try to do things....

On a more personal note. Thank you for your patience. Having had to personally respond to a lot of "iTiVo isn't encoding the file the way I want it to", I know how frustrating it can be to try and help when the problem rests with an encoder that is entirely black magic to make work (I use mencoder there.. but same sort of issues arise).

__________________
Don't pay for Tivo Desktop / Roxio on the mac: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. and To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts..

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

I was thinking about adding a new feature to streambaby (because I ran into the need for it earlier today...) so that users could select a "quality" on the play screen. So if they select "default" everything gets passed through as normal and I use the sameq option for transcoding. If they select something other than default (high/low/medium/etc) it would force transcoding, and I would tell ffmpeg what quality to generate it.

Now because I'd also like to (at some later date more than likely) be able to "test" the bandwidth and set the quality based on how much bandwidth is available, I'd like to tell ffmpeg to base it's quality on a "target" bit rate (preferably VBR).

My question is what are the correct params to pass ffmpeg to do something like this. I really haven't done too much of this in the past, I usually just use the -qscale parameter. My problem is not that I can't find documentation with google, more that I find way too much ;-)

You should definitely try to sync up with WGW, one of the main pyTivo developers. He's done a LOT of work in this area. It'd be a shame for you to waste time going over things that have already been sorted out already. Possibly also Rdian06, who's also done quite a bit of work on pyTivo, perhaps with more of a focus on specific ffmpeg issues/builds.

Granted, the HMO downloading and HME streaming implementations and gotchas may vary, but there's bound to be much similarities between the two functions.

That said, I've just installed StreamBaby today and found it extremely useful. Nice work. I've since uninstalled HME-VLC and tivostream. pyTivo and StreamBaby should be all that I need going forward.

Hmm.. *IF* you're ok with trying out beta-level software, go to the pytivox download page at http://code.google.com/p/pytivox/downloads/list and download the latest beta (1.1b2). This has the 0.17 streambaby in there, and you can choose to use pytivo, streambaby, or both. Keep in mind you can only stream to a tivo 3 / HD.

Tell me if things seem broken (I'll try and figure out if it's a bug in pytivox or streambaby, and if so, forward it up the chain).

I've got it up and running with 1.1b5. It works great. Only one little glitch and I don't know where the fault lies...It seems that if I am trying to stream an HD file that I'd downloaded from the Tivo, that streambaby can't keep up. It's not the desktop. I'm using a 2.66 GHz Quad Core Mac Pro. It's loafing with the CPU. But I see the outbound network speed around 8 to 10 Mb/sec while for an HD MPEG-2 stream it should be somewhere around 16 Mb/sec. So I'm not sure what's causing the slowdown here...

My question is what are the correct params to pass ffmpeg to do something like this. I really haven't done too much of this in the past, I usually just use the -qscale parameter. My problem is not that I can't find documentation with google, more that I find way too much ;-)

A couple of key arguments related to bitrate control are "-b #" and "-maxrate #". For example:
-b 2000k -maxrate 3000k means to ffmpeg to try and maintain an average bitrate around 2000 kbps and at most 3000 kbps. Problem is as you try and limit bitrate you will find that at times ffmpeg will complain that maxrate is not large enough, so usually one ends up having to bump up maxrate a lot more.
(You may also have to use -bufsize argument along with the 2 given above for it to work properly).

As stated above, ffmpeg is somewhat voodoo magic at times to get working right and personally I try and avoid transcoding whenever possible. If something must be re-encoded then I will spend the time to do it manually, not in real time, since doing a good job usually involves 2-pass encoding. Then again if it's something where quality doesn't matter much then on the fly transcoding is fine.

I've got it up and running with 1.1b5. It works great. Only one little glitch and I don't know where the fault lies...It seems that if I am trying to stream an HD file that I'd downloaded from the Tivo, that streambaby can't keep up. It's not the desktop. I'm using a 2.66 GHz Quad Core Mac Pro. It's loafing with the CPU. But I see the outbound network speed around 8 to 10 Mb/sec while for an HD MPEG-2 stream it should be somewhere around 16 Mb/sec. So I'm not sure what's causing the slowdown here...

Anyone got any ideas or is HD streaming not really working yet?

That's a Tivo limitation. Streaming mpeg2 video is limited to the same kind of speeds you can get out of Tivo To Go - not very fast. You are lucky if you can maintain 13 Mbps under normal circumstances, and that's with the original S3. THD units are a little slower than that. If you tune your Tivo to channels you don't receive you can help speed things up a little but it will struggle to keep up with high quality HD mpeg2 streams no matter what you do.

NOTE: mpeg4 H.264 streams faster than mpeg2 to Tivos, so for high quality HD streaming mpeg4 is actually a better option. Problem is of course a lot of HD content you may want to stream back to your Tivos originated from Tivos so of course will be in mpeg2 format.

EDIT: Just tried a couple of mpeg2 & mpeg4 streams to get some rough average bit rate numbers to report here:
I get about 20 Mbps streaming H.264 to Tivo compared to about 12-13 Mbps streaming mpeg2.
(This is with my S3 under normal conditions tuned to HD channels on both tuners).

That's a Tivo limitation. Streaming video is limited to the same kind of speeds you can get out of Tivo To Go - not very fast. You are lucky if you can maintain 13 Mbps under normal circumstances, and that's with the original S3. THD units are a little slower than that. If you tune your Tivo to channels you don't receive you can help speed things up a little but it will struggle to keep up with high quality HD mpeg2 streams no matter what you do.

NOTE: mpeg4 H.264 streams much faster than mpeg2 to Tivos, so for high quality HD streaming mpeg4 is actually a better option. Problem is of course a lot of HD content you may want to stream back to your Tivos originated from Tivos so of course will be in mpeg2 format.

Ah, thank you. I had been playing around earlier today with streaming back .tivo files, and noticed that streaming couldn't keep up. After I saw the other post about HD streams, I was just looking in my code to see if maybe I was creating a bottle neck somewhere.

That's a Tivo limitation. Streaming mpeg2 video is limited to the same kind of speeds you can get out of Tivo To Go - not very fast. You are lucky if you can maintain 13 Mbps under normal circumstances, and that's with the original S3. THD units are a little slower than that.

Thanks. That's rather annoying. Why put a 100 Mb/sec LAN connection on a device and not use it. Perhaps its to keep the device stable as too much LAN traffic could maybe cause the box to crash. Still, you'd think they could do better with that.

So it looks like there's not a really good way to transfer HD Tivo files back to the box. I've got to wait either way. Bummer.

Any way to set up streambaby to force a transcode from MPEG2 to H.264?

It's interesting how H.264 will work. Yeah, it will stream fine as the codec is much more efficient at compressing the stream. But then it requires a lot more horsepower at the receiving end to decompress the stream. So if the Tivo can handle that fine, why don't they just let it stream at a faster bit rate to begin with.

Hey one other comment on Streambaby. I've got a bunch of DVD rips that I'd like to play. Streambaby will see and play the .vob files fine, but it won't recognize the DVD folder as an entire DVD. And it also will not recognize .iso files.

It's interesting how H.264 will work. Yeah, it will stream fine as the codec is much more efficient at compressing the stream. But then it requires a lot more horsepower at the receiving end to decompress the stream. So if the Tivo can handle that fine, why don't they just let it stream at a faster bit rate to begin with.

There are two different systems at work here -- the remuxing or demuxing of MPEG-2, from program stream to transport stream or elementary streams, which is (apparently) done in software; and the decoding of the video, which is done in hardware. The TiVo doesn't have much horsepower for things it has to do in software.

The faster streaming of h.264 is a fascinating result. I always thought those podcasts seemed to come in blazingly fast, but I didn't make the connection. It suggests that the h.264 streams are indeed being pumped to the decoder without having to be demuxed or remuxed, unlike the MPEG-2 streams.

It makes me wonder all the more if there's really no way to get an MPEG-2 transport stream directly to the TiVo. There ought to be.

It also suggests a reason why h.264 is not yet (as far as we can tell) allowed for TTCB transfers.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

It makes me wonder all the more if there's really no way to get an MPEG-2 transport stream directly to the TiVo. There ought to be.

It also suggests a reason why h.264 is not yet (as far as we can tell) allowed for TTCB transfers.

There should be a way, after all that is how MRV is said to work.

I also think there is a legacy issue. TTG and TTCB were designed to apply and remove DRM, something that most streams don't have. The streams rely on the stream not being saved rather than having a DRM wrapper in many cases. (Netflix being the obvious DRM encased stream exception) TiVo would need to re-engineer the TTG and TTCB code to skip past the DRM steps for mp4 content and simply may not have gotten around to doing that yet.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Encoding to a decent quality H.264 on the fly in real time is not possible for most computers with non dedicated hardware for the task, so I don't think this is a viable option.

The other issue is that currently to stream MP4 to the tivo, the full index (moov atom) needs to be sent to the TiVo as part of the MP4 file, which is not available until the entire video has been transcoded.

One thing I have been wanting to play with, but can't seem to find the correct tools to test it, is to see if the TiVo supports h264/ac3 inside of a MPEG-PS stream. If it did, then it would be at least possible to transcode to h264(mp4) and stream to the TiVo. (My guess is that this wouldnt help with the bandwidth issues, as it would probably make h264 slow down like the current mpeg streams, but since you can get better quality at lower bit rates with h264, it may help somewhat)

Does anyone know of any tools to create a mpeg-ps with h264/ac3? (From what I've read I think it should be possible).