the config i am using is inherited from the designers of the elgg platform
and i have explored it enough to know most of what it is doing.
perhaps i need to replace the location block that targets .php files with
one that explicitly lists all the possible locations of php files instead...
which wou
ok, thanks.
1. i was thinking that this was the case, based on the results i have seen,
yes.
2. ah, ok - i didn't appreciate that. i found this page with php code:
http://licson.net/post/stream-videos-php/
is there a standard / recommended way to approach this with nginx?
3. i believe the proble
scenario:
i am using a site built with the php based social framework called elgg
(www.elgg.org) and am extending elgg to stream video.
i discovered that nginx is not serving the mp4 files (for example) with the
'Accept-Ranges' header and thus without streaming support.
i am searching for a way to
one of the core elgg coders was speaking about using the X-Sendfile header
to bypass php processing and serve the file directly, though i don't know
enough about how the architecture of nginx/php would handle that to know if
it would help here or not.
Posted at Nginx Forum:
http://forum.nginx.org
after more exploration, i see that files which are placed in the root of my
site can be preloaded and seeked correctly when played via the video.js
package or directly as a video element.
however, the videos that are played via the php application that runs my
site are stored outside of the root di
ok, thanks for clarifying.
i just did a clean test as suggested and do indeed see the Accept-Ranges
header being returned automatically by nginx.
in doing that - the mp4 video still does not stream/pre-buffer as i am
desiring.
i accessed the test video file that is on the homepage of the video.js
i just did a test of inserting a meaningless header into the response, by
adding the add_header directive into the various levels of the nginx config,
beginning with http, then server and then the location that i have setup to
focus on mp4 files.
i found that the header is successfully inserted in
this stackoverflow response on the topic is one that quotes the code i
used... i have also seen this page linked by several other pages which said
this was a workable approach:
http://stackoverflow.com/questions/14598565/serving-206-byte-range-through-nginx-django
i am not blindly following anythi
also.. since only the headers added via the final location block will be
used, does this then mean that i need to put conditional logic into that
block to check the current url for particular paths - if some headers are
needed for some paths only.. ?
since most of my served items will end in the .
thanks for responding here.
the 206 code was advised by every tutorial i found online.
i am using nginx 1.7.2, so cannot upgrade.
>You shouldn't try to add Accept-Ranges header manually. It will
>be added automatically when nginx supports range requests to the
>resource in question.
how do i noti
i need to ensure the Accept-Ranges header is present to serve video files
while supporting forward/backwards seeking.
i notice in many tutorials for nginx that this header is shown as being
present in server response headers by default, yet not on my present setup.
i have used the following to add
i am creating a plugin for the elgg open source social networking framework,
that adds the projekktor media player (http://www.projekktor.com/) to elgg.
i am so far unable to get projekktor to seek video/audio files on the
webserver (tested using nginx 1.5.13 + 1.7).
i have asked on the projekktor
aha! yes, i needed to remove 'service'.
now i see the correct 1.7 version code. thanks!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249670,249677#msg-249677
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/n
those two commands don't show any version numbers, so i am not presently any
closer to identifying the issue here.
the paths returned look fine to me, from what i know already.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249670,249674#msg-249674
_
thanks for assisting. i ran that command and see 3 repos which provide
nginx. from what i see there, the 1.7.0-1 wheezy package is the candidate
and also has been installed.
i just checked my local development machine which is running lmde - the
version of nginx is also the same spurious ubuntu 0.
after running the upgrade to 1.7.01 mainline version on debian, the nginx
version check (service nginx -V) lists:
0.91-ubuntu1 - even though 1.7.01 is listed in the package manager in
debian.
does this mean that debains repos are serving an incorrect package?
Posted at Nginx Forum:
http://forum.
ah, i found the answer..
i needed to change the javascript mimetype to 'application/javascript'
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,245997,246000#msg-246000
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/l
thanks for responding. :)
so... has a change been made in the way i would activate the gzip process
between the stable and mainline versions?
in nginx.conf?
this is the list of options i was successfully using in stable (built
through trial and error):
gzip on;
gzip_http_version 1.0;
i just replaced a stable install with the mainline version (1.5.8) and
noticed that the outputted files are not being gzipped.
i ran nginx -V and do not see any arguments that enable gzip.
is there a reason why the stable version included gzip and this mainline
does not?
do i need to manually build
19 matches
Mail list logo
