Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (55)
-
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir -
List of compatible distributions
26 avril 2011, parThe table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...) -
Librairies et binaires spécifiques au traitement vidéo et sonore
31 janvier 2010, parLes logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
Binaires complémentaires et facultatifs flvtool2 : (...)
Sur d’autres sites (7067)
-
FFmpeg ignores some HTTP options when using the PUT method
6 mars 2020, par mehdi.rI am using FFmpeg to create a CMAF stream and I upload it to an AWS resource (AWS MediaStore) using the
PUTmethod of FFMpeg.
I need to pass theContent-Typeheader when uploading manifests & segments.
I have 3 type of files :application/x-mpegURL: m3u8 manifestapplication/dash+xml: mpd manifestvideo/mp4: video segmentsCurrently, all the types are set to
Binary - octet-streamin the AWS resource (AWS MediaStore).
As I will upload a huge number of files, I can’t use AWS Lambda functions to set the correct content type after a file as been uploaded.FFmpeg upload logs
[https @ 0x555fe7a7d1c0] Opening 'https://XXXX.YYYY.amazonaws.com/chunk-stream0-00001.mp4' for writing
[https @ 0x555fe7a7d0c0] request: PUT /chunk-stream0-00001.mp4 HTTP/1.1
Transfer-Encoding: chunked
User-Agent: Lavf/58.28.100
Accept: */*
Connection: keep-alive
Host: XXXXX.YYYY.amazonaws.com
Icy-MetaData: 1My tries
I tried static builds & master branch of FFMpeg.
I tried different ways to pass the content type, without success :-mime_type 1 -headers "Content-type: video/mp4\r\n"-mime_type "video/mp4,application/dash+xml,application/x-mpegURL"-content_type application/dash+xml-multiple_requests 1 -headers "a:b" -icy 0Upload command :
./ffmpeg -re -i ~/videos/BigBuckBunny.mp4 -loglevel debug \
-map 0 -map 0 -map 0 -c:a aac -c:v libx264 -tune zerolatency \
-b:v:0 2000k -s:v:0 1280x720 -profile:v:0 high -b:v:1 1500k -s:v:1 640x340 -profile:v:1 main -b:v:2 500k -s:v:2 320x170 -profile:v:2 baseline -bf 1 \
-keyint_min 24 -g 24 -sc_threshold 0 -b_strategy 0 -ar:a:1 22050 -use_timeline 1 -use_template 1 -window_size 5 \
-adaptation_sets "id=0,streams=v id=1,streams=a" -hls_playlist 1 -seg_duration 3 -streaming 1 \
-strict experimental -lhls 1 -remove_at_exit 0 -master_m3u8_publish_rate 3 \
-f dash -method PUT -http_persistent 1 https://example.com/manifest.mpdAny help would be highly appreciated.
Reference :
https://www.ffmpeg.org/ffmpeg-protocols.html#http -
FFmpeg segment desktop capture and send over http
18 décembre 2014, par staticI’m trying to capture the desktop video and segment it in order to send it over http to my node.js server, where I want to encode it to multiple bit-rates in order to serve it to clients for live streaming.
The video has to be received in segments in order to create the manifest for live streaming, because i’m trying to use DASH, and to play the video on the client side using dash.js.The problem is that i can’t seem to be able to segment the video properly when i’m sending it to the server.
This is the ffmpeg command that i’ve tried :
ffmpeg -rtbufsize 1500M -f dshow -r 10 -i video="UScreenCapture"
-vcodec libvpx -crf 10 -quality good -cpu-used 3 -b:v 1000k -qmin 10 -qmax 42 -
threads 2 -vf scale=-1:480 -bufsize 1500 -flags -global_header -map 0 -f stream_
segment -segment_time 2 -segment_format webm - http://localhost:3000/stream/22I’ve managed to send it over http without segmenting the video, but on the server side i need to receive segments that have a duration of 2 seconds so that i can create the manifest.
Also processing the video on the server side is also going to be done using ffmpeg(fluent ffmpeg module).
I’m open to any suggestions. -
ffmpeg Command in Docker with Rust Tokio Closes Warp Server Connection (curl 52 Error)
3 juin 2024, par user762345I’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;
use reqwest::Client;
use std::convert::Infallible;
use log::{info, error};
use env_logger;
use tokio::process::Command;

#[tokio::main]
async fn main() {
 std::env::set_var("RUST_LOG", "debug");
 env_logger::init();

 let route = warp::path::end()
 .and_then(handle_request);

 info!("Starting server on 0.0.0.0:3030");
 warp::serve(route)
 .run(([0, 0, 0, 0], 3030))
 .await;
}

async fn handle_request() -> Result<impl infallible="infallible"> {
 let client = Client::new();

 let output = Command::new("ffmpeg")
 .args(&[
 "y",
 "-i", "concat:/usr/src/minimal_docker_webserver_post_error/file1.wav|/usr/src/minimal_docker_webserver_post_error/file2.wav",
 "-c", "copy",
 "/usr/src/minimal_docker_webserver_post_error/combined.wav"
 ])
 .output()
 .await;

 match output {
 Ok(output) => {
 if output.status.success() {
 info!("WAV files concatenated successfully");
 } else {
 error!("Failed to concatenate WAV files: {:?}", output);
 return Ok(warp::reply::with_status("Failed to concatenate WAV files", warp::http::StatusCode::INTERNAL_SERVER_ERROR));
 }
 },
 Err(e) => {
 error!("Failed to execute ffmpeg: {:?}", e);
 return Ok(warp::reply::with_status("Failed to execute ffmpeg", warp::http::StatusCode::INTERNAL_SERVER_ERROR));
 }
 }

 // ISSUE: Connection closes with curl: (52) Empty reply from server
 match client.get("https://httpbin.org/get").send().await {
 Ok(response) => info!("GET request successful: {:?}", response),
 Err(e) => error!("GET request failed: {:?}", e),
 }

 match client.post("https://httpbin.org/post")
 .body("field1=value1&field2=value2")
 .send().await {
 Ok(response) => info!("POST request successful: {:?}", response),
 Err(e) => error!("POST request failed: {:?}", e),
 }

 Ok(warp::reply::with_status("Request handled", warp::http::StatusCode::OK))
}
</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"


Syndiquer tout le site
