Re: Video files not streaming on mobile devices - ZMS only
"Robert Buchholz [email protected] [zms-developers]" <[email protected]> Wed, 11 Nov 2015 17:10:52 +0100
| Newsgroups | gmane.comp.cms.zms.devel |
|---|---|
| Message-ID | <[email protected]> |
--gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hallo, I don't think ZMS's file serving code handles the HTTP "Range" header, which is required by iOS to stream videos: https://developer.apple.com/library/prerelease/ios/documentation/AppleAppli= cations/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingV= ideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6 Best, Robert On 09.11.2015 13:21, Sebastian T=C3=A4nzer [email protected] [zms-developers] w= rote: > Hi Hiels, >=20 > thanks a lot. From what I see this is related to the FileFromData functio= n that is used to created blob fields programmatically. We=E2=80=99re not d= oing that. In our case the user simply uploads a video file in a file field= , nothing else. Storing is handled by ZMS just fine. The file does not come= from the ZODB, definitely not. The file is in the mediadb folder in the sy= stem and returned from there (deleting the file physically in the folder ac= tually causes an error) >=20 > The problem we=E2=80=99re experiencing seems to be related to the way ZMS= handles HTTP reponses of this data as there is a special HTTP =E2=80=9Estr= eam=E2=80=9C method in the native OFS.File source. >=20 > Our headers we set by our python script to return the video are _exactly_= the same. >=20 > I=E2=80=99ll play a bit more with this and will post my insights :-) >=20 > Best > Sebastian >=20 >> Am 09.11.2015 um 13:16 schrieb Niels Dettenbach [email protected] [zms-dev= elopers] <[email protected]>: >> >> Am Montag, 9. November 2015, 12:55:52 schrieben Sie: >>> Hey Niels, >>> >>> thanks for the quick reply. We are in fact using mediadb and from what = I see >>> the files do come from the filesystem. Doesn=E2=80=99t ZMS take care of= this itself >>> when using getData() on a file field? >> >> If i remember right, i had to change this method to get a generated file= from a special db into the mediadb (when required): >> >> # -------------------------------------------------------------------= ------- >> # ZMSGlobals.FileFromData: >> # -------------------------------------------------------------------= ------- >> def FileFromData( self, data, filename=3D'', content_type=3DNone, med= iadbStorable=3DFalse): >> >> before: >> >> def FileFromData( self, data, filename=3D'', content_type=3DNone ): >> >> otherwise each generated file from a onChangeObject is landing in the ZO= DB instead of a configured mediadb. If i remember right, with Images / Imag= e blobs this was working out of the box instead. >> >>> >>> My problem is that the data return from the mediadb by ZMS does not wor= k >>> with video files - any other files work just fine. The files themselves= do >>> not reside in the ZODB but in the filesystem. >>> >>> I=E2=80=99d love to see your code snippet to read the actualy file from= the mediadb. >>> >> >> ...just out of my work, >> this works here so far for MP3s in a web player and in iTunes. If i reme= mber right, i had to fiddle with the correct Headers a while. So may be thi= s could bring you on a way it works for you (hope so)... >> >> Cleaned out a bit from stuff not relevant here. Some of the headers are = gone to the frontend proxy, so this may be incomplete or lines are commente= d out. No guarantees so far!!! >> >> request =3D container.REQUEST >> RESPONSE =3D request.RESPONSE >> session =3D context.REQUEST.SESSION >> >> RESPONSE =3D request.RESPONSE >> counted =3D False >> >> try: >> if context.getObjProperty('audiofile_playout',request): >> file=3Dcontext.getObjProperty('audiofile_playout',request) >> else: >> file=3Dcontext.getObjProperty('audiofile',request) >> >> #filetype=3Dfile.getContentType() >> filetype=3D"audio/mpeg" >> filename=3Dfile.getFilename() >> filesize=3Dfile.getDataSizeStr() >> fileurl=3Dfile.getHref(request) >> >> # rise in object request counters >> try: >> # count on the ad >> # -> remember last played/requested url >> context.countMP3Requested() >> >> # generates cookie / session if required >> #if not session.get('last_played_id'): >> # session.set('last_played_id','no') >> >> counted =3D True >> except: >> counted =3D False >> >> RESPONSE.setStatus('200') >> #RESPONSE.setHeader('Cache-Control', 'no-cache') >> RESPONSE.setHeader('Content-Type', filetype) >> RESPONSE.setHeader('Content-Length', filesize) >> RESPONSE.setHeader('Content-Disposition','attachment;filename=3D%s'%fil= ename) >> >> return file.getData() >> >> except: >> RESPONSE.setStatus('404') >> return 'Error: File not found' >> >> >> good luck, >> >> >> Niels. >> >> -- >> --- >> Niels Dettenbach >> Syndicat IT & Internet >> http://www.syndicat.com >> PGP: https://syndicat.com/pub_key.asc >> --- >> >> >> >> >=20 --=20 Mit freundlichen Gr=C3=BC=C3=9Fen Robert Buchholz ----------------------------------------------------------- yeepa Software Engineering mailto:[email protected] ----------------------------------------------------------- yeepa is a registered trademark of SNTL Publishing GmbH & Co KG Hegelplatz 1, 10117 BERLIN T: ++49-(0)30 - 209 127 8-4 F: ++49-(0)30 - 209 127 8-1 www.sntl-publishing.com [email protected] ----------------------------------------------------------- --gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWQ2iMAAoJEKZK0qp6IqRx3o8P/iM+XjpgXki2WHF+eJhvsqDj nNfB8Req8bNEEv54KUwfTCYDBGwsY/wMeAYGSxuQORh+Va+gRCA5SgVIctkAX4h9 2IWG8i2EYCyZx69NLyr+qZf8UQVPoEp9ah6dSXx+buOFheew5n9fthD3D0MXXVjG ahN+IdxsokW9pL9MbPE9z5wQ5T9xYUq4fecjul14F/ZiISyjSelAf12Lpt59WBqb D7czjZGmHLCdyN0J9PzkeJsH/ql1GCV3BbkjimL10HL4VnvD8fKu8Lh4kLf05FhG Ins1o7qlg9PqLcwrCU9W7UlS3AWLWdZDg6PcasxAzSktHJEjW1rv84H6joW5XPLN k/AA7rZXEmeDDGEvJOjvXqjqt7OyOkhPsnBOcSUZuPDy3lFj3AfOQEHjB93Y1zfc izjpN5ZTWSjWyVRdk2lwz1VOMXteYhhtzTKvw/8u6x3ZsrUJIpBibvL5Q+zep+v4 BTtClXrsWLeO9GYms05kT+D4LoBnqcPqzXASJUbYNMtfsx5Akw1pQfPqIDBZwDtM u9wht9f0NgjVyRwj163DjUVOgckWpcwUZHUN/oSD2GTWzqANGQrfUC1Z6ZK8pd1i 73sfTJdVhONnFeDQxh1XgwTxDJBJPbqYSVafVbampyBU9e9tURfD2SujXfjolg8n iupS483hHPtlWBne+jUR =D/Lb -----END PGP SIGNATURE----- --gadLlcKxlUQ2v6b06KxXfOupme4SfFfLa--