Sur d’autres sites (7114)

• ffmpeg Command in Docker with Rust Tokio Closes Warp Server Connection (curl 52 Error)

  3 juin 2024, par user762345

  I’m encountering an issue where executing an ffmpeg concatenation command through Rust’s Tokio process in a Docker container causes subsequent HTTP requests to fail. The error occurs exclusively after running the ffmpeg command and making immediate requests, resulting in a “curl 52 empty response from server” error with the connection being closed. Notably, this issue does not occur when running the same setup outside of Docker. Additionally, if no HTTP requests are made after the ffmpeg command, the curl 52 error does not occur.

  


  Here is the verbose curl output of my minimum reproducible example (see below).

  


  curl -v "http://localhost:3030"
*   Trying 127.0.0.1:3030...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> GET / HTTP/1.1
> Host: localhost:3030
> User-Agent: curl/8.1.2
> Accept: */*
> 
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server


  


  Here are Docker logs from my minimum reproducible example (see below). The wav files are concatenated successfully, then the container appears to rebuild.

  


  [2024-06-03T05:26:58Z INFO  minimal_docker_webserver_post_error] Starting server on 0.0.0.0:3030
[2024-06-03T05:26:58Z INFO  warp::server] Server::run; addr=0.0.0.0:3030
[2024-06-03T05:26:58Z INFO  warp::server] listening on http://0.0.0.0:3030
[2024-06-03T05:27:07Z INFO  minimal_docker_webserver_post_error] WAV files concatenated successfully
[Running 'cargo run']
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/minimal_docker_webserver_post_error`
[2024-06-03T05:27:08Z INFO  minimal_docker_webserver_post_error] Starting server on 0.0.0.0:3030
[2024-06-03T05:27:08Z INFO  warp::server] Server::run; addr=0.0.0.0:3030
[2024-06-03T05:27:08Z INFO  warp::server] listening on http://0.0.0.0:3030


  


  What I have tried :
I tried using different web frameworks (Warp, Actix-web) and request crates (reqwest, ureq). I also tried running the setup outside of Docker, which worked as expected without any issues. Additionally, I tried running the setup in Docker without making any HTTP requests after the ffmpeg command, and the connection closed successfully without errors. I also tried posting to httpbin with a minimal request, but the issue persisted.

  


  Minimum reproducible example :

  


  main.rs

  


  use warp::Filter;&#xA;use reqwest::Client;&#xA;use std::convert::Infallible;&#xA;use log::{info, error};&#xA;use env_logger;&#xA;use tokio::process::Command;&#xA;&#xA;#[tokio::main]&#xA;async fn main() {&#xA;    std::env::set_var("RUST_LOG", "debug");&#xA;    env_logger::init();&#xA;&#xA;    let route = warp::path::end()&#xA;        .and_then(handle_request);&#xA;&#xA;    info!("Starting server on 0.0.0.0:3030");&#xA;    warp::serve(route)&#xA;        .run(([0, 0, 0, 0], 3030))&#xA;        .await;&#xA;}&#xA;&#xA;async fn handle_request() -> Result<impl infallible="infallible"> {&#xA;    let client = Client::new();&#xA;&#xA;    let output = Command::new("ffmpeg")&#xA;        .args(&amp;[&#xA;            "y",&#xA;            "-i", "concat:/usr/src/minimal_docker_webserver_post_error/file1.wav|/usr/src/minimal_docker_webserver_post_error/file2.wav",&#xA;            "-c", "copy",&#xA;            "/usr/src/minimal_docker_webserver_post_error/combined.wav"&#xA;        ])&#xA;        .output()&#xA;        .await;&#xA;&#xA;    match output {&#xA;        Ok(output) => {&#xA;            if output.status.success() {&#xA;                info!("WAV files concatenated successfully");&#xA;            } else {&#xA;                error!("Failed to concatenate WAV files: {:?}", output);&#xA;                return Ok(warp::reply::with_status("Failed to concatenate WAV files", warp::http::StatusCode::INTERNAL_SERVER_ERROR));&#xA;            }&#xA;        },&#xA;        Err(e) => {&#xA;            error!("Failed to execute ffmpeg: {:?}", e);&#xA;            return Ok(warp::reply::with_status("Failed to execute ffmpeg", warp::http::StatusCode::INTERNAL_SERVER_ERROR));&#xA;        }&#xA;    }&#xA;&#xA;    // ISSUE: Connection closes with curl: (52) Empty reply from server&#xA;    match client.get("https://httpbin.org/get").send().await {&#xA;        Ok(response) => info!("GET request successful: {:?}", response),&#xA;        Err(e) => error!("GET request failed: {:?}", e),&#xA;    }&#xA;&#xA;    match client.post("https://httpbin.org/post")&#xA;        .body("field1=value1&amp;field2=value2")&#xA;        .send().await {&#xA;        Ok(response) => info!("POST request successful: {:?}", response),&#xA;        Err(e) => error!("POST request failed: {:?}", e),&#xA;    }&#xA;&#xA;    Ok(warp::reply::with_status("Request handled", warp::http::StatusCode::OK))&#xA;}&#xA;</impl>

  


  FFMPEG command to generate the two wav files for concatenation

  


  ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" file1.wav && ffmpeg -f lavfi -i "sine=frequency=500:duration=5" file2.wav


  


  Dockerfile

  


  # Use the official Rust image as the base image
FROM rust:latest

# Install cargo-watch
RUN cargo install cargo-watch

# Install ffmpeg
RUN apt-get update && apt-get install -y ffmpeg

# Set the working directory inside the container
WORKDIR /usr/src/minimal_docker_webserver_post_error

# Copy the Cargo.toml and Cargo.lock files
COPY Cargo.toml Cargo.lock ./

# Copy the source code
COPY src ./src

# Copy wav files
COPY file1.wav /usr/src/minimal_docker_webserver_post_error/file1.wav
COPY file2.wav /usr/src/minimal_docker_webserver_post_error/file2.wav

# Install dependencies
RUN cargo build --release

# Expose the port that the application will run on
EXPOSE 3030

# Set the entry point to use cargo-watch
CMD ["cargo", "watch", "-x", "run"]


  


  Cargo.toml

  


  [package]
name = "minimal_docker_webserver_post_error"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
warp = "0.3"
reqwest = { version = "0.12.4", features = ["json"] }
tokio = { version = "1", features = ["full"] }
log = "0.4"
env_logger = "0.11.3"


  


  Making the request to the warp server

  


  curl -v "http://localhost:3030"


  


• Using libav to encode RGBA frames into MP4 but the output is a mess

  5 octobre 2019, par Cu2S

  I’m trying to decode a video into RGB frames, and then postprocess the frames, finally encode the frames into a video. But the output video is completely a mess :
  

  I wrote a minimal example to illustrate my idea. First, I read some information from some source video :

      AVFormatContext* inputFormatCtx = nullptr;
  
      int ret = avformat_open_input(&inputFormatCtx, inputParamsVideo, nullptr, nullptr);
  
      assert(ret >= 0);
  
      ret = avformat_find_stream_info(inputFormatCtx, NULL);
  
      av_dump_format(inputFormatCtx, 0, inputParamsVideo, 0);
  
  
  
      assert(ret >= 0);
  
      AVStream* inputVideoStream = nullptr;
  
      for (int i = 0; i < inputFormatCtx->nb_streams; i++)
  
      {
  
          const auto inputStream = inputFormatCtx->streams[i];
  
          if (inputStream->codec->codec_type == AVMEDIA_TYPE_VIDEO)
  
          {
  
              inputVideoStream = inputStream;
  
              break;
  
          }
  
      }
  
  
  
      assert(inputVideoStream != nullptr);
  
      AVCodecParameters* inputParams = inputVideoStream->codecpar;
  
      AVRational framerate = inputVideoStream->codec->framerate;
  
      auto gop_size = inputVideoStream->codec->gop_size;
  
      auto maxBFrames = inputVideoStream->codec->max_b_frames;

  Then I assign the information to the output stream :

  AVFormatContext *outputAVFormat = nullptr;
  
  avformat_alloc_output_context2(&outputAVFormat, nullptr, nullptr, kOutputPath);
  
  assert(outputAVFormat);
  
  AVCodec* codec = avcodec_find_encoder(outputAVFormat->oformat->video_codec);
  
  assert(codec);
  
  AVCodecContext* encodingCtx = avcodec_alloc_context3(codec);
  
  avcodec_parameters_to_context(encodingCtx, inputParams);
  
  encodingCtx->time_base = av_inv_q(framerate);
  
  encodingCtx->max_b_frames = maxBFrames;
  
  encodingCtx->gop_size = gop_size;
  
  
  
  
  
  if (outputAVFormat->oformat->flags & AVFMT_GLOBALHEADER)
  
      encodingCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
  
  AVStream* outStream = avformat_new_stream(outputAVFormat, nullptr);
  
  assert(outStream != nullptr);
  
  ret = avcodec_parameters_from_context(outStream->codecpar, encodingCtx);
  
  assert(ret >= 0);
  
  outStream->time_base = encodingCtx->time_base;

  Then I convert RGBA frames(which is read from files) into YUV420P via sws_scale, and encoding :

      ret = avcodec_open2(encodingCtx, codec, nullptr);
  
      assert(ret >= 0);
  
      av_dump_format(outputAVFormat, 0, kOutputPath, 1);
  
  
  
      ret = avio_open(&outputAVFormat->pb, kOutputPath, AVIO_FLAG_WRITE);
  
      assert(ret >= 0);
  
      ret = avformat_write_header(outputAVFormat, nullptr);
  
      assert(ret >= 0);
  
  
  
      AVFrame* frame = av_frame_alloc();
  
      frame->width = inputParams->width;
  
      frame->height = inputParams->height;
  
      frame->format = inputParams->format;
  
      frame->pts = 0;
  
      assert(ret >= 0);
  
  
  
      ret = av_frame_get_buffer(frame, 32);
  
      int frameCount = 0;
  
      assert(ret >= 0);
  
      ret = av_frame_make_writable(frame);
  
      assert(ret >= 0);
  
      SwsContext* swsContext = sws_getContext(inputParams->width, inputParams->height,
  
          AV_PIX_FMT_RGBA, frame->width,
  
          frame->height, static_cast<avpixelformat>(inputParams->format),
  
          SWS_BILINEAR, NULL, NULL, NULL);
  
  
  
  
  
      for (auto inputPicPath : std::filesystem::directory_iterator(kInputDir))
  
      {
  
          int width, height, comp;
  
          unsigned char* data = stbi_load(inputPicPath.path().string().c_str(), &amp;width, &amp;height, &amp;comp, 4);
  
          int srcStrides[1] = { 4 * width };
  
          int ret = sws_scale(swsContext, &amp;data, srcStrides, 0, height, frame->data,
  
              frame->linesize);
  
          assert(ret >= 0);
  
          frame->pts = frameCount;
  
          //frame->pict_type = AV_PICTURE_TYPE_I;
  
          frameCount += 1;
  
          encode(encodingCtx, frame, 0, outputAVFormat);
  
  
  
          stbi_image_free(data);
  
      }
  
  
  
      while (encode(encodingCtx, nullptr, 0, outputAVFormat))
  
      {
  
          ;
  
      }
  
  
  
      static bool encode(AVCodecContext* enc_ctx, AVFrame* frame, std::uint32_t streamIndex,
  
          AVFormatContext * formatCtx)
  
      {
  
          int ret;
  
          int got_output = 0;
  
          AVPacket packet = {};
  
          av_init_packet(&amp;packet);
  
          ret = avcodec_encode_video2(enc_ctx, &amp;packet, frame, &amp;got_output);
  
          assert(ret >= 0);
  
          if (got_output) {
  
              packet.stream_index = streamIndex;
  
              av_packet_rescale_ts(&amp;packet, enc_ctx->time_base, formatCtx->streams[streamIndex]->time_base);
  
              ret = av_interleaved_write_frame(formatCtx, &amp;packet);
  
              assert(ret >= 0);
  
              return true;
  
          }
  
          else {
  
              return false;
  
          }
  
      }
  
  </avpixelformat>

  Finally I cleaned up stuff :

      av_write_trailer(outputAVFormat);
  
      sws_freeContext(swsContext);
  
      avcodec_free_context(&encodingCtx);
  
      avio_closep(&outputAVFormat->pb);
  
      avformat_free_context(outputAVFormat);
  
      av_frame_free(&frame);

  I dumped my input format and my output format :

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'H:\Me.MP4':
  
    Metadata:
  
      major_brand     : mp42
  
      minor_version   : 1
  
      compatible_brands: mp41mp42isom
  
      creation_time   : 2019-04-03T05:44:22.000000Z
  
    Duration: 00:00:06.90, start: 0.000000, bitrate: 1268 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 540x960, 1238 kb/s, 29.86 fps, 30 tbr, 600 tbn, 1200 tbc (default)
  
      Metadata:
  
        creation_time   : 2019-04-03T05:44:22.000000Z
  
        handler_name    : Core Media Video
  
      Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 8000 Hz, stereo, fltp, 24 kb/s (default)
  
      Metadata:
  
        creation_time   : 2019-04-03T05:44:22.000000Z
  
        handler_name    : Core Media Audio
  
  [libx264 @ 000002126F90C1C0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
  
  [libx264 @ 000002126F90C1C0] profile High, level 3.1, 4:2:0, 8-bit
  
  [libx264 @ 000002126F90C1C0] 264 - core 157 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=12 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=12 rc=abr mbtree=1 bitrate=1238 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to './output.mp4':
  
      Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 540x960, q=2-31, 1238 kb/s, 29.86 tbn

  Update :

  After I deleted

  encodingCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;

  the output video is right. Also, outputting avi works, too.

• Hacking the Popcorn Hour C-200

  3 mai 2010, par Mans — Hardware, MIPS

  Update : A new firmware version has been released since the publication of this article. I do not know if the procedure described below will work with the new version.

  The Popcorn Hour C-200 is a Linux-based media player with impressive specifications. At its heart is a Sigma Designs SMP8643 system on chip with a 667MHz MIPS 74Kf as main CPU, several co-processors, and 512MB of DRAM attached. Gigabit Ethernet, SATA, and USB provide connectivity with the world around it. With a modest $299 on the price tag, the temptation to repurpose the unit as a low-power server or cheap development board is hard to resist. This article shows how such a conversion can be achieved.
  

  Kernel

  The PCH runs a patched Linux 2.6.22.19 kernel. A source tarball is available from the manufacturer. This contains the sources with Sigma support patches, Con Kolivas’ patch set (scheduler tweaks), and assorted unrelated changes. Properly split patches are unfortunately not available. I have created a reduced patch against vanilla 2.6.22.19 with only Sigma-specific changes, available here.

  The installed kernel has a number of features disabled, notably PTY support and oprofile. We will use kexec to load a more friendly one.

  As might be expected, the PCH kernel does not have kexec support enabled. It does however, by virtue of using closed-source components, support module loading. This lets us turn kexec into a module and load it. A patch for this is available here. To build the module, apply the patch to the PCH sources and build using this configuration. This will produce two modules, kexec.ko and mips_kexec.ko. No other products of this build will be needed.

  The replacement kernel can be built from the PCH sources or, if one prefers, from vanilla 2.6.22.19 with the Sigma-only patch. For the latter case, this config provides a minimal starting point suitable for NFS-root.

  When configuring the kernel, make sure CONFIG_TANGOX_IGNORE_CMDLINE is enabled. Otherwise the command line will be overridden by a useless one stored in flash. A good command line can be set with CONFIG_CMDLINE (under “Kernel hacking” in menuconfig) or passed from kexec.

  Taking control

  In order to load our kexec module, we must first gain root privileges on the PCH, and here a few features of the system are working to our advantage :

  1. The PCH allows mounting any NFS export to access media files stored there.
  2. There is an HTTP server running. As root.
  3. This HTTP server can be readily instructed to fetch files from an NFS mount.
  4. Files with a name ending in .cgi are executed. As root.

  All we need do to profit from this is place the kexec modules, the kexec userspace tools, and a simple script on an NFS export. Once this is done, and the mount point configured on the PCH, a simple HTTP request will send the old kernel screaming to /dev/null, our shiny new kernel taking its place.

  The rootfs

  A kernel is mostly useless without a root filesystem containing tools and applications. A number of tools for cross-compiling a full system exist, each with its strengths and weaknesses. The only thing to look out for is the version of kernel headers used (usually a linux-headers package). As we will be running an old kernel, chances are the default version is too recent. Other than this, everything should be by the book.

  Assembling the parts

  Having gathered all the pieces, it is now time to assemble the hack. The following steps are suitable for an NFS-root system. Adaptation to a disk-based system is left as an exercise.

  1. Build a rootfs for MIPS 74Kf little endian. Make sure kernel headers used are no more recent than 2.6.22.x. Include a recent version of the kexec userspace tools.
  2. Fetch and unpack the PCH kernel sources.
  3. Apply the modular kexec patch.
  4. Using this config, build the modules and install them as usual to the rootfs. The version string must be 2.6.22.19-19-4.
  5. From either the same kernel sources or plain 2.6.22.19 with Sigma patches, build a vmlinux and (optionally) modules using this config. Modify the compiled-in command line to point to the correct rootfs. Set the version string to something other than in the previous step.
  6. Copy vmlinux to any directory in the rootfs.
  7. Copy kexec.sh and kexec.cgi to the same directory as vmlinux.
  8. Export the rootfs over NFS with full read/write permissions for the PCH.
  9. Power on the PCH, and update to latest firmware.
  10. Configure an NFS mount of the rootfs.
  11. Navigate to the rootfs in the PCH UI. A directory listing of bin, dev, etc. should be displayed.
  12. On the host system, run the kexec.sh script with the target hostname or IP address as argument.
  13. If all goes well, the new kernel will boot and mount the rootfs.

  Serial console

  A serial console is indispensable for solving boot problems. The PCH board has two UART connectors. We will use the one labeled UART0. The pinout is as follows (not standard PC pinout).

          +-----------+
         2| * * * * * |10
         1| * * * * * |9
          -----------+
            J7 UART0
      /---------------------/ board edge
  

  Pin	Function
  1	+5V
  5	Rx
  6	Tx
  10	GND

  The signals are 3.3V so a converter, e.g. MAX202, is required for connecting this to a PC serial port. The default port settings are 115200 bps 8n1.