Status Update
Comments
cb...@google.com <cb...@google.com> #2
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.
[Deleted User] <[Deleted User]> #3
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.
ka...@creditkarma.com <ka...@creditkarma.com> #4
[Deleted User] <[Deleted User]> #5
c....@gmail.com <c....@gmail.com> #6
[Deleted User] <[Deleted User]> #7
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?
ka...@gmail.com <ka...@gmail.com> #8
ig...@gmail.com <ig...@gmail.com> #9
Furthermore, requesting '
XX...@vida.com <XX...@vida.com> #10
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.
de...@gmail.com <de...@gmail.com> #11
Mi...@peopleconnect.us <Mi...@peopleconnect.us> #12
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!
fi...@gmail.com <fi...@gmail.com> #13
il...@icandeliver.ru <il...@icandeliver.ru> #14
an...@tty.no <an...@tty.no> #15
Can you confirm if the quality and resolution is of higher quality now?
If you are still seeing this, could you provide an example of the file or the exact codec, resolution and framerate of the video?
[Deleted User] <[Deleted User]> #16
I tried using the Google Drive integration with Google Photos, but it was a nightmare because deleting a photo from Drive wouldn't necessarily delete it from Photos. Now I'm hoping to use the Google Photos API.
I tried downloading a video from Google Photos today, but the 50MB video from my phone resulted in a 13MB download. Also, the video was taken at a time as per the filename on my phone: 20181124_140007.mp4 but the EXIF data in the downloaded video had been rewritten by Google Photos and the only timestamp in there was 2018:11:24 16:48:07, which was probably the time that my phone uploaded the video. So now I have a poorer quality copy of my original video with the wrong timestamp.
And it's just this second dawned on me that I've deleted files from my phone to free up space, so the only original copy of those files is on Google Photos and I can't get access to them.
I'm just trying to keep a few files in sync between different devices. It shouldn't be this difficult.
[Deleted User] <[Deleted User]> #17
Any solution about this issue ???
jo...@artlogic.net <jo...@artlogic.net> #18
Any news about this issue. ?
su...@google.com <su...@google.com> #19
someone work on it?
cl...@tradera.com <cl...@tradera.com> #20
I have recently discovered that my 1080p 60fps videos are now transcoded down to 30fps with high compression - they look terrible. But if I directly download them from the Google Photos Web they are fine. Why is the API transcoding, please?
Here is an example which I share globally for all to see.
Album =
The attachment contains three copies of the video:
- the original file from the phone directly (1080p 60fps)
- the file as downloaded from the Google Photos Web (similar but not identical to the above)
- the file as downloaded from baseUrl with =dv -- this shows only 30 fps and file size is 1/10 of the above
[Deleted User] <[Deleted User]> #21
This is getting really ridiculous. This API has been the only means of interacting with Google Photos since you all did away with the Google Drive folder a couple months ago and yet we still can't get any traction on this issue that's been open for OVER A YEAR???? What kind of terrible management is going on over there that the person assigned to this hasn't been canned already for not completing their work?
For the love of all things holy Google... PLEASE FIX THIS DUMPSTER FIRE OF AN API!!!!
ro...@gmail.com <ro...@gmail.com> #22
I'm using
com.google.photos.library:google-photos-library-client:1.4.0
to fetch videos. It was working pretty well but for some new videos i got issue IOException with reason 500 from google endpoints:
It describe itself more like this:
java.io.IOException: Server returned HTTP response code: 500 for URL:
this is (partial) output from fields of MediaItem
google.photos.types.MediaItem.base_url=
google.photos.types.MediaItem.mime_type=video/mp4, google.photos.types.MediaItem.media_metadata=creation_time {
seconds: 1570301787
}
width: 576
height: 1024
video {
fps: 29.918403416437823
status: READY
}
, google.photos.types.MediaItem.filename=video-c523eb1bb7a18b3e31f97ac581bffabf-V.mp4}
all i do is append =dv to the end of baseUrl
da...@unimarket.com <da...@unimarket.com> #23
mean:
I cannot remove above comment...
kf...@gmail.com <kf...@gmail.com> #24
[Deleted User] <[Deleted User]> #25
ja...@globalpay.com <ja...@globalpay.com> #26
[Deleted User] <[Deleted User]> #27
ma...@e-hps.com <ma...@e-hps.com> #29
will this be fixed anytime soon?
be...@probance.com <be...@probance.com> #30
ro...@globalpay.com <ro...@globalpay.com> #31
gi...@bit-key.nl <gi...@bit-key.nl> #32
rd...@gpcsolutions.fr <rd...@gpcsolutions.fr> #33
ch...@contentpass.de <ch...@contentpass.de> #34
rd...@gpcsolutions.fr <rd...@gpcsolutions.fr> #35
da...@isealtires.com <da...@isealtires.com> #36
[Deleted User] <[Deleted User]> #37
[Deleted User] <[Deleted User]> #38
li...@gmail.com <li...@gmail.com> #39
pa...@plaidcloud.com <pa...@plaidcloud.com> #40
mi...@datamantis.com <mi...@datamantis.com> #41
sh...@gmail.com <sh...@gmail.com> #42
ma...@gmail.com <ma...@gmail.com> #43
se...@gmail.com <se...@gmail.com> #44
de...@curbside.com <de...@curbside.com> #45
[Deleted User] <[Deleted User]> #46
ma...@gmail.com <ma...@gmail.com> #47
br...@homeward.com <br...@homeward.com> #48
dm...@team.wrike.com <dm...@team.wrike.com> #49
th...@gmail.com <th...@gmail.com> #50
to...@paxport.net <to...@paxport.net> #51
fa...@particles.io <fa...@particles.io> #52
ma...@madworx.se <ma...@madworx.se> #53
an...@resourceguruapp.com <an...@resourceguruapp.com> #54
ov...@cyscale.com <ov...@cyscale.com> #55
[Deleted User] <[Deleted User]> #56
re...@gmail.com <re...@gmail.com> #57
[Deleted User] <[Deleted User]> #58
[Deleted User] <[Deleted User]> #59
i can easily download the original video with =dv but =m18, =m22 etc simple dont work after full video encode
it works for a few then is gone
ma...@gmail.com <ma...@gmail.com> #60
ma...@gmail.com <ma...@gmail.com> #61
dy...@trufflesec.com <dy...@trufflesec.com> #62
bd...@gmail.com <bd...@gmail.com> #63
Hello Google,
any news on that topic? The first issue has been introduced in 2018. Would you please come with a solution? ${baseUrl}=dv does not work and it has definitely something to do with the exposed endpoint.
Many thanks
With best regards
[Deleted User] <[Deleted User]> #64
are you still working on this? I don't want do download my videos squished down in quality with the api...
[Deleted User] <[Deleted User]> #65
ba...@gmail.com <ba...@gmail.com> #66
to...@gmail.com <to...@gmail.com> #67
jf...@fogandfrog.com <jf...@fogandfrog.com> #68
oc...@gmail.com <oc...@gmail.com> #69
Come on google, I'm PAYING you extra to store original quality video. you are holding my data ransom here... please fix this bug.
[Deleted User] <[Deleted User]> #70
jo...@gsa.gov <jo...@gsa.gov> #71
iv...@propelo.ai <iv...@propelo.ai> #72
hy...@gmail.com <hy...@gmail.com> #73
[Deleted User] <[Deleted User]> #74
[Deleted User] <[Deleted User]> #75
[Deleted User] <[Deleted User]> #76
Poor decision. OneDrive provides original quality via API.
[Deleted User] <[Deleted User]> #77
fc...@medallia.com <fc...@medallia.com> #78
fr...@rabitsch.net <fr...@rabitsch.net> #79
al...@protonmail.com <al...@protonmail.com> #80
What the fuck is going here Google ? Do you want users let your services down ? I always lov(ed?) Android, but those kind of WFT is making me really reconsider it for the future
ca...@gmail.com <ca...@gmail.com> #81
gr...@gmail.com <gr...@gmail.com> #82
[Deleted User] <[Deleted User]> #83
ta...@taylortrimble.com <ta...@taylortrimble.com> #84
My data is too valuable to entrust to Google if they are going to snub their customers by not fixing a bug like this after knowing about it for 3 years. I'll be exfiltrating my Google One data and canceling my subscription ASAP.
ad...@firstdollar.com <ad...@firstdollar.com> #85
[Deleted User] <[Deleted User]> #86
ta...@taylortrimble.com <ta...@taylortrimble.com> #87
cm...@google.com <cm...@google.com> #88
ta...@taylortrimble.com <ta...@taylortrimble.com> #89
da...@zenhub.com <da...@zenhub.com> #90
na...@airasia.com <na...@airasia.com> #91
se...@google.com <se...@google.com>
[Deleted User] <[Deleted User]> #92
za...@google.com <za...@google.com> #93
gm...@google.com <gm...@google.com> #94
[Deleted User] <[Deleted User]> #95
to...@hornbach.com <to...@hornbach.com> #96
ma...@mx.com <ma...@mx.com> #97
[Deleted User] <[Deleted User]> #98
M
to...@hornbach.com <to...@hornbach.com> #99
I never heard of Google Photos product previously although I have been working in Google Cloud Partner ecosystem for over two years, so am quite familiar with Google's product portfolio both in and outside Google Cloud.
When I learned about Google Photos from one of the Machine Learning courses that I am taking I thought that it sounds like a pretty good product so I spent some time to check it out. I liked the interface and the features but I also learned that this product does not allow to export the photos and videos back at their original resolution/quality level. This is vendor lock-in and is a deal breaker.
I cannot recommend this product to my customers and friends. In fact, I feel that now that I know about the vendor lock-in situation, it is my duty to mention this to any client or friend who is using Google Photos or is considering it. I also feel it is my duty to mention this every time I mention Google Photos in my line of work as an example of successful application of ML models.
I believe that in our time, and I'm writing this in year 2023, not allowing customers to export and take away all their data is socially unacceptable for a SaaS. I'm looking forward to this being fixed so that I can try this product again and begin recommending it to my clients and friends.
Description
It would be great if maxAge, includeSubdomains and preload could be controlled as well.
Reference: