Troubleshooting streaming pauses

[David Badia]

Just bought the ipad app and am troubleshooting an issue where recorded tv plays for about 15-20 seconds then I get the quicktime icon, then comes back about 30 seconds later.  Couple of assumptions I wanted to to verify:

1. The FE definitions on the app are only to allow remote control?  That is, the FE plays no role when streaming content to the ipad?  I ask bc most of my FEs are underpowered and diskless.
   
2. Transcoding of videos for streaming follows the normal Myth/Torc job queue process?  The job itself is a transcode job like any other?
   
3. If I have 3 BEs but have have all jobs configured only to run on my MBE, the streaming API this will obey this setting as well?

Thanks
Dave

[Robert McNamara]

On Sun, May 13, 2012 at 6:04 PM, David Badia <dba...@gmail.com> wrote:
> Just bought the ipad app and am troubleshooting an issue where recorded tv
> plays for about 15-20 seconds then I get the quicktime icon, then comes back
> about 30 seconds later.  Couple of assumptions I wanted to to verify:

This means you are running short of bandwidth somewhere, or on the
outside, are running short of backend CPU. HLS contains two streams--
one video and audio, one audio only. When the iOS media player
classes detect that they can't get data quick enough because they're
bandwidth starved, it switches to the audio only stream. Somewhere,
you're running short of bandwidth. This can also sometimes occur when
the transcode can't keep up with your playback. You'll know for sure
if you pause playback upon streaming start, wait a few minutes, and
then start playback again-- if you never see a switch to audio-only,
then your issue is CPU speed. If you do, then your problem is
bandwidth.

> The FE definitions on the app are only to allow remote control?  That is,
> the FE plays no role when streaming content to the ipad?  I ask bc most of
> my FEs are underpowered and diskless.

Correct. FE settings is only used for the remote/for where to play
back when a piece of media is launched in the library.

> Transcoding of videos for streaming follows the normal Myth/Torc job queue
> process?  The job itself is a transcode job like any other?

No. It runs independent of the job queue, and does not use the job
queue settings.

> If I have 3 BEs but have have all jobs configured only to run on my MBE, the
> streaming API this will obey this setting as well?

The streaming will occur on the backend the media was recorded on, I
believe. This might be more a question for the MythTV people.

Robert

[Robert McNamara]

On Sun, May 13, 2012 at 6:10 PM, Robert McNamara
<robert....@gmail.com> wrote:
> On Sun, May 13, 2012 at 6:04 PM, David Badia <dba...@gmail.com> wrote:
>> Just bought the ipad app and am troubleshooting an issue where recorded tv
>> plays for about 15-20 seconds then I get the quicktime icon, then comes back
>> about 30 seconds later.  Couple of assumptions I wanted to to verify:
>

Note, also, that the backend has to decode the video into raw frames
before transcoding into H.264, and for HLS that decode will always be
in software, so if you're relying on something like VDPAU to decode
video for playback, you're not getting that with streaming, *and*
you're adding the overhead of a CPU-intensive encode. You need
serious CPU here. My Q6600 Quad Core can keep up with most 540p
streaming, but falls behind on anything recorded from my HD-PVR.

Robert

[Myther]

Can a transcode be scheduled so that it doesn't have to happen
realtime?

On May 13, 6:14 pm, Robert McNamara <robert.mcnam...@gmail.com> wrote:
> On Sun, May 13, 2012 at 6:10 PM, Robert McNamara

[Robert McNamara]

On Mon, May 14, 2012 at 8:28 PM, Myther <torri...@gmail.com> wrote:
> Can a transcode be scheduled so that it doesn't have to happen
> realtime?
>

No, not at present. You could technically mimic the commands passed
to mythtranscode by the API as a user job, but there's no concept in
the API of seeing whether there are streams available for a given
piece of media, so when you ask for a stream of an item in the API, it
just bulldozes over the existing stream, starting from scratch.

I know that Chris intends to implement something better, including
support for resuming a partially complete stream. When that exists,
I'll update the app to support it-- currently, though, since the app
is a consumer of the API, it's limited by the behaviors of that API.

Robert

[Myther]

Can HLS use the GPU for transcoding or CPU only?

On May 14, 8:35 pm, Robert McNamara <robert.mcnam...@gmail.com> wrote:

[Robert McNamara]

On Mon, May 14, 2012 at 9:39 PM, Myther <torri...@gmail.com> wrote:
> Can HLS use the GPU for transcoding or CPU only?
>

CPU Only. See the second message in this thread for further detail.

Robert

[David Badia]

On Sunday, May 13, 2012 9:14:35 PM UTC-4, Robert McNamara (Torc Developer) wrote:

On Sun, May 13, 2012 at 6:10 PM, Robert McNamara wrote:

> On Sun, May 13, 2012 at 6:04 PM, David Badia wrote:
>> Just bought the ipad app and am troubleshooting an issue where recorded tv
>> plays for about 15-20 seconds then I get the quicktime icon, then comes back
>> about 30 seconds later.  Couple of assumptions I wanted to to verify:
>

Note, also, that the backend has to decode the video into raw frames
before transcoding into H.264, and for HLS that decode will always be
in software, so if you're relying on something like VDPAU to decode
video for playback, you're not getting that with streaming, *and*
you're adding the overhead of a CPU-intensive encode.  You need
serious CPU here.  My Q6600 Quad Core can keep up with most 540p
streaming, but falls behind on anything recorded from my HD-PVR.

Robert

Ok I think that explains things then.  My SBEs are woefully underpowered and wouldn't stand a chance of playbacke without VDPAU.   I think the recordings I tested were from the SBEs.  I'll try another from the MBE (AMD Phenom II X4 905e Deneb 2.5GHz) which might stand a chance of keeping up?

Interesting that even your machine can't keep up with HD-PVR material.

I'll pursue the possibility of forcing all transcode work to a single BE on the myth list.  Also will hope that VDPAU transcoding support comes sooner than later...

Thanks for the prompt reply.  App looks very slick, nice work!
Dave

[Anthony Giggins]

I'm seeing the same issue, I dont think it would be my backend as its an i5 2400 and handbrake can trancode recordings from my DVB HDHR within a couple of minutes.

potentially it could be my wireless (Dodgey Linksys WAG320N) running in Wireless N only but my airvideo server doesn't have nearly as many issues as torc, personally I'd rather see torc wait and buffer rather then play audio only....

Cheers,

Anthony

[Robert McNamara]

On Wed, May 23, 2012 at 3:03 PM, Anthony Giggins
<se...@seven.dorksville.net> wrote:

> potentially it could be my wireless (Dodgey Linksys WAG320N) running in
> Wireless N only but my airvideo server doesn't have nearly as many issues as
> torc, personally I'd rather see torc wait and buffer rather then play audio
> only....

Where you say torc above, you are actually meaning Myth. MythTV is
the source of your streamed content, the iOS app is extremely "dumb"
when it comes to it.

The application doesn't have the choice to buffer, or to not use the
audio only stream. Live streaming from the application's perspective
consists of the following steps:

1) Call the API requesting a live streaming transcode begin for a
given piece of media.
2) Monitor the live streaming transcode until some content is transcoded.
3) Pass the playlist URL to the iOS native player classes.

That is literally all the app does. There's no playback code, no
custom handling of any kind, and no real way of getting any. The app
is just a go-between between the source of the content (your backend
and its transcoding capabilities) and the player of the content (The
iOS MediaPlayer framework). You could wait for more segments to be
ready, but that would introduce an unacceptable lag time before
starting to play a stream in almost every case. Realistically, your
backend and all network segments between the iOS device and the
backend MUST be able to sustain the transcode *as done by MythTV* and
must maintain enough bandwidth throughout to keep the iOS player
classes happy. Both are out of the control of the application.

Comparing AirVideo to the MythTV backend is inevitable, but they're
fundamentally different. It may very well be that MythTV doesn't have
the most optimized HLS transcode implementation-- it's extremely new--
but it's not something the iOS software can affect. I can't change
the behavior of the Myth HLS implementation any more than your printer
can affect the content of your term paper. ;)

Robert

[Anthony Giggins]

Thanks Robert

I'll wait and see how the HLS code matures as I read there was debate about it being included in 0.25 at all, but maybe an option in Torc for the amount of segments to wait for before begining playback? unacceptable lag verses reliable playback is going to differ betwen users and how they Interconnect too the backend...

Cheers,

Anthony

[Anthony Giggins]

Can confirm this is wireless related works fine when sitting in the same room as the wireless router and the HLS stream is way ahead at the point the stream switches to audio only :( once again I cant see any point of going to audio only thank you apple!

Cheers,

Anthony

[Anthony Giggins]

Hi Robert,

I've done some further testing and theres got to be something in the the Torc playback code, as the same stream created via Torc plays back perfectly in mobilemyth http://www.mobilemyth.net/ without dropping back to the audio only stream.

Regards,

Anthony

[Robert McNamara]

Hi Anthony,

I am not sure what to reply here, then, as there is literally no playback code in Torc.  The only thing I do is invoke MPMoviePlayerController and pass it the playback URL.  Something is definitely fishy here, and I'm going to provide a higher bitrate audio stream for the HBR profiles in the next version with the hope that it addresses your issue.  I can't quite put my finger on the issue that you're experiencing, but to say that it's in Torc playback code isn't accurate as there simply is none (well, none outside of handing it to the OS for playback).  I'd really like to get to the bottom of your issue. The reality is it's not something that most people are experiencing (and in all the other cases we're able to pin it down to something else, and usually correct it by doing so) so I'm not sure where to continue with our troubleshooting.

MobileMyth is a web app and relies on whatever Safari's playback handling is-- I can't say how it's different from my own, or how it interacts with your particular setup.

Robert

--
You received this message because you are subscribed to the Google Groups "Torc for iOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to torc-for-ios...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robert McNamara]

Sorry, I actually replied to this thinking you were the guy with the audio issue.

That said, there's still no playback code in Torc-- it's possible that Safari (as it's actually Apple code) has lower level access to streaming code and is able to provide more buffering some how.  I can look into it a little more, but as of now I'm initializing streaming playback exactly how Apple specifies you should do so so I'm a little at my wit's end as to why you are dropping back to the audio-only stream-- I (and most others) don't experience it outside of bandwidth issues, or transcode speed issues.

Robert