YouTube plugin and stuttering playback.

Hardware Mac Desktop 4,1 Dual 8 Core CPUs 6GB ram
Mac OS X Yosemite 10.10.3
Firefox 37.0.1
Youtube.groovy plugin downloaded and installed 2015/05/23
Serviio 1.5.2
Toshiba Regza TC model 55SL500U @192.168.2.15
Firewall set to allow both Serviio and Serviio-Console to accept incoming connections
Network is wired Ethernet over cat 5E

URL of video in Firefox <https://www.youtube.com/watch?v=h7EHfBd0uNQ>
Source URL in Serviio console <https://www.googleapis.com/youtube/v3/videos?id=h7EHfBd0uNQ>
Media type video
Preferred online content quality - tried at all 3 settings - it made no difference
****All other media libraries have been unshared so this is the only file being tested****

What is the problem?
Using the TV control I navigate to the online videos and select this Youtube file.
It starts to play and after approximately 26 seconds begins to stutter - that is it does play cleanly all the way through.

What have I tried?
1. The same video plays perfectly in Firefox.
2. All my other Serviio media libraries play perfectly over the LAN
3. I tried allocating up to 8 cores on my Dual CPU but it made no difference.
4. Here is the DEBUG log….

What am I doing wrong?


respect…

Peter

Can anyone please help me on this? So far no replies..... Thanks....

[jhb50]

The video is transcoded to an .stf file in your transcoding directory(see console tab). Copy it to a serviio share, rename it to .mpg and then play it as a file and see if it still stutters. If so then its due to the bitrate over the network or tv limits. If not then its some delay in the transcoding itself. Watch the transcoding directory in explorer and hit F5 to refresh and watch the speed of the transcode.

Thanks for your reply - seriously thanks for taking the trouble.
But I am on a Mac (as indicated at the top of my post).
The console tab is not the one to look at to find the transcode directory. It is the Delivery tab.
Also Mac's don't use IE. We use Safari or Firefox (my preference as noted at the top of my post).

Finally when I cd to the transcoded files location as indicated by the Delivery tab, namely
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/ it's not accessible because:
Gandalf:zyxvpxvq6csfxvn_n0000000000000 pteeson$ ls -al
total 0
drwxr-xr-x 6 root wheel 204 27 Apr 19:41 .
drwxr-xr-x 24 root wheel 816 30 Apr 14:25 ..
drwxr-xr-x 6 root wheel 204 26 May 17:28 0
drwx------ 12 root wheel 408 25 May 18:30 C
drwxr-xr-x 4 root wheel 136 26 May 17:31 Cleanup At Startup
drwx------ 12 root wheel 408 26 May 17:36 T
Gandalf:zyxvpxvq6csfxvn_n0000000000000 pteeson$

Now I could certainly chmod the T dir but it seems to me that there must be a better explanation as to why it plays perfectly through Firefox on my computer and not via the YouTube plugin. And furthermore why does it need to be transcoded in the first place.

All my other HD media files served by Serviio play just fine over my wired LAN and I have 15/5Mbps Internet over fibre which is certainly more than adequate.

Can we think of what else it might be?


respect...

Peter

[jhb50]

I love problems! This one is unique. Here is my explanation and answers to your questions..

Running ffmpeg against the youtube-url shows the file is a 16.4 MB AVC/AAC-LC.MP4 with an aggregate bit rate ~ 219Kbps and res 320x240
According to the serviio Toshiba profile it will be transcoded to mpeg2video/aac.mpg
Note the following profile note however which you can try.
<!-- Some models might play h264 in mpegts - in that case the below can be uncommented -->

Note that youtube now offers adaptive streaming formats in addition to the old static formats used by Serviio.
The youtube player (html5?) will use these and play the streams directly on your web browser.

Serviio must however use ffmpeg to play the static streams even if it just wraps them (transcodes) in mpegts as is required for DLNA streaming.
When I add the youtube id to Serviio and play in the Mediabrowser it plays at about 1 second in 10.

To test why, I used ffmpeg native to download this 16.4MB file, and found it transfered 1.8GB!! Thats more than 100 times the data with an effective rate of 3.4frames per second, so thats why playback stutters, but shows it is not a Serviio poblem.

When I download the file with YouTube-dl the 16.4MB transfers in less than a minute at ~300fps, so its not a youtube file problem.

To further test, I obtained the "Low Res" version of the file (format 5) vs the format 18 youtube uses for "Medium" and "High" res. It is an flv1/mp3.flv file and it plays fine.

So I conclude that this is a youtube/ffmpeg bug and there is something in the ffmpeg request that causes youtube to send the downloaded file with extraneous bytes/packets that ffmpeg ignores when reading the stream, but that those bytes/packets impede the playback in real time.

I've never seen something like this.

The only solution would be to add a res= option to the plug in so you can force selection to the working low res version.

[jhb50]

I love problems! This one is unique. Here is my explanation and answers to your questions..

Running ffmpeg against the youtube-url shows the file is a 16.4 MB AVC/AAC-LC.MP4 with an aggregate bit rate ~ 219Kbps and res 320x240
According to the serviio Toshiba profile it will be transcoded to mpeg2video/aac.mpg
Note the following profile note however which you can try.
<!-- Some models might play h264 in mpegts - in that case the below can be uncommented -->

Note that youtube now offers adaptive streaming formats in addition to the old static formats used by Serviio.
The youtube player (html5?) will use these and play the streams directly on your web browser.

Serviio must however use ffmpeg to play the static streams even if it just wraps them (transcodes) in mpegts as is required for DLNA streaming.
When I add the youtube id to Serviio and play in the Mediabrowser it plays at about 1 second in 10.

To test why, I used ffmpeg native to download this 16.4MB file, and found it transfered 1.8GB!! Thats more than 100 times the data with an effective rate of 3.4frames per second, so thats why playback stutters, but shows it is not a Serviio poblem.

When I download the file with YouTube-dl the 16.4MB transfers in less than a minute at ~300fps, so its not a youtube file problem.

To further test, I obtained the "Low Res" version of the file (format 5) vs the format 18 youtube uses for "Medium" and "High" res. It is an flv1/mp3.flv file and it plays fine.

So I conclude that this is a youtube/ffmpeg bug and there is something in the ffmpeg request that causes youtube to send the downloaded file with extraneous bytes/packets that ffmpeg ignores when reading the stream, but that those bytes/packets impede the playback in real time.

I've never seen something like this.

The only solution would be to add a res= option to the plug in so you can force selection to the working low res version.

First of all thanks for your investigating this...
I am trying to add online streaming to my use of Serviio and that was why I got the YouTube plugin.

Although I've been programming computers for >40 years there's always something new to learn (thank goodness).
I know almost nothing about media formats beyond their extensions - mp3, mp4, m4v etc.
Also a modest understanding of the DLNA (UPnP) client/server protocol.

So your post is an eye opener to me....a nice contribution to my education... thanks.

Having first got YouTube-dl I then downloaded the file (YouTube-dl https://www.youtube.com/watch?v=h7EHfBd0uNQ)
and moved it into my media library and played it back via Serviio to my Toshiba TV.
Worked great (one of the most utterly sublime pieces of music IMHO.)

Also tried your 1st suggestion of un-commenting the line in the Toshiba profile. It made no difference.

So here are a number of questions as I try to move forward with adding streaming online media to my use of Serviio:
What should we do about this specific situation?
Is this specific problem restricted to just this one file?
Or is it generic to all YouTube online URLs?
Does the author of the YouTube plugin (zip?) know about this? If not should he?

I welcome and solicit your guidance and suggestions on how to proceed....

kind regards....

Peter

[jhb50]

What should we do about this specific situation?

Since the plugin does not allow you to override the console resolution, and you want low resolution for this video, you need to make a new plugin called youtubelow.groovy, invoke it with a modified resource url (line 18) eg: googleapisdlow and change it back by adding this in place of line 40

  Code:

resourceUrl = new URL(resourceUrl.toString().replace("googleapislow","googleapis"))


then delete lines 111 thru 123 plus 129 so that format 5 is always selected.

Is this specific problem restricted to just this one file? Or is it generic to all YouTube online URLs?

Only one I have seen

Does the author of the YouTube plugin (zip?) know about this? If not should he?

Its not a Serviio problem, but it would be nice to be able to override the console quality with &res=low

Well thanks very much for your help.
But that's more work than I am willing to take on at this time.
I'd have to get Eclipse and re-learn it plus the groovy language, maybe Maven, debug it and test it.
That doesn't scare me but it's not worth it for just one file.

Now I have it downloaded I can play it any time I wish.
I'll try some other YouTube videos and see if I have trouble with them.
If I do I might re-visit -- but I have 2 other higher priority projects to keep me busy in my retirement.

Thanks again...
respect...

Peter

[jhb50]

What work? Copy and rename the plugin and modify as instructed and add to plugins. ~3minutes.

Ahh.. I didn't realize I could just open it with a text editor... Thanks...

[zip]

Moving this to support forum.

Since I have not had any problems with other YouTube videos, (so far), and since I have DL'd the original file I see no need to make an extra plugin just for that one file.

It is certainly bizarre that after I chose to begin learning how to stream online media using Serviio the very first video was such a weird file.

Thanks for the contribution to my education....

respect....

Peter