Recherche avancée

Médias (2)

Mot : - Tags -/map

Autres articles (36)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (6437)

  • Is Java fast enough to do live screensharing ?

    10 mars 2012, par user1260501

    For the past few months, a developer and I have been working on a screensharing applet that streams to a media server like Wowza or Red5, but no matter what we do, we have about 5 seconds of latency, which is too long for a live application where people are interacting with each other. We've tried xuggle, different encoders, different players, different networks, different media servers, and even streaming locally, there's significant latency.

    So, I'm beginning to wonder…

    Is Java fast enough to do live screensharing ?

    I've seen lots of screen recording applets written in Java, but none of them are streaming live. Everything that's done live, such as GoToMeeting, seems to use C++. I'm thinking maybe there's a reason.

    It's not a compression problem. Using ScreenVideo, we've compressed an hour-long stream down to about 100 MB, and we have plenty of bandwidth. The processor isn't overloaded doing the compression, either, but it seems to be taking too much time. We are getting the best results from some code pulled out of BigBlueButton, but still, the latency is terrible.

    Streaming the WebCam, on the other hand, is nice and snappy. Almost no latency at all. So, the problem is the applet.

    The only other idea I can think of is somehow emulating a WebCam with Java. Not sure if that would be faster or not.

    Ideas ? Or should I just give up on Java and do this in C++ ? I would hate to do that, because then I would have to create different versions for different platforms, but if it's the only way, it's the only way.

  • Generating 64kbps audio-only mpegts for HTTP Live segmenter to meept 64kbps audio only requirement

    23 avril 2012, par Pobre

    I am trying to convert our mp4 files into mpeg-ts and segment it into .ts files for my iphone app to play. I am using Carson McDonalds's HTTP-Live-Video-Stream-Segmenter-and-Distributor to do that.

    I got his stuff complied and working correctly. I am currently trying to meet Apple's requirement where I need to provide a baseline 64 kbps audio only stream to my m3u8 playlist.
    Carson doesn't seem to have a profile for that.

    I need to be able to generate 64kbps audio-only stream from mp4, and turn that into mpeg-ts for the segmenter into ts. I am trying to find the right ffmpeg command that will validate without problem using Apple's mediastreamvalidator.

    So far I modified an existing encoding profile to try to achieve 64kbps total :

    ffmpeg -er 4 -i %s -f mpegts -acodec libmp3lame -ar 22050 -ab 32k -s 240x180 -vcodec libx264 -b 16k -flags +loop+mv4 -cmp 256 -partitions +parti4x4+partp8x8+partb8x8 -subq 7 -trellis 1 -refs 5 -coder 0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 64k -maxrate 16k -bufsize 16k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 4:3 -r 10 -g 30 -async 2 - | %s %s %s %s %s

    but then when I try to validate it using mediastreamvalidator, it gives error after few ts :

    Playlist Validation : OK

    Segments :

    sample_cell_4x3_64k-00001.ts :

    WARNING : Media segment exceeds target duration of 10.00 seconds by 1.30 seconds (segment duration is 11.30 seconds)

    sample_cell_4x3_64k-00002.ts :

    WARNING : Media segment exceeds target duration of 10.00 seconds by 1.40 seconds (segment duration is 11.40 seconds)

    ....
    ....

    sample_cell_4x3_64k-00006.ts :

    ERROR : (-1) Unknown video codec : 1836069494 (program 0, track 0)
    ERROR : (-1) failed to parse segment as either an MPEG-2 TS or an ES

    sample_cell_4x3_64k-00007.ts :

    ERROR : (-1) Unknown video codec : 1836069494 (program 0, track 0)
    ERROR : (-1) failed to parse segment as either an MPEG-2 TS or an ES

    ....
    ....
    Average segment duration : 10.26 seconds
    Average segment bitrate : 376797.92 bps
    Average segment structural overhead : 349242.17 bps (92.69 %)

    Is there someway I can generate this correctly with just audio which totals 64kbps and turn it into mpeg-ts ready to be segmented and validated correctly ?

    Am I approaching the problem right ?

  • Removed use of $.live().

    29 novembre 2012, par jackmoore

    m colorbox/jquery.colorbox.js Removed use of $.live().