Livestreaming via FFmpeg en perl cgi (of php)

Pagina: 1
Acties:

Onderwerpen


  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
Hallo,

Ik ben bezig met een project met webcams. Hiervoor is het nodig dat er een livestream wordt opgezet die via het web is te bekijken, middels flash. Nu hadden we in eerste instantie het idee om dit via een media server als wowza te doen, alleen blijkt dit heel erg moeilijk te worden omdat de camera die we hiervoor hebben niet het juiste MPEG4 formaat naar buiten stuurt (hij verstuurt MPEG4 part2 waar h.264 vereist is). Nieuwe camera's bestellen is helaas geen optie, dus moet het omgezet worden middels transcoding.

Via FFmpeg is het mogelijk live de stream om te zetten naar FLV, wat prima werkt. Nu wil ik alleen niet de webserver gebruiken van FFmpeg zelf, ivm security. Daarom had ik een PHP script gemaakt die de transcoding via FFmpeg start en de boel naar de browser stuurt. Dit werkt opzich wel redelijk, behalve dat PHP hiervoor niet snel genoeg lijkt te zijn. Het beeld blijft een lange tijd stil staan voor er wat gebeurd en als hij eenmaal begonnen is gaat het ook met horten en stoten.

Als alternatief heb ik hetzelfde scriptje in perl gemaakt, wat wel snel gaat. Probleem hiermee is alleen dat als de browser gesloten wordt, dat FFmpeg gewoon door blijft lopen, wat op langere termijn nogal een impact krijgt op de CPU load. In PHP kan je middels register_shutdown_function zorgen dat de boel netjes afgesloten wordt, maar in Perl bestaat die optie niet (of ik ken hem niet).

De vraag is dus, hoe kan ik er voor zorgen dat de stream gestopt wordt zodra de browser gesloten wordt?

Hier het perl scriptje:

code:
1
2
3
4
5
6
7
8
9
10
11
#!/usr/bin/perl -wT

$| = 1;

local $ENV{"PATH"} = "/bin:/usr/local/bin:/usr/bin";
local $ENV{"BASH_ENV"}="";

print "Pragma: no-cache\n";
print "Content-type: video/x-flv\n\n";

exec("/usr/bin/ffmpeg -er 4 -y -r 10 -b 320 -qmin 1 -qmax 3 -s 704x576 -an -bufsize 80000 -f rtsp -i rtsp://192.168.1.165:554/mpeg4/media.amp -f flv - 2> /dev/null");


En voor de geintresseerden ook het PHP script voor het geval daar een oplossing in te vinden is:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
$descriptorspec = array(
   0 => array("pipe", "r"),  // stdin is a pipe that the child will read from
   1 => array("pipe", "w"),  // stdout is a pipe that the child will write to
   2 => array("file", "/tmp/error-output.txt", "a") // stderr is a file to write to
);

$cwd = '/tmp';

$process = proc_open('ffmpeg -er 4 -y -r 10 -b 320 -qmin 1 -qmax 3 -s 704x576 -an -bufsize 80000 -f rtsp -i rtsp://192.168.1.165:554/mpeg4/media.amp -f flv - 2> /dev/null', $descriptorspec, $pipes, $cwd);

register_shutdown_function(array('flv_streamer', 'kill_stream'), $process);

if (is_resource($process)) {
    // $pipes now looks like this:
    // 0 => writeable handle connected to child stdin
    // 1 => readable handle connected to child stdout
    // Any error output will be appended to /tmp/error-output.txt
    
    while (!feof($pipes[1])) {
        echo fgets($pipes[1]);
        
        ob_flush();
        flush();
    }

    // It is important that you close any pipes before calling
    // proc_close in order to avoid a deadlock
    $return_value = proc_close($process);
}

function kill_stream($process) {
    $status = proc_get_status($process);
    
    //close all pipes that are still open
    fclose($pipes[1]); //stdout
    fclose($pipes[2]); //stderr
    //get the parent pid of the process we want to kill
    $ppid = $status['pid'];
    //use ps to get all the children of this process, and kill them
    $pids = preg_split('/\s+/', `ps -o pid --no-heading --ppid $ppid`);
    foreach($pids as $pid) {
        if(is_numeric($pid)) {
            echo "Killing $pid\n";
            posix_kill($pid, 9); //9 is the SIGKILL signal
        }
    }
       
    proc_close($process);
}

  • sariel
  • Registratie: Mei 2004
  • Laatst online: 22-05-2024
Tsja, wat misschien een optie is, is om het transcoden met VLC te doen. VLC kan een video-server opzetten die live-streaming doet vanaf een webcam of andere source (ook andere stream van het internet). Als je dan je PHP/Perl/Watooit-script een fopen doen naar die stream en deze 1:1 door zetten naar de browser van de client. Het maakt dan niet uit als de browser gesloten wordt want VLC blijft toch wel streamen, ongeacht het aantal "clients".

opzet:

webcam -> vlc -> vlc-transcoded-stream -> Webserver-PHP/Perl -> browser of media player

Persoonlijk zou ik dat PHP/Perl script er tussen uit halen en dmv portforwarding de browser direct toegang geven tot de stream, maar ok.


commandoregel:
code:
1
./vlc <input> --sout "#transcode{vcodec=FLV1,acodec=mp3}:std{access=http,dst=0.0.0.0:8081/stream.flv}"

[ Voor 11% gewijzigd door sariel op 13-08-2009 11:45 ]

Copy.com


  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
sariel schreef op donderdag 13 augustus 2009 @ 11:43:
Tsja, wat misschien een optie is, is om het transcoden met VLC te doen. VLC kan een video-server opzetten die live-streaming doet vanaf een webcam of andere source (ook andere stream van het internet). Als je dan je PHP/Perl/Watooit-script een fopen doen naar die stream en deze 1:1 door zetten naar de browser van de client. Het maakt dan niet uit als de browser gesloten wordt want VLC blijft toch wel streamen, ongeacht het aantal "clients".

opzet:

webcam -> vlc -> vlc-transcoded-stream -> Webserver-PHP/Perl -> browser of media player

Persoonlijk zou ik dat PHP/Perl script er tussen uit halen en dmv portforwarding de browser direct toegang geven tot de stream, maar ok.


commandoregel:
code:
1
./vlc <input> --sout "#transcode{vcodec=FLV1,acodec=mp3}:std{access=http,dst=0.0.0.0:8081/stream.flv}"
Bedankt voor je antwoord.

VLC heb ik ook al getest, maar die werkt helaas niet zo lekker. Is een beetje onbetrouwbaar, die doet het dan eventjes en na een paar minuten crasht het. Ook vreet vlc nogal wat meer performance, iets wat ook een issue is. Het punt is dat er uiteindelijk een grotere hoeveelheid camera's op deze manier aangestuurd gaan worden, dus de stream altijd open laten staan wordt gewoon echt een probleem.

De reden dat ik het door een script heen wil laten lopen is dat de security belangrijk is. De stream rechtstreeks aanroepen zou uiteraard kunnen, maar dan heb je veel minder de controlle er over.

  • sariel
  • Registratie: Mei 2004
  • Laatst online: 22-05-2024
HaBl schreef op donderdag 13 augustus 2009 @ 11:54:
[...]


Bedankt voor je antwoord.

VLC heb ik ook al getest, maar die werkt helaas niet zo lekker. Is een beetje onbetrouwbaar, die doet het dan eventjes en na een paar minuten crasht het. Ook vreet vlc nogal wat meer performance, iets wat ook een issue is. Het punt is dat er uiteindelijk een grotere hoeveelheid camera's op deze manier aangestuurd gaan worden, dus de stream altijd open laten staan wordt gewoon echt een probleem.

De reden dat ik het door een script heen wil laten lopen is dat de security belangrijk is. De stream rechtstreeks aanroepen zou uiteraard kunnen, maar dan heb je veel minder de controlle er over.
De reden waarom ik vlc aangeef is omdat het de mogelijkheid heeft om een stream-flv te maken zonder dat deze additionele schijfruimte in beslag neemt. Van ffmpeg weet ik dit niet.
Ik heb nog eventjes gezocht op het net naar manieren om flv's veilig te streamen, en ben hier op gekomen:
- http://www.flashcomguru.c...lv-video-via-PHP-take-two
- http://www.flash-video-soft.com/flash-media-server/ (betaal-flv-server)
- http://www.longtailvideo.com/players/jw-flv-player/ (RTMP via PHP-script?)

Copy.com


  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
sariel schreef op donderdag 13 augustus 2009 @ 12:05:
[...]

De reden waarom ik vlc aangeef is omdat het de mogelijkheid heeft om een stream-flv te maken zonder dat deze additionele schijfruimte in beslag neemt. Van ffmpeg weet ik dit niet.
Ik heb nog eventjes gezocht op het net naar manieren om flv's veilig te streamen, en ben hier op gekomen:
- http://www.flashcomguru.c...lv-video-via-PHP-take-two
- http://www.flash-video-soft.com/flash-media-server/ (betaal-flv-server)
- http://www.longtailvideo.com/players/jw-flv-player/ (RTMP via PHP-script?)
Voor FFmpeg geld hetzelfde, die spuugt gewoon rechtstreeks de binaries naar STDOUT. Ook gekeken naar je link suggesties, hier had ik alleen ook al mee ge-experimenteerd. FLV streamen via PHP gaat in dit geval niet werken, ze gaan er daar vanuit dat het om losse FLV bestanden gaat, niet om livestreams. Die flash-media-server gaat niet werken omdat die hetzelfde probleem krijgt met transcoding + ik ben afhankelijk van een linux omgeving en die player is wel goed, maar dat is echt puur en alleen een player.

Probleem is dat RTMP maar een beperkt aantal formaten ondersteund, welke onze camera niet bezit. Het enige dat die camera ondersteund is RTSP (MPEG4 part2 dus) en MJPEG. Het betrefd een Axis 215 PTZ camera overigens.

Verwijderd

Is het niet een idee om iets direct met Apache te doen?

Het is alweer een tijd geleden maar ik denk dat je met mod_rewrite en/of mod_proxy ofzo wel iets moet kunnen bedenken. Daarnaast is een proxy setup denk ik zowieso aan te raden want via je huidige methode via PHP/Perl start je een ffmpeg instance per request?!. Wat doe je als je meerdere bezoekers tegelijk hebt?

Kun je mod_proxy niet zo opzetten dat deze met de ffmpeg webserver samenwerkt? Je hebt dan wel mischien precies 1 ffmpeg transcoder per webcam maar ook niet meer dan dat. Die kunnen dan ook verspreid staan over meerdere (virtuele) servers met je Apache webserver als het punt waar alle streams op te vragen zijn.

En als je een uitdaging zoekt kun je mischien iets met multicast proberen. Met IPv6 is multicast nu een inherent onderdeel van de transportlaag en elke router en switch ondersteunt het dus. hmm, HTTP multicast over IPv6?!?

  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
Verwijderd schreef op donderdag 13 augustus 2009 @ 13:32:
Is het niet een idee om iets direct met Apache te doen?

Het is alweer een tijd geleden maar ik denk dat je met mod_rewrite en/of mod_proxy ofzo wel iets moet kunnen bedenken. Daarnaast is een proxy setup denk ik zowieso aan te raden want via je huidige methode via PHP/Perl start je een ffmpeg instance per request?!. Wat doe je als je meerdere bezoekers tegelijk hebt?

Kun je mod_proxy niet zo opzetten dat deze met de ffmpeg webserver samenwerkt? Je hebt dan wel mischien precies 1 ffmpeg transcoder per webcam maar ook niet meer dan dat. Die kunnen dan ook verspreid staan over meerdere (virtuele) servers met je Apache webserver als het punt waar alle streams op te vragen zijn.

En als je een uitdaging zoekt kun je mischien iets met multicast proberen. Met IPv6 is multicast nu een inherent onderdeel van de transportlaag en elke router en switch ondersteunt het dus. hmm, HTTP multicast over IPv6?!?
Nou, opzich een heel goed idee moet ik zeggen. Ik ben er uitgebreid mee gaan testen, alleen dan wel rechtstreeks met mjpeg. Probleem is namelijk als ik de streams van FFmpeg continu open laat staan dat dit een te hoge CPU load genereerd.

Alleen na nog wat verder te testen is ook dit helaas geen optie omdat mjpeg ten eerste niet goed genoeg wordt ondersteund en ten tweede een belachelijke hoeveelheid dataverkeer genereren.

Dus ik ben eigenlijk nog steeds opzoek naar een alternatief dat a) niet teveel bandbreedte kost, b) niet teveel CPU load c) goed ondersteund wordt door clients en d) goed te beveiligen is. Als iemand nog een geniale ingeving heeft houd ik mij aanbevolen :)

Acties:
  • 0 Henk 'm!

Verwijderd

Je zou in Apache een speciale handler kunnen instellen voor bijvoorbeeld een .cam bestand.

Dit werkt het zelfde als wanneer je PHP als cgi instelt ipv als de mod_php module. Op het moment dat Apache een request krijgt voor een .php bestand dan start deze de php-cgi executable en geeft de naam van het opgevraagde bestand mee als argument. PHP leest het bestand en voert het uit en schrijft alle output naar stdout precies zoals ffmpeg doet. De kunst is dus eigenlijk om een soort ffmpeg wrapper te schrijven.

Je zou dus een heel simpel bash script kunnen schrijven en die aanstellen om uitgevoerd te worden wanneer er een .cam bestand wordt opgevraagd. Eventueel kun je de ffmpeg opties in het .cam bestand zelf bewaren en dan na wat input checking natuurlijk gewoon ffmpeg aanroepen en alle output meteen doorpompen naar Apache.

In dit script zou je eventueel ook het multiplex geheel kunnen doen wat eigenlijk niet veel meer hoeft te zijn dan een check om te kijken of een ffmpeg instance al is gestart en zoja daarop in te haken. Ik weet zo even niet hoe je op een multicast pipe inhaakt. Je hebt dan wel meerdere bash scripts, 1 voor elk request, die de stdout van ffmpeg oppikken en meteen weer uitspugen naar Apache, naar de client dus.

Ik weet dat Bash zeer efficient is in het doorpompen van pipes aangezien ik zelf meerdere scripts gebruik voor mijn eigen server beheer waarbij ik vaak meerdere gigabytes door bash heen jaag zonder probleem en zo snel als mijn raid setup het kan aanleveren. Bash is natuurlijk ook om het hele POSIX pipe idee heen gebouwed.

Er zijn 3 problemen die ik zo kan bedenken in deze setup:
1) Je multicast pipe, bijgebrek aan een beter woord, moet natuurlijk wel zijn buffer in de gaten houden. Terwijl ffmpeg zijn stdout doorpompt naar de stdin van de multicast pipe moet wel elk bash script een copie van die stdout ontvangen. Een named pipe is daar niet geschikt voor omdat elke write naar de fifo ook maar 1 read oplevert. Dus slecht 1 van de bash scripts krijgt wat ffmpeg heeft uitgespuugd. Hier zijn meerdere oplossingen voor zoals meerdere named pipes met een verdeel daemon of UDP broadcast over localhost mischien, etc.

2) Voor MPEG streams werkt dit dacht ik, maar voor de client is het alsof die een bestand opent waarvan het begin mist. Of FLV dan ook nog afspeelt weet ik niet dus mischien moet je in je bash script een fake header uitspugen zodat de client denkt dat hij het bestand vanaf het begin opent. Streaming bestaat ook eigenlijk niet in HTTP, het heet eigenlijk progressief downloaden oftewel de speler begint alvast terwijl de data binnenkomt.

3) Zoals je zelf ook al merkte, wat te doen als de client disconnect. Ik vermoed dat Apache op een manier toch aan de handler zal vertellen dat deze mag stoppen dus check de documentatie van Apache eens.

Zoals je wel ziet is dit nog niet helemaal goed uitgedacht. Het is vooral het gebrek aan een manier om de stdout van ffmpeg aan meerdere clients te versturen dat lastig is. Je kunt dit in iedergeval eens uitproberen met 1 ffmpeg instance per request wat opzich met een bash scriptje van 2 lijnen kan. En als je bandwijdte wilt besparen is multicasting natuurlijk de way-to-go. Mischien zou je dan ook eens naar FFServer moeten kijken? 8)7 :)

Acties:
  • 0 Henk 'm!

Verwijderd

HaBl schreef op donderdag 13 augustus 2009 @ 11:31:
In PHP kan je middels register_shutdown_function zorgen dat de boel netjes afgesloten wordt, maar in Perl bestaat die optie niet (of ik ken hem niet).
Perl kent een END-block dat uitgevoerd wordt bij het afsluiten van het script. Niet altijd robust. Een andere optie is om zgn. signals af te vangen. Zie hier voor de standaard methode en hier voor een alternatief.

Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 20:34
Volgens mij ben je het helemaal verkeerd aan het aanpakken. Zoals Docey al opmerkte ga je nu pér gebruiker de stream converteren (maar wel altijd naar hetzelfde formaat). Dat is natuurlijk echt zonde van de bandbreedte.

Je moet dus een streaming server opzetten die één keer converteert en de geconverteerde stream aan meerdere clients kan aanbieden. VLC is daar ideaal voor. Er zijn ongetwijfeld nog wel meer alternatieven. Maar zelf met Perl of PHP wat in elkaar hacken lijkt me hier niet de beste aanpak; het probleem is te complex om simpel en robuust op te lossen vanuit een PHP script.
Nu wil ik alleen niet de webserver gebruiken van FFmpeg zelf, ivm security.
Wat bedoel je hier precies mee? Aan welke risico's denk je dan? Als FFmpeg alleen een stream aanbiedt via HTTP is er niets aan de hand, lijkt me? (Desnoods laat je FFmpeg alleen op localhost binden en dan sluis je de gewenste stream door via Apache als reverse proxy of een PHP script.)

[ Voor 24% gewijzigd door Soultaker op 14-08-2009 12:46 ]


Acties:
  • 0 Henk 'm!

  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
Soultaker schreef op vrijdag 14 augustus 2009 @ 12:44:
Volgens mij ben je het helemaal verkeerd aan het aanpakken. Zoals Docey al opmerkte ga je nu pér gebruiker de stream converteren (maar wel altijd naar hetzelfde formaat). Dat is natuurlijk echt zonde van de bandbreedte.

Je moet dus een streaming server opzetten die één keer converteert en de geconverteerde stream aan meerdere clients kan aanbieden. VLC is daar ideaal voor. Er zijn ongetwijfeld nog wel meer alternatieven. Maar zelf met Perl of PHP wat in elkaar hacken lijkt me hier niet de beste aanpak; het probleem is te complex om simpel en robuust op te lossen vanuit een PHP script.


[...]

Wat bedoel je hier precies mee? Aan welke risico's denk je dan? Als FFmpeg alleen een stream aanbiedt via HTTP is er niets aan de hand, lijkt me? (Desnoods laat je FFmpeg alleen op localhost binden en dan sluis je de gewenste stream door via Apache als reverse proxy of een PHP script.)
Het is ook niet de bedoeling dat voor iedere gebruiker een stream opgezet wordt. Alleen om CPU load te beperken, is het wel de bedoeling dat een stream pas gestart wordt als een gebruiker hier om vraagt. Mocht er al een stream actief zijn moet deze al bestaande stream opgepakt worden.

Ik ga ook niet een hele streaming server in elkaar flanzen, dat is inderdaad een beetje onnodig werk en veel te gevoelig. Mijn bedoeling was dat PHP of Perl gaat checken of de gebruiker is ingelogd en ook de benodigde rechten heeft op de stream, als dat het geval is wordt de stream doorgestuurd naar de browser. Dus FFmpeg blijft de streaming doen, de output hiervoor wordt gewoon 1 op 1 doorgestuurd door een scriptje.

Reden hiervan is dat de stream dan niet voor de hele buitenwereld open staat, je hebt zo volledige controlle over wie de stream te zien krijgt.

Overigens even een status update, ik ben met de signals aan de gang gegaan van willemjoosten, wat inderdaad een oplossing bleek (waarvoor dank!), de stream wordt nu ten alle tijden netjes afgesloten. Wel nog een ander probleem erbij gekomen, het blijkt dat FFmpeg op zijn tijd moeite heeft met de stream uit te lezen. Begint dan wat foutmeldingen te genereren waarna het een lange tijd duurt voor de stream uiteindelijk echt gestart wordt.

code:
1
2
3
4
5
6
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq 750d expected=c560
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq 6d13 expected=751e
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq c560 expected=6d24
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq 751e expected=c571
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq 6d24 expected=7520
[NULL @ 0x7f281eadf330]RTP: PT=60: bad cseq c571 expected=6d26


Etc etc.

Nu had ik nog geprobeerd om ipv de RTSP stream de MJPEG variant uit te lezen. Deze heeft dit probleem niet, maar hierbij ontstaan er weer enorme vertragingen (1 seconden beeld duurt zeg maar 3 seconden). Ik vermoed dat MJPEG gewoon teveel data is om realtime te verwerken.

code:
1
2
3
4
5
#MJPEG
/usr/bin/ffmpeg -er 4 -y -r 10 -qmin 7 -qmax 9 -s 320x240 -an -f mjpeg -vglobal 2 -i http://192.168.1.165/axis-cgi/mjpg/video.cgi -f flv - 2> /dev/null

#RTSP
/usr/bin/ffmpeg -er 4 -y -r 10 -qmin 7 -qmax 9 -s 320x240 -an -f rtsp -vglobal 2 -i rtsp://192.168.1.165:554/mpeg4/media.amp -f flv - 2> /dev/null


Overigens dat idee van Docey staat me ook zeker aan, die houd ik even achter de hand voor mocht dit echt niets gaan worden. Voor nu ben ik nog even verder aan het stoeien met de scriptjes en ffmpeg finetunen, maar mocht dat echt op niets gaan uitdraaien ga ik daar verder mee.

Acties:
  • 0 Henk 'm!

  • HaBl
  • Registratie: November 2003
  • Laatst online: 28-04 09:57
Mensen, nog even een bedankje naar een ieder voor het mee denken, het probleem is inmiddels opgelost.

Heb het kunnen oplossen dmv het perl scriptje, inderdaad met signals zoals door willemjoosten aangegeven. Verder moesten er in de camera zelf wat instellingen veranderd worden zodat ffmpeg minder te doen had (voornamelijk framerate gelijk trekken aan de output van ffmpeg).

Hier het scriptje (nog niet helemaal uitgewerkt, maar wel werkend):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/usr/bin/perl -wT

$| = 1;

$SIG{'PIPE'} = sub {
        die "Stream beëindigd.";
};

$SIG{'CHLD'} = sub {
        die "Strean beëindigd.";
};


local $ENV{"PATH"} = "/bin:/usr/local/bin:/usr/bin";
local $ENV{"BASH_ENV"}="";

print "Pragma: no-cache\n";
print "Content-type: video/x-flv\n\n";

system("/usr/bin/ffmpeg -er 4 -y -r 10 -qmin 1 -qmax 3 -s 320x240 -an -f mjpeg -vglobal 2 -i http://192.168.1.165/axis-cgi/mjpg/video.cgi -f flv - 2> /dev/null");


Mocht er iemand zijn die dit wil gebruiken, houd er dan rekening mee dat voor een goeie werking in een flashplayer, het cgi bestand een .flv extentie moet hebben. In IE accepteerd ie geen .cgi namelijk. Dus een apache handler aanmaken hiervoor lost dat probleem op.

code:
1
AddHandler cgi-script .cgi .flv

Acties:
  • 0 Henk 'm!

  • Borizz
  • Registratie: Maart 2005
  • Laatst online: 24-08 20:35
HaBl schreef op zondag 16 augustus 2009 @ 23:23:
...

Mocht er iemand zijn die dit wil gebruiken, houd er dan rekening mee dat voor een goeie werking in een flashplayer, het cgi bestand een .flv extentie moet hebben. In IE accepteerd ie geen .cgi namelijk. Dus een apache handler aanmaken hiervoor lost dat probleem op.

code:
1
AddHandler cgi-script .cgi .flv
Het lijkt me beter om dit (bijvoorbeeld) met mod rewrite op te lossen i.p.v. alle bestanden met een .flv extensie door je cgi script af te laten handelen.

Als voorbeeld .htaccess in de betreffend directory:
code:
1
2
RewriteEngine On
RewriteRule ^filename.flv filename.cgi


Daarnaast kan je met de Content-Disposition header ook een filename meesturen.

If I can't fix it, it ain't broken.


Acties:
  • 0 Henk 'm!

  • alienfruit
  • Registratie: Maart 2003
  • Laatst online: 14:07

alienfruit

the alien you never expected

Volgens mij kijkt de flash player met name naar de mimetype en niet de extensie.

Acties:
  • 0 Henk 'm!

Verwijderd

Maar nu heb je toch weer een ffmpeg instance per request draaien?

Daarnaast kun je die AddHandler ook direct in een .htaccess zetten dacht ik. Wel zo veilig.
Pagina: 1