Recherche avancée

Sur d’autres sites (10828)

• avcodec/xbmenc : Allow for making UW images

  19 janvier 2021, par Jose Da Silva

  avcodec/xbmenc : Allow for making UW images
  I've run into some bugs where I was downloading a bunch of data and began
  
  seeing weird hiccups. For example, javascript promises to allow you to push
  
  some very long lines of data, but the hiccups I saw was with data larger
  
  than 2k in length (windows) pushed out of a child process stdout piped into
  
  the stdin of the calling parent program.
  
  Soo much for smooth promises, this was broken and would run into similar
  
  problems on a linux PC with 32k line limits.
  
  The solution was to break the data into smaller chunks than 2k - and then
  
  these data hiccups disappeared (windows PC).
  It would be expected to be similar for linux PCs (32k I think) and other
  
  OSes with different sizes.
  If the ANSI required minimum needs to be 509 chars or larger (assuming
  
  509+<CR>+<LF>+<0>=512), then 509 was chosen as the shortest worst-case
  
  scenario) in this patch.
  
  Most small pictures will go output looking pretty much the same data out
  
  until you get to about 84bytes (672 pixels wide), where lines out begin to
  
  be split. For example a UW 4K will exceed a 2k readln and a UW 10K picture
  
  approaches an 8k readln
  The purpose for this patch is to ensure that data remains below the
  
  readline limits (of 509 chars), so that programs (like javascript) can push
  
  data in large chunks without breaking into hiccups because the data length
  
  is too long to be pushed cleanly in one go.
  
  Subject : [PATCH 3/3] avcodec/xbmenc : Allow for making UW images
  Worst-case ANSI must allow for 509 chars, while Windows allows for 2048
  
  and Linux for 32K line length. This allows an OS with a small readline
  
  access limitation to fetch very wide images (created from ffmpeg).
  

  • [DH] libavcodec/xbmenc.c

• How do you run ffmpeg from Java, without crashing ?

  30 juin 2024, par WinnieTheDampoeh

  I 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 amfast

  I'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 segmentation part of ffmpeg does create 100ms segments and save them to disk immediately, but the strftime 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 ?