
Recherche avancée
Médias (21)
-
1,000,000
27 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Demon Seed
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
The Four of Us are Dying
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Corona Radiata
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Lights in the Sky
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Head Down
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
Autres articles (51)
-
HTML5 audio and video support
13 avril 2011, parMediaSPIP 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 (...) -
Support audio et vidéo HTML5
10 avril 2011MediaSPIP 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 (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe 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 (9690)
-
.mpd deleted after played
18 novembre 2020, par thxboxI would like to stream mp4 file with .mpd file. I installed MP4Box to convert mp4 to .mpd file, with this command


P4Box -dash 4000 -frag 4000 -dash-profile onDemand -segment-name out-seg -time-shift -1 -out prev_video.mpd prev_video.mp4



on my Ubuntu server


I also use nginx-rtmp-module to do video streaming.


My problem is after I play .mpd file with VLC Player then .mpd file was auto deleted.
so question is, is it possible to keep .mpd in my server ? or I miss some configuration while convert .mp4 to .mpd with MP4Box


Thank


-
webmdashenc : Fix UTCTiming Element
28 avril 2015, par Vignesh Venkatasubramanianwebmdashenc : Fix UTCTiming Element
Remove the direct profile from UTCTiming element. Per DASH spec,
direct profile value should be the time at which the request was
made to the server and not the time at which the manifest was
written. So ffmpeg cannot write this value. This patch removes
the direct profile and write the UTCTiming element with the http
profile only if a URL is passed as a parameter. Update the fate
test to reflect this change.Signed-off-by : Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by : Michael Niedermayer <michaelni@gmx.at> -
How to encode a video from several images generated in a C++ program without writing the separate frame images to disk ?
5 mai 2021, par ksb496I am writing a C++ code where a sequence of N different frames is generated after performing some operations implemented therein. After each frame is completed, I write it on the disk as IMG_%d.png, and finally I encode them to a video through ffmpeg using the x264 codec.



The summarized pseudocode of the main part of the program is the following one :



std::vector<int> B(width*height*3);
for (i=0; i/ void generateframe(std::vector<int> &, int)
 generateframe(B, i); // Returns different images for different i values.
 sprintf(s, "IMG_%d.png", i+1);
 WriteToDisk(B, s); // void WriteToDisk(std::vector<int>, char[])
}
</int></int></int>



The problem of this implementation is that the number of desired frames, N, is usually high (N 100000) as well as the resolution of the pictures (1920x1080), resulting into an overload of the disk, producing write cycles of dozens of GB after each execution.



In order to avoid this, I have been trying to find documentation about parsing directly each image stored in the vector B to an encoder such as x264 (without having to write the intermediate image files to the disk). Albeit some interesting topics were found, none of them solved specifically what I exactly want to, as many of them concern the execution of the encoder with existing images files on the disk, whilst others provide solutions for other programming languages such as Python (here you can find a fully satisfactory solution for that platform).



The pseudocode of what I would like to obtain is something similar to this :



std::vector<int> B(width*height*3);
video_file=open_video("Generated_Video.mp4", ...[encoder options]...);
for (i=0; icode></int>



According to what I have read on related topics, the x264 C++ API might be able to do this, but, as stated above, I did not find a satisfactory answer for my specific question. I tried learning and using directly the ffmpeg source code, but both its low ease of use and compilation issues forced me to discard this possibility as a mere non-professional programmer I am (I take it as just as a hobby and unluckily I cannot waste that many time learning something so demanding).



Another possible solution that came to my mind is to find a way to call the ffmpeg binary file in the C++ code, and somehow manage to transfer the image data of each iteration (stored in B) to the encoder, letting the addition of each frame (that is, not "closing" the video file to write) until the last frame, so that more frames can be added until reaching the N-th one, where the video file will be "closed". In other words, call ffmpeg.exe through the C++ program to write the first frame to a video, but make the encoder "wait" for more frames. Then call again ffmpeg to add the second frame and make the encoder "wait" again for more frames, and so on until reaching the last frame, where the video will be finished. However, I do not know how to proceed or if it is actually possible.



Edit 1 :



As suggested in the replies, I have been documenting about named pipes and tried to use them in my code. First of all, it should be remarked that I am working with Cygwin, so my named pipes are created as they would be created under Linux. The modified pseudocode I used (including the corresponding system libraries) is the following one :



FILE *fd;
mkfifo("myfifo", 0666);

for (i=0; i/ void WriteToPipe(std::vector<int>, FILE *&fd)
 fflush(fd);
 fd=fclose("myfifo");
}
unlink("myfifo");
</int>



WriteToPipe is a slight modification of the previous WriteToFile function, where I made sure that the write buffer to send the image data is small enough to fit the pipe buffering limitations.



Then I compile and write the following command in the Cygwin terminal :



./myprogram | ffmpeg -i pipe:myfifo -c:v libx264 -preset slow -crf 20 Video.mp4




However, it remains stuck at the loop when i=0 at the "fopen" line (that is, the first fopen call). If I had not called ffmpeg it would be natural as the server (my program) would be waiting for a client program to connect to the "other side" of the pipe, but it is not the case. It looks like they cannot be connected through the pipe somehow, but I have not been able to find further documentation in order to overcome this issue. Any suggestion ?