
Recherche avancée
Médias (2)
-
Granite de l’Aber Ildut
9 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
-
Géodiversité
9 septembre 2011, par ,
Mis à jour : Août 2018
Langue : français
Type : Texte
Autres articles (95)
-
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...) -
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Submit bugs and patches
13 avril 2011Unfortunately a software is never perfect.
If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
You may also (...)
Sur d’autres sites (6329)
-
How do you run ffmpeg from Java, without crashing ?
30 juin 2024, par WinnieTheDampoehI try running ffmpeg from Java, and for a couple of moments everything is working fine. I want ffmpeg to record my screen, and split the recording into small clips. The command is working fine from the terminal, but when I run it from Java I get at most 3 clips. Ffmpeg doesn't write anything to the InputStream, so I have no idea what's going wrong.


public static void execute(int frameRate, int width, int height, String windowTitle) {
 String[] args = new String[]{
 path,
 "-hide_banner",
 "-f", "gdigrab",
 "-thread_queue_size", "1024",
 "-rtbufsize", "256M",
 "-framerate", "" + frameRate,
 "-offset_x", "0",
 "-offset_y", "0",
 "-video_size", "" + width + "x" + height,
 "-draw_mouse", "1",
 "-i", "title=" + windowTitle,
 "-c:v", "libx264",
 "-r", "" + frameRate,
 "-preset", "ultrafast",
 "-tune", "zerolatency",
 "-crf", "28",
 "-pix_fmt", "yuv420p",
 "-movflags", "+faststart",
 "-y",
 "-f", "segment",
 "-reset_timestamps", "1",
 "-segment_time", "1",
 "output%06d.mp4"
 };

 try {
 Process p = Runtime.getRuntime().exec(args);
 Thread thread = new Thread(() -> {
 String line;
 BufferedReader input = new BufferedReader(new InputStreamReader(p.getInputStream()));

 System.out.println("TEST");
 try {
 while ((line = input.readLine()) != null)
 System.out.println(line);

 System.out.println("Stopping with reading");
 input.close();
 } catch (IOException e) {
 e.printStackTrace();
 }
 });
 int exitCode = p.waitFor();
 thread.start();
 thread.join();
 if (exitCode != 0) {
 throw new RuntimeException("FFmpeg exited with code " + exitCode);
 }
 } catch (IOException | InterruptedException e) {
 throw new RuntimeException(e);
 }
 }



I've run the same command in the terminal. That worked fine. I ran the code above, but that resulted in ffmpeg stopping after 3 clips. It kept showing as working from the task manager. As said before, ffmpeg doesn't write anything to the InputStream, even though it normally does write a lot in the terminal. The weird thing is, when I stop my Java program, but accidentally keep ffmpeg running, it suddenly does everything I wanted it to. It didn't capture the things between stopping and closing Java, but after that it continues like it should have.


-
How to save ffmpeg segmets to disk immediately with sub-second intervals ?
20 octobre 2023, par amfastI'm trying to record video on a raspberry and have it save as much as possible (sub-second resolution) in case of a power cutoff.


I use
-f segment
to save the encoded stream in 100ms segments with the hope that all but the interrupted (by power cutoff) segment will be saved in memory. Unfortunately, when cutting off power, all the destination files (output_0001.mp4, output_0002.mp4, ...) are created, but empty.

To save the files to disk immediately, I added the
-strftime 1
option that allows formatting the output filename as time. It seems weird that this is the (only ?) way to trigger immediate saving of files, but it works - untill I try to have segments smaller than 1 second. The problem seems to be that the format string%d
, that previously added a sequence number in my output filenames, now represents "day" (i.e. date) and the smallest resolution time format string is%S
for second. I saw%f
suggested somewhere for smaller resolutions, but it only prints "%f".

The result is that the
segment
ation part of ffmpeg does create 100ms segments and save them to disk immediately, but thestrftime
feature gives the output files names that only change every second, so all the interim files are overwritten.

Example of the failing command below. Without the
-strftime
option this creates nice segments, but does not save them to disk immediately.

libcamera-vid --flush \
 --framerate ${FRAMERATE} \
 --width ${WIDTH} \
 --height ${HEIGHT} \
 -n \
 -t ${TIMEOUT} \
 --codec yuv420 \
 -o - | 
ffmpeg \
 -fflags nobuffer \
 -strict experimental \
 -loglevel debug \
 -flags low_delay \
 -f rawvideo \
 -pix_fmt yuv420p \
 -s:v ${WIDTH}x${HEIGHT} \
 -r ${FRAMERATE} \
 -i - \
 -c:v h264_v4l2m2m \
 -f segment \
 -segment_time 0.1 \
 -segment_format mp4 \
 -reset_timestamps 1 \
 -strftime 1 \
 -b:v ${ENCODING_BITRATE} \
 -g 1 \
 "output_%04d.mp4"



Question :

Is there another way besides-strftime
to trigger immediate saving ? Or is there a mechanism to feed finer resolution format strings to the output filename ?

-
FFMPEG : Multicast packets incoming, but input stream does not open
2 septembre 2022, par oldslowI have a weird problem with ffmpeg and I was wondering if someone might know what's going on.


We have transcoding clusters outputting video to a multicast network. In some computers of the same network, I'm able to open these streams with a command like :


ffplay -i "udp://239.{mutlticast address}:10001?localaddr={Local adapter IP which receives packets}" -nodisp -loglevel trace


But in other computers it does not work. Particularly in a server running Centos 7 I just get :


[NULL @ 0x7fc9a4000920] Opening 'udp://239.xxx.xxx.xxx:10001?localaddr=xxx.xxx.xxx.xxx' for reading
[udp @ 0x7fc9a40012a0] No default whitelist set 
[udp @ 0x7fc9a40012a0] end receive buffer size reported is 131072
nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0



I was thinking it might be a network problem. I started Wireshark to see if the packets were coming in and the thing is, they are ! As soon as I start FFMpeg/FFplay, the MPEG TS packets start coming in, but still FFMpeg won't open the stream :


1067 1.897872161 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 51718 Destination port: scp-config
1068 1.898576050 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 40892 Destination port: documentum-s[Malformed Packet]
1069 1.900472740 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 37505 Destination port: documentum
1070 1.901850051 192.168.194.92 -> PTS 30268.882311111 MPEG TS 1358 video-stream
1071 1.903688205 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1072 1.905842200 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 51718 Destination port: scp-config
1073 1.906249539 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1074 1.909831587 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 51718 Destination port: scp-config
1075 1.911357251 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1076 1.912000106 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1077 1.913819520 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1078 1.917778444 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 Source port: 37505 Destination port: documentum
1079 1.917802429 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet
1080 1.920473981 192.168.194.92 -> 239.193.2.221 MPEG TS 1358 NULL packet



Anyone have any idea what can I do to fix this ?
Thanks a lot !