I am using an HTTP call to upload a video using a public URL of a zoom recording. The upload is working, BUT
The name and description, even though supplied in the API call are discarded apparently in the result.
The video ID generated seems to be alphanumeric whereas the video ID is clearly stated in the specs as an integer value. Interestingly enough when using the vimeo app in Integromat I can get a number video ID but when using the Upload API with the upload link it generates a non standard video ID which if course is not accepted by the the vimeo app.
Here's an example Vimeo link I get to the video
https://vimeo.com/640201271/b99c5d6405
the b99... part is nonstandard for some reason.
The Upload API for videos using the link parameter docs:
Vimeo API Reference: Videos | Vimeo Developer
My payload for the https://api.vimeo.com/me/videos call:
"data": "{
"upload":
{
"approach": "pull",
"name": "Alex Sirota's Personal Meeting Room - alex#newpathconsulting.com - 0",
"description": "Recording Start Date/Time: 2021-10-28 09:55 PM - Recording End Date/Time: 2021-10-28 09:55 PM - Duration (min): 0",
"privacy.download": false,
"privacy.embed": "private",
"privacy.view":"nobody",
"size": "784755",
"link": "https://us02web.zoom.us/rec/download/redacted?access_token=redacted"
}
}"
Non-public videos will sometimes have an alphanumeric video id - it's highly recommended to use the "metadata.interactions" objects on the Video response to interact with the video, especially if you're interacting with private videos https://developer.vimeo.com/api/reference/responses/video.
If you'd like this video to be available publicly on the Vimeo app, you would need to ensure to set the privacy.view = 'anybody' on upload (this will also remove the alphanumeric video id).
Related
so I'm encountering some unexpected behavior with subtitles on an HTML5 video.
I am storing my video + subtitles files on Google Cloud Storage and I have a web interface to watch the movies.
My server generates signed URLs for the movie and subtitle files. The movies play fine, and I can view the subtitle text content using the URL. However, using the <track> does not work:
<track label="my_subtitle_file" src="my_signed_url" srclang="en" kind="subtitles">
In Firefox I get an error:
Security Error: Content at <my site> may not load data from <signed GCS url>
In Chrome I get a slightly different error, but I imagine it's the same problem:
Unsafe attempt to load URL <signed GCS URL> from frame with URL <my site>.
Domains, protocols and ports must match.
I suppose I could make a wrapper endpoint on my backend, which fetches the content of the file and serves it. But I am wondering, is there another way? And why do <track> nodes have this severe restriction?
edit
I added a CORS policy to the GCS bucket:
[
{
"origin": ["https://my-domain.com"],
"responseHeader": ["Content-Type"],
"method": ["GET"],
"maxAgeSeconds": 3600
}
]
On the GCS Console I also tried removing the "prevent public access setting". I didn't make the files public though (I still want to require presigned URLs), but it seems GCS is kinda wierd in that you can turn of "prevent public access" without actually making it public.
I'm trying to use a Live stream audio and following exactly what this tutorial says, but it does not work. AmplitudeJS for Live Stream HTML5 Audio I have a blank page and nothing error shows in console. I perceived one "contradiction", in tutorial, Amplitude was not initialized as documentations says:
To initialize Amplitude.js, you must call the Amplitude.init() method and pass in an object that contains an array of songs and settings
I looked for the part of documentation that specify how to use Live Stream, but I didn't find.
I will update that tutorial! To do a live stream, you will have to have a streaming service set up. Then when initializing Amplitude.js, your songs array will have to include one song object with a 'live' flag of 'true'. See: https://521dimensions.com/open-source/amplitudejs/docs#song-objects
An example init, would be like this:
Amplitude.init({
"songs": [
{
"name": "Station Name",
"url": "https://yourstreamingservice.com/something-that-returns-properly-encoded-audio",
"station_art_url": "/station/art/url.jpg",
"genre": "country"
"live": true
}
]
});
When the live flag is set to true, pause cuts off the stream so it doesn't save to local memory and it resumes where the actual stream is at not where the user is set to pause.
Hope this helps!
I used this URL to get the recent media about specific tag like cats using Instagram API. the URL is like this:
https://api.instagram.com/v1/tags/cats/media/recent?access_token=*****
Unfortunately, there is no data and I got the below warning in pagination:
{"pagination":{"deprecation_warning":"next_max_id and min_id are deprecated for this endpoint; use min_tag_id and max_tag_id instead"},"meta":{"code":200},"data":[]}
how can I get min_tag_id or min_tag_id? why there is no data?
I assume you created your client for this request after Nov. 17 2015. Instagram made some changes to their API, see here.
Apps created on or after Nov 17, 2015 will start in Sandbox Mode and function on newly updated API rate-limits and behaviors.
Your app/client is probably in sandbox mode and thus it has limited behavior. It's written down in the docs, section API behaviour:
Data is restricted to sandbox users and the 20 most recent media from each sandbox user.
[...]
As another example, let's consider an endpoint that returns a list of media: /tags/{tag-name}/media/recent. The response returned by this endpoint will contain only media with the given tag, as expected. But instead of returning media from any public Instagram user, it will return only media that belongs to your sandbox users, restricted to the last 20 for each user.
If you create a "cat" tag with your sandbox user, you should see it. Once your app has switched to live, you should see all public available "cat" tags.
Regarding the deprecated warnings, they are normal as they inform apps that used the "old way" about breaking changes. In your case they can be ignored.
Is is possible to receive both video and audio from another peer if the peer who called createOffer() only allowed audio when requested via getUserMedia()?
Explanation by scenario:
Alice connects to a signalling server, and when getUserMedia() is called, chooses to share both video and audio.
Bob connects to the signalling server, and when getUserMedia() is called, only shares audio.
As Bob is the last to party, Bob creates the peer connection offer via RTCPeerConnection.createOffer(). He shares his localDescription which contains SDP data that does not mention video.
The resultant connection is audio-only as the SDP data only contained audio-related information.
Can an offer be created that asks to receive video data without sharing it?
So the key was in the creation of the offer.
Referring to the Specification
The WebRTC 1.0 specification says:
4.2.5 Offer/Answer Options
These dictionaries describe the options that can be used to control the offer/answer creation process.
dictionary RTCOfferOptions {
long offerToReceiveVideo;
long offerToReceiveAudio;
boolean voiceActivityDetection = true;
boolean iceRestart = false;
};
In the case of video:
offerToReceiveVideo of type long
In some cases, an RTCPeerConnection may wish to receive video but not send any video. The RTCPeerConnection needs to know if it should signal to the remote side whether it wishes to receive video or not. This option allows an application to indicate its preferences for the number of video streams to receive when creating an offer.
Solution
RTCPeerConnection.createOffer() can take MediaConstraints as an optional third parameter.
The example I found was from the WebRTC for Beginners article:
Creating Offer SDP
peerConnection.createOffer(function (sessionDescription) {
peerConnection.setLocalDescription(sessionDescription);
// POST-Offer-SDP-For-Other-Peer(sessionDescription.sdp, sessionDescription.type);
}, function(error) {
alert(error);
}, { 'mandatory': { 'OfferToReceiveAudio': true, 'OfferToReceiveVideo': true } });
These MediaContraints can also be used with createAnswer().
Bob's offer will contain audio, but alice will also share her video.
When Bob later wishes to add (video) streams he calls RtcPeerConnection.addStream() and a (re-)negotiation is needed (see negotiationneeded event). This will allow Bob to add different (additional video) or additional streams at any time he wishes. You just have to make sure that on the offer/answer will be exchanged correctly (e.g. at negotiationneeded event).
I wrote a (dart based) webrtc library that might help you to see how it works. See Sender and Receiver
I'm trying to upload images generated in my Flash application to an album on Facebook. This was working earlier in the year, but revisiting the code I now get the following OAuthException:
(#324) Requires upload file
I am using the most recent version of the ActionSccript Facebook API. The setup works like this:
First I do the authentication check with PHP to ensure users have granted permission before having to wait for the Flash to load. I'm requesting the publish_stream and user_photos permissions. The access token comes back correctly.
Once the user is authenticated the Flash is loaded and performs its own initialisation, passing fileUpload=true as part of the init object:
var initObject:Object = {
channelUrl : "myChannelURL.html",
fileUpload : true
}
Facebook.init(
'myAppID',
myCallbackFunction,
initObject,
myAccessToken
);
This seems to work as expected, the callback receives the uid of the current user.
At the end of my application I POST a Bitmap object to a predetermined album:
Facebook.api(
albumID+"/photos",
onImagePost,
{
message:"",
image:new Bitmap(myBitmapData),
fileName:''
},
URLRequestMethod.POST
);
At this point Facebook returns a 400 response:
"error": {
"message": "(#324) Requires upload file",
"type": "OAuthException"
}
What more do I need to do to ensure that this permission is being included?
It turns out that this was not a permissions error at all. Since I last deployed this code Facebook have tightened up their restrictions a bit, and the fileName parameter passed as part of the api call can no longer be an empty string. Simply passing any old text as a file name fixes the problem.
Facebook.api(
albumID+"/photos",
onImagePost,
{
message:"",
image:new Bitmap(myBitmapData),
fileName:'FILE' // required to be non-empty
},
URLRequestMethod.POST
);
Im not sure if this is a solution that can be translated into the Actionscript SDK... But, with the PHP SDK there is a method inside the facebook SDK that is called setFileUploadSupport - try looking in the code for a place to set that parameter to true.