Youtube supports some binary caption file formats, such as ebu-stl.
I've got an *.stl file that uploads and processes just fine when I upload it via the web interface. But when I try to upload it via the API v2 with a POST request, it does not seem to recognize the file format properly. The POST request looks like this:
POST /feeds/api/videos/VIDEO_ID/captions HTTP/1.1
Host: gdata.youtube.com
Content-Type: application/vnd.youtube.timedtext; charset=UTF-8
Content-Language: en
Slug: Title of caption track
Authorization: Bearer ACCESS_TOKEN
GData-Version: 2
X-GData-Key: key=DEVELOPER_KEY
<Caption File Data>
This is how the *.stl file uploaded via the API looks on the website. There should be several lines with readable text.
Everything works fine when I upload a utf8 plain text subtitle file (eg *.vtt) with the same code. Furthermore, if I upload the stl file once via the web interface and once via the API, and retrieve both files through the API afterwards, they are byte-identical.
It looks like an encoding issue to me- youtube receives the file correctly, but probably parses the entire binary file as UTF-8. However, youtube responds with a 4xx error when I ommit either charset= or Content-Language.
Is it possible to upload binary caption files? I would also appreciate confirmation in case it is not possible.
Minimalistic stl file if you want to try it yourself (hex dump). Read it as (ruby):
stl = hex.chars.each_slice(2).map{|x|x.join.to_i(16)}.pack('C*')
API v2 is now officially deprecated. As of April 2, the API v3 now officially support captions. Binary caption files are supported, too.
The documentation is lacking some details as to the raw HTTP requests. You could try using one of their libraries.
I used their python script and took a look at the request it made. For reference, here's a minimal working HTTP request for uploading a binary subtitle/captions file.
The docs aren't mentioning this parameter, but setting uploadType=multipart is important, the API returns an error otherwise.
POST /upload/youtube/v3/captions?uploadType=multipart&part=id,snippet&sync=false HTTP/1.1
Host: www.googleapis.com
Accept: */*
Authorization: Bearer {AUTH_TOKEN}
X-GData-Key: key={YOUR_KEY}
Content-Type: multipart/related; boundary================83250640405719953005==
Content-Length: 7147
Expect: 100-continue
--===============83250640405719953005==
Content-Type: application/json
MIME-Version: 1.0
{"snippet":{"videoId":"Agn_uesF248","language":"en","name":"Subtitle Test 2","isDraft":false}}
--===============83250640405719953005==
MIME-Version: 1.0
Content-Type: application/sla
Content-Transfer-Encoding: binary
{BINARY_CAPTION_FILE_DATA}
--===============83250640405719953005==--
application/sla are ebu-stl caption files. Use text/plain for plain text subtitles (.srt, .vtt, .ass, &c.).
Replace {AUTH_TOKEN} and {YOUR_KEY} with the proper authorization credentials for the scope https://www.googleapis.com/auth/youtube.force-ssl; and {BINARY_CAPTION_FILE_DATA} with the file you wish to upload.
Related
I have a Web server written on top of your standard http module in Node.js. It's been working like a clock for me for serving all kinds of HTML, JavaScript, CSS, and asset content -- making up the bulk of my web pages, naturally.
When the service is requested a URL that maps to a file with an unknown extension (there is no MIME sniffing going on), it simply serves content using chunked transfer encoding with the header Content-Type: application/octet-stream, which has been working wonderfully as well -- I occasionally host files of all kinds on the server and am able to download these without any interference from the user agent, as I'd expect from application/octet-stream handling.
Today, however, I tried to download on a Safari mobile browser running on iOS 9.3.5 on an iPhone 4S, and that thing just plain refused to download from a valid URL, alerting me with:
Download failed. Safari cannot download this file.
I've since tried to add Content-Disposition: attachment and also Content-Disposition: attachment; filename="foobar" for good measure, but it still refuses.
This has been the case with a file called random which is filled with 1000 random bytes. My host headers are (Content-Disposition is optional, as said above):
HTTP/1.1 200 OK
Host: example.com
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="foobar"
Date: Mon, 01 May 2017 13:48:37 GMT
Connection: keep-alive
Transfer-Encoding: chunked
For the record, Android 6.x phone also behaves as expected (in addition to Firefox 53 on my Windows 10 x86_64 host), downloading from the URL without a hitch.
What's going on with Safari here?
Yes, the only thing you can download with Safari on iOS is image. This is because iOS does not expose file structure to user (download file to somewhere user can never see does not make any sense), it has nothing to do with anti web attack. Browser on Android can download arbitrary files because Android file structure is visible to user.
Here is a previous discussion on Apple community: https://discussions.apple.com/thread/3697948?start=0&tstart=0
The ONLY thing you can save to an iPhone, from Safari, is a pic. Nothing else, and no downloads.
It is possible that iOS supported video files can be downloaded in future, but it is unlikely for arbitrary files with application/octet-stream MIME type.
After I have spent so much time trying to find the solution, I came with this solution:
Replace the octet-stream with pdf.
<?php
$file = 'data/report/foobar.pdf';
header('Content-Description: File Transfer');
header('Content-Type: application/pdf');
header('Content-Disposition: attachment; filename="'.$file.'"');
header('Expires: 0');
header('Cache-Control: must-revalidate');
header('Pragma: public');
header('Content-Length: '.filesize($file));
readfile($file);
?>
I want to upload a text file to OneDrive API.I don't have any idea about multipart/related. Can any one suggest me how to put below data in postman to upload a file.
I resolved this issue.We need to provide Authorization & Content-Type in header and provide the remaining information in body as raw and select content-type as Text.
i am sending mail from my rails application , but in lotus notes is coming as atttot4u.dat.dat file , attachment , but in other mails , like gmail , zimbra it's coming properly ..
this is the header
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Please help me in the same .
Have you tried changing the filename ?
We were having a similar problem with Lotus Notes, receiving *.dat files with weird names, which would change every time we would open the email or its preview.
Finally, removing all kinds of spaces and accented characters did the trick.
This post put us on the right track, even though not Lotus-related.
I'm struggling to get a WAV file to play on a HTML page as either an HTML5 audio tag or via a regular downloadable link in mobile Safari (iPad/iPhone):
<audio controls src="audio-pcm_s16le-8k.wav"/></audio>
audio
The HTML5 audio object just shows Cannot play audio file in it, and when I click to download the anchor referenced one I get a black page with a "can't play this circle" in the middle. I've tried various frequencies (8000, 11025, 16000, 32000, 44100), various encodings (mu-law, Linear Signed 16-bit LE and BE), various containers (.wav, .caf, .aiff), and various audio conversion programs (Audacity, ffmpeg, and Apple's own afconvert)... I can't get audio to play (unless I make it MP3 -- and no, I can't just use MP3 or AAC, I need a "raw" format for reasons too long to get in to here).
I looked at the supported formats for iOS and it appears to support WAV... anyone got any experience with this issue? I'm on latest iOS 6.0.1
EDIT: The selected answerer got me to the issue, but the reason is in the comments of the answer. Bottom line is it requires HTML range headers for playing the files.
Well, you've certainly gotten me on the right track at least... it's apparently not the file at all... it's the web server. Same exact content from stockley works, but on my web server it doesn't. I'll have to look over the HTTP response in detail I suppose. My web server is returning Content-Type: audio/x-wav so it's not that...
Checking the headers for the test site I set up, you want to be returning Content-Type: text/html for the page containing the HTML data you need:
And Content-Type: audio/x-wav for the actual audio file (http://www.test.com/file.wav)
Through a run of trial and error I found that you need a content-range header for it to work. Here's an example of my headers that allows a wav file to play in Safari for iOS:
Content-Range: bytes XX-XX/XX
Content-Type: audio/wav
Content-Disposition: attachment; filename="whatever.WAV"
Content-Length: XX
Hope this helps!
It works great. I used Content-Range: bytes XX-XX/XX and Content-Length: XX
I try to automatically translate a document using version 3 of Google Document List API.
The documentation just says to add a "sourceLanguage" and/or a "targetLanguage" parameter to the initial HTTP POST request.
So here is the request I'm sending :
POST /feeds/upload/create-session/default/private/full?sourceLanguage=fr&targetLanguage=en
Authorization: GoogleLogin auth=<authentication token>
GData-Version: 3.0
Content-Type: application/atom+xml
Content-Length: 163
X-Upload-Content-Type: text/plain
X-Upload-Content-Length: 50
<?xml version="1.0" encoding="UTF-8"?><entry xmlns="http://www.w3.org/2005/Atom" xmlns:docs="http://schemas.google.com/docs/2007"><title>french.txt</title></entry>
I tried with very simple .txt files as well as .doc (french to english).
The files are uploaded correctly to the service, but translation does not occur.
The translation using Tools->Translate menu on the uploaded documents works OK, so the "translation engine" is able to perform the translation I'm trying to do through the API.
Is the documentation wrong ? How does automatic translation work ?