I`m software developer and trying to upload some videos using Google Photo API, but I want to set up "High quality mode" of such videos programmatically.
So, the point is that my app must upload videos without user participation every 15 GiB.
Could anybody advice to me - how to do it?
Thanks for help!
All media items uploaded to Google Photos using the API are stored in full resolution at original quality. They count toward the user’s storage.
check here: https://developers.google.com/photos/library/guides/api-limits-quotas
Related
I written a code(In python) to automatically upload videos to YouTube
Now, the problem:
I can only upload 6 videos (quota limit = 10,000/day)
Is there any way to upload video on YouTube by python or any other language
Thx in advance
There are two ways to upload videos to YouTube. You can do it manually though the YouTube web application or you can do it programmatically though the YouTube data api.
The YouTube data api has a cost based quota system. Which means that you are given a default of 10000 quota points, and each request you make costs something against that quota. Inserting videos for example costs 1600 quota points.
Is there any way to upload video on YouTube by python or any other language
The programming language you use does not matter, the quota will be the same. So no there is no other way of uploading videos to YouTube using the api.
You should just request a quota extension if you need to upload more videos.
I'd like to know if it's possible to record an audio extract on Google Assistant (with Dialogflow and Firebase) and play it later? The idea is to:
Ask the user to tell his name vocally.
Record it.
Play it afterwards.
I read these answers. The answer was no, but maybe there's an update as now we can listen to what we said on Google Assistant "myactivity" as seen here.
The answer is still no, as a developer. While users have recordings available, there's no way to access them programmatically and no way to play them through Dialogflow.
You can read this great article which explains a trick to record audio and play it back on the Google Assistant using a progressive web app.
The design consists of thses two parts:
A web client for recording and uploading the audio files to Google Cloud Storage.
An Action that plays the audio file from Cloud Storage
You'll also find the url of the open-sourced code on github at the end of the article.
I am currently planing the total cost of hosting my videos on azure. After studying the pricing I noted that the costs for storing the data is actually much lower than the price for converting them. Unfortunately I will have many videos, but they won't be watched a lot. Therefore the relative cost for converting them to different formats is too high for me.
Now my question, do I actually need to convert the videos to different formats or wouldn't it be possible to send the video directly from the storage to the browser?
To send video's from storage to browser you can use SAS urls as Zain mentioned. You need to ask yourself what devices,bitrates your solution is targeting: which browsers, web only or web + mobile.
Probably you want your users be able to start watching video before it has been fully downloaded on client(progressive download). Make sure that you encoded it into desired bitrate and moov atom in the video is placed at the beginning of file -https://support.jwplayer.com/customer/portal/questions/12945932-mp4-file-progressive-play.
Based on your original video format and answers to above questions you might need to re-encode your videos and upload re-encoded version to server.
Yes, it's possible to send them directly from storage to the browser, just like it's possible to send any file that you make publicly accessible.
If you're going to store your videos in blob storage, just make sure you either mark the container as public or you generate SAS urls for each video that make them publicly accessible.
We've been asked if we can help a client stream uploaded video files while overlaying a unique watermark per user, eg, their email address or username. Security on the stream needs to be good, but not necessarily ironclad. That is, enough to put someone off trying to grab the bits outside of the player (so some encryption is very helpful), while the overlay would hopefully make it clear that re-recording it, or saving the file, would help us track the perpetrator.
I was hoping some combo of Azure Media Services and the Azure Media Player might be able to do something like this, but for the life of me I can't find anything online about it.
We're not wedded to Azure if it's not possible using that service but is through an alternative.
Thanks so much for your help. It feels like this shouldn't be a unique request, but I can't find anything on Google. Maybe my search terms are letting me down.
It really depends if you are trying to do server side watermarking or client side watermarking. Currently Azure Media Services doesn't have support for server side watermarking.
However, this is easily achieved on the client side with Azure Media Player -> because the player uses HTML elements, you can easily add an additional HTML element for your overlay and style it with CSS to display the required information.
I am working on an App that will have a bunch of pictures and videos the user will need to have. The app's mantra is having these videos and pictures available on demand and on the go. However, I am concerned about the app being too fat (big), in essence turning off some customers who prioritize size over substance. The preference has always been to have the customer be able to access these videos from anywhere regardless of 3g/wifi (i.e. local on the device). What are the really good options? Assuming I choose to elect to go the non-local route (i.e. using wifi/3g), what are my options there as well? Please advice. The size of the videos/pics could be up to 1.5GB.
The usual approach seems to be to download and store the videos on demand. A lot of the apps I've seen allow the user to manage the stored videos themselves so that they can remove videos if they aren't going to use them again.