Draikin

Sorry for the wait, this took me more time than expected. There’s three files here. The new lytespryte, which now has no actual background anymore. What’s new are the top and bottom gradients. These need to be positioned at the top and bottom of the video window, underneath the lytespryte elements.

lytespryte 2015
top gradient
bottom gradient

I could merge these images but then the layout of the lytespryte would change completely. I didn’t add a button to the timeline because it’s only visible when you hover over the video. I’m not sure if you need that for the “audio-only” lytes? Let me know if this works.

I’m running into the same problem.

PHP Version 5.5.9-1ubuntu4.11
extension version 0.12
libssh2 version 1.4.3
banner SSH-2.0-libssh2_1.4.3

I haven’t gotten around to this yet, but I think I should be able to finish this during the weekend. Do you intend to push out an update with the UI changes alone?

I’ll try and add those later this week.

Here’s a new sprite using the icons mentioned above. If anything else needs to be added, I can look into that as well, but so far I haven’t seen embeds that show more than that. The title and positioning would need to be done using CSS, let me know if you need any help with that.

From what I’m seeing, the embedded players now have a lot less features. It’s just the title, a “watch later” and a “share” button, and then the play button in the middle. Are you seeing the same as well? It would certainly make it easier to replicate.

I indeed read that they started pushing the update live for everyone today. I’ll take a look at it!

Do you mean the transparent UI? I’ve seen that recently, it looks really nice. I’m certainly willing to look into providing an update for the lytesprite when Youtube makes the switch.

Okay, so after getting more information from the Jetpack team, I think we can conclude the following:

– The problem with Jetpack delivering different types (both PNG and JPG) is related to WordPress renaming the file because one with the same name already existed. It adds a “-1” to the filename in that case, and apparently that’s what caused Photon to not always use the original image as a starting point to generate the other ones.
– EWWW and Photon aren’t all that compatible. The only benefit you’ll get out of using EWWW with Photon is an optimized original image. All the other resized images are made by Photon, so there’s no point in letting EWWW generate those. If you’re like me, and you don’t compress the original images, then there’s very little benefit in using the two together. However, since Photon is serving the images anyway, file size doesn’t really matter, outside of getting a higher Pagespeed score. It also means the server has more time to handle other requests.

Conclusion: Photon, for being free, is rather awesome. EWWW offers superior compression, but this only really matters when you’re not using a CDN. If you’re using Photon, EWWW offers little added value. They also have a great support team ??

Yeah, but that’s the problem, the original was still a PNG :/ EWWW is set to only convert the featured image, large, medium and thumbnail to JPG. So if I upload a PNG, it will still store the PNG as the original. And that’s the image being sent to Photon. So here’s the situation on my local webserver after uploading an image:

Original: PNG
Featured, Large, Medium, Thumbnail: JPG

And here’s what I get from Photon:

Original, Featured: PNG
Large, Medium, Thumbnail: JPG

And that has me terribly confused because from your explanation, all the five images from Photon should be of the same type (in this case PNG).

Okay, but in that case I’m puzzled as to why Jetpack is serving JPG files, despite the original being a PNG. Using Photon, the original and the featured image are a PNG, but “Large”, “Medium” and “Thumbnail” are JPG. Since Jetpack doesn’t convert files, I’d expect all to be PNG…

I understand the example. I thought the filenames indicated that it was using the resized images from EWWW, but then I was drawing the wrong conclusion. Does that mean Photon also converts PNG to JPG, just like I’m doing with EWWW? Because then, I’m again confused why it’s returning the featured image as a PNG file, while the other resizes are in fact returned as a JPG file? Sorry for all the questions, just trying to wrap my head around this.

I’ve taken a look at the filter, that should indeed work, thanks.

EDIT: for anyone looking to do the same, here’s what you need to add to your functions.php:

/* Change Youtube Lyte thumbnails to sddefault.jpg */
add_filter(‘lyte_match_thumburl’,’lyte_my_own_thumburl’,10,1);
function lyte_my_own_thumburl($thumb) {
return str_replace(“hqdefault.jpg”, “sddefault.jpg”, $thumb);
}

I have to admit though, the maxresdefault looks better than the sddefault.jpg, even with the browser resizing them. The ideal solution would be Youtube Lyte doing its own resizing based on the maxresdefault file, and then caching the result for subsequent requests. I realize that’s a bit more ambitious ??

Perhaps I misunderstand what you mean by “original” but that explanation doesn’t quite match what I’m seeing here. Judging from the filenames generated by Photon, it seems to me that all the resized versions of the image are uploaded to Photon, and that Photon then tries to find a match for the required resolution. That’s why I’m seeing these urls:

Original: …/image.png?resize=1280%2C720
Featured: …/image.png?fit=625%2C9999
Large: …/image-625×352-1.jpg?resize=625%2C352
Medium: …/image-300×169-1.jpg?resize=300%2C169
Thumbnail: …/image-150×150-1.jpg?resize=150%2C150

So that’s why I found it odd that the featured image didn’t use the same url as the “Large” image, and instead generated a new image from the original PNG file. And that’s also why I don’t quite understand that, if it does find an exact match, that it seems to recompress the image anyway and returns a larger file (except for the original image, that seems to be exactly the same as generated by EWWW).

In any case, I’ll send you the links to the images and my website through the contact form, that should clarify what I mean.
EDIT: I just submitted the support request with more details.

Thanks for the response. Regarding the caching: this was a new post, so EWWW immediately generated the images, not later on. So Photon should have cached the correct version (which it in fact did for the other resized images). What I can say is that the featured images have the same size as the “large” image (max width 625 pixels and max height 9999 pixels). But the large image was handled correctly by Photon in the sense that it was also a JPG. It’s the featured image that Photon created from scratch.

I’ll look into sending you a link, the website currently isn’t using Photon though. Would you have enough data available if I give you the links to all the different images from Photon and the ones generated by EWWWW? My third question (Photon serving larger files when it doesn’t need to) is probably the biggest issue preventing me from using it at the moment, so I’d appreciate reading your thoughts on that.