Fixed
Status Update
Comments
au...@google.com <au...@google.com> #2
Thanks for the report!
Unfortunately you can't specify a height or width for video files at the moment, and the 'dv' parameter returns a downsampled version of the video. There is currently no option to retrieve the video in its original resolution.
I have forwarded this to the team and will update here once I hear back.
Unfortunately you can't specify a height or width for video files at the moment, and the 'dv' parameter returns a downsampled version of the video. There is currently no option to retrieve the video in its original resolution.
I have forwarded this to the team and will update here once I hear back.
da...@google.com <da...@google.com> #3
Thanks
The documentation should be updated then?
https://developers.google.com/photos/library/guides/access-media-items#video-base-urls
If specifying a video width or height is not possible the sentense "with your required dimensions:" makes no sense then.
The documentation should be updated then?
If specifying a video width or height is not possible the sentense "with your required dimensions:" makes no sense then.
au...@google.com <au...@google.com> #4
Thanks - Good catch, I'll get the documentation updated. (The previous sentence is quite explicit, but we must have missed this one.)
da...@google.com <da...@google.com> #5
Is there a separate ticket for adding the ability to download full resolution video? Or does this documentation ticket also cover that? I want to make sure I'm tracking the correct ticket so I'll know when that feature is added.
da...@google.com <da...@google.com> #6
Re #5, we can track this here. I have renamed the title of the issue to capture this.
hm...@google.com <hm...@google.com> #7
Not sure if this works (or is fool-proof), but I tried reverse-engineering this based on the URLs I see in Google Photos directly, and in Picasa. My hunch is, if you pass the attribute "=m37", you might get a higher resolution video. How I tracked this down is:
1. Go to Picasa's API for showing your albums:https://picasaweb.google.com/data/feed/api/user/YOUR_USER_ID_HERE?kind=album&prettyprint=true . Find the album you are looking for, in the element <gphoto:id>xxxxx</gphoto:id>. Note that this album id is different from your Google Photos album id.
2. Now look at your album via Picasa's API:https://picasaweb.google.com/data/feed/api/user/YOUR_USER_ID/albumid/YOUR_ALBUM_ID?kind=photo&prettyprint=true . Find the video you are looking for (you can search by title etc.).You will see the following defined:
<media:content url='https://lh3.googleusercontent.com/dummy-image-url=m18 ' height='360' width='640' type='video/mpeg4' medium='video'/>
<media:content url='https://lh3.googleusercontent.com/dummy-image-url=m22 ' height='720' width='1280' type='video/mpeg4' medium='video'/>
<media:content url='https://lh3.googleusercontent.com/dummy-image-url=m37 ' height='1080' width='1920' type='video/mpeg4' medium='video'/>
Specifically look for those items where the type='video/mpeg4'.
If you observe the URLs you will see that they have the same URL with a different suffix: =m18 for the smallest resolution, =m22 for the medium resolution, and =m37 for the highest resolution. This is what I see in my albums; you might see something else. What I have found, though, is that if I simply append "=m37" to the URL shown in Google Photos API, it seems to neatly bring me a good resolution video.
Product Team,
Is my hypothesis correct? Or am I completely off-base?
1. Go to Picasa's API for showing your albums:
2. Now look at your album via Picasa's API:
<media:content url='
<media:content url='
<media:content url='
Specifically look for those items where the type='video/mpeg4'.
If you observe the URLs you will see that they have the same URL with a different suffix: =m18 for the smallest resolution, =m22 for the medium resolution, and =m37 for the highest resolution. This is what I see in my albums; you might see something else. What I have found, though, is that if I simply append "=m37" to the URL shown in Google Photos API, it seems to neatly bring me a good resolution video.
Product Team,
Is my hypothesis correct? Or am I completely off-base?
hm...@google.com <hm...@google.com> #8
One more thing - I got the idea of looking at the Picasa API because in the preview page of Google Photos I saw that the small preview of my video was suffixed with "=m18", and I had seen that while I was working with the Picasa API.
hm...@google.com <hm...@google.com> #9
Re #8 Adding "=m37" works for me in a browser but gives me a 404 when calling the API.
Furthermore, requesting 'https://lh3.googleusercontent.com/[video-baseUrl]=dv ' now results in an Error 400 (did work before for low-res videos) - do I just leave that here, or do I open another issue?
Furthermore, requesting '
da...@google.com <da...@google.com> #10
Please do not use any flags that are not documented on the "Access media items" guide in our developer documentation: https://developers.google.com/photos/library/guides/access-media-items
Undocumented flags are not supported and should not be used directly. If you have a use case for other types of encoded or processed video, please do file a new feature request, describing your use and any technical requirements.
Undocumented flags are not supported and should not be used directly. If you have a use case for other types of encoded or processed video, please do file a new feature request, describing your use and any technical requirements.
da...@google.com <da...@google.com> #11
How is this a feature request, this is clearly a bug. The dv link should download the full resolution just like the documentation states and also its a minimum functionality of getting a media item. Currently there is no way to download the video so the feature is broken. Please update the bug type and priority.
ow...@google.com <ow...@google.com>
hm...@google.com <hm...@google.com> #12
Correction (I shouldn't say just resolution but rather full quality of the video):
Based on the description in the documentation the dv parameter should download the full quality video. There is no mention of down sampling the in documentation.
In addition it the basic expectation of getting a media item is to have access to its full quality download.Not having this ability makes the api incomplete missing basic functionality most apps require.
Finally access to full quality video would be consistent with the way images download works (full quality with some tagging stripped).
This is why I think this is a bug, the behavior is unexpected, undocumented, and inconsistent with other interfaces.
Thanks!
Based on the description in the documentation the dv parameter should download the full quality video. There is no mention of down sampling the in documentation.
In addition it the basic expectation of getting a media item is to have access to its full quality download.Not having this ability makes the api incomplete missing basic functionality most apps require.
Finally access to full quality video would be consistent with the way images download works (full quality with some tagging stripped).
This is why I think this is a bug, the behavior is unexpected, undocumented, and inconsistent with other interfaces.
Thanks!
hm...@google.com <hm...@google.com> #13
Any update on this? There's little point in me using the API if I can't download the original (or thereabouts) video. It can't be that hard to implement.
da...@google.com <da...@google.com>
au...@google.com <au...@google.com> #14
It's blocked by 109754198 but I don't have permission to view that.
Description
Applying the newer AGP KMP plugin to androidx.sqlite breaks the Gradle metadata such that a JVM project depending on the artifact will attempt (and fail) to use the android artifact instead of the JVM one.
This was originally reported in SQLite KMP b/396148592
Here is a diff on the metadata, left is before AGP KMP is used (i.e. after reverting the changes in this CL ) and right is with AGP KMP applied: https://diff.googleplex.com/#key=EY2FqaJWQbUQ
Let me know if you need a sample project, but if you create a new JVM or Kotlin project and depend on
androidx.sqlite:sqlite:2.5.0-beta01
and try to use classes from it, it will fail at runtime with a class not found exception. When inspecting the deps via:dependencies
you will notice it attempts to use the-android
artifact instead of the-jvm
one: