Recherche avancée
Autres articles (74)
-
Mise à jour de la version 0.1 vers 0.2
24 juin 2013, parExplications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...) -
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;
-
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)
Sur d’autres sites (12563)
-
VLC and ffplay not receiving video from RTMP stream on Nginx
14 janvier, par EkobaddI'm streaming via OBS 30.1.2 to an RTMP server on a digitalocean droplet. The server is running on nginx 1.26.0 using the RTMP plugin (libnginx-mod-rtmp in apt).


OBS is configured to output H.264-encoded, 1200kbps, 24fps, 1920x1080 video and aac-encoded, stereo, 44.1kHz, 160kbps audio.


Below is the minimal reproducible example. When I attempt to play the rtmp stream with ffplay or VLC, it's a random chance whether I get video or not. Audio is always fine. The output from ffplay or ffprobe (example below) occasionally does not show any video stream.


rtmp {
 server {
 listen 1935;
 chunk_size 4096;

 application ingest {
 live on;
 record off;

 allow publish <my ip="ip" address="address">;
 deny publish all;

 allow play all;
 }
 }
}
</my>

The server has two applications, "ingest" and "live", the former uses the following ffmpeg command to transcode the stream and create a corresponding stream on the latter application :


exec_push ffmpeg -i rtmp://localhost/ingest/$name -b:v 1200k -c:v libx264 -c:a aac -ar 44100 -ac 1 -f flv -preset veryfast -tune zerolatency rtmp://localhost/live/$name 2>>/tmp/rtmp-ingest-$name.log;


As you can see, this produces a log which shows the following :


Output #0, flv, to 'rtmp://localhost/live/ekobadd':
 Metadata:
 |RtmpSampleAccess: true
 Server : NGINX RTMP (github.com/arut/nginx-rtmp-module)
 displayWidth : 1920
 displayHeight : 1080
 fps : 23
 profile :
 level :
 encoder : Lavf61.1.100
 Stream #0:0: Audio: aac (LC) ([10][0][0][0] / 0x000A), 44100 Hz, mono, fltp, 69 kb/s
 Metadata:
 encoder : Lavc61.3.100 aac


The video is not present, though I can see on the digitalocean control panel that the server is pulling 1.2Mbps inbound, which is about the same as my OBS video bitrate. And, although the ffmpeg instance which is transcoding does not appear to see the video stream from the ingest application, ffprobe from my local machine does, sometimes :


> ffprobe rtmp://mydomain.com/ingest/ekobadd
...
Input #0, flv, from 'rtmp://mydomain.com/ingest/ekobadd': 0B f=0/0
 Metadata:
 |RtmpSampleAccess: true
 Server : NGINX RTMP (github.com/arut/nginx-rtmp-module)
 displayWidth : 1920
 displayHeight : 1080
 fps : 23
 profile :
 level :
 Duration: 00:00:00.00, start: 122.045000, bitrate: N/A
 Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 163 kb/s
 Stream #0:1: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 1228 kb/s, 23 fps, 23.98 tbr, 1k tbn
 126.24 A-V: -1.071 fd= 0 aq= 54KB vq= 161KB sq= 0B f=0/0


Sometimes, however, it doesn't see the stream at all :


[rtmp @ 0000022d87d0fe00] Server error: No such stream
rtmp://mydomain.com/ingest/ekobadd: Operation not permitted


Testing the stream with VLC gives the same results.


Of course, the "live" application also doesn't have video. I have, however, streamed video from it before. I assume if I restart nginx enough, that the exec_push ffmpeg command will randomly see the video stream much like ffprobe does. I also have HLS and DASH configured, and they're both working perfect if you're a radio talk show host.


/etc/nginx/nginx.conf : (I'm quite sure I never touched anything in the HTTP section, but it's included just in case)


rtmp {
 server {
 listen 1935;
 chunk_size 8192;

 idle_streams off;

 application ingest {
 live on;
 record off;

 # Transcode to h264/aac via flv, 1.2Mbps 24fps 44.1kHz, single audio channel video (HLS Ready)
 exec_push ffmpeg -i rtmp://localhost/ingest/$name -b:v 1200k -c:v libx264 -c:a aac -ar 44100 -ac 1 -f flv -preset veryfast -tune zerolatency rtmp://localhost/live/$name 2>>/tmp/rtmp-ingest-$name.log;

 allow publish <my ip="ip" address="address">;
 deny publish all;

 allow play all; # This was added for debugging.
 }

 application live {
 live on;
 record off;

 hls on;
 hls_path /var/www/mydomain.com/html/live/hls;
 hls_fragment 6s;
 hls_playlist_length 60;

 dash on;
 dash_path /var/www/mydomain.com/html/live/dash;

 allow publish 127.0.0.1;
 deny publish all;

 allow play all;
 }
 }
}

http {

 ##
 # Basic Settings
 ##

 sendfile on;
 tcp_nopush on;
 types_hash_max_size 2048;
 server_tokens build; # Recommended practice is to turn this off

 server_names_hash_bucket_size 64;
 # server_name_in_redirect off;

 include /etc/nginx/mime.types;
 default_type application/octet-stream;

 ##
 # SSL Settings
 ##

 ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3 (POODLE), TLS 1.0, 1.1
 ssl_prefer_server_ciphers off; # Don't force server cipher order.

 ##
 # Logging Settings
 ##

 access_log /var/log/nginx/access.log;

 ##
 # Gzip Settings
 ##

 gzip on;

 # gzip_vary on;
 # gzip_proxied any;
 # gzip_comp_level 6;
 # gzip_buffers 16 8k;
 # gzip_http_version 1.1;
 # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

 ##
 # Virtual Host Configs
 ##

 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;
}
</my>

/etc/nginx/sites-available/mydomain.com :


server {
 listen 443 ssl;

 ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;

 root /var/www/mydomain.com/html;

 server_name mydomain.com www.mydomain.com;

 location / {
 root /var/www/mydomain.com/html/live;

# add_header Cache-Control no-cache;
 add_header Access-Control-Allow-Origin *;
 }
}

types {
# application/vnd.apple.mpegurl m3u8;
 application/dash+xml mpd;
}


-
ffmpeg-next potential bug in write_header causes timebase to bet set to Rational(1/15360)
7 septembre 2024, par HuhngutI am trying to encode a video using the ffmpeg_next crate. I got everything working and it successfully creates an output video.
The only problem is that the time_base of my stream is wrongly written to the file.
I can confirm that I set the timebase correctly for both the encoder as well as the stream.


By debug prints I was able to narrow the problem down.
octx.write_header().unwrap();causes the stream timebase to be reset from Rational(1/30) to Rational(1/15360). Changing the timebase back afterwards has no effect. The wrong value must have been written to the header.

I modified the src code of ffmpeg-next and recompiled it. I can confirm that the correct value is set before the call to
avformat_write_header

pub fn write_header(&mut self) -> Result<(), Error> {
 println!(
 "_________________ {:?}",
 self.stream(0).unwrap().time_base()
 );
 unsafe {
 match avformat_write_header(self.as_mut_ptr(), ptr::null_mut()) {
 0 => Ok(()),
 e => Err(Error::from(e)),
 }
 }
 }


To my understanding this must be a bug in the crate but I dont want to accuse someone with my non existing knowledge about ffmpeg. Also the examples in the github repo seem not to have this problem. My fault then ? Unfortunately I was not able to get the transcode-x264 to run. Most of my code comes from this example.


Relevant code bits are these. I dont know how much the set_parameters influences anything. My testing said it has no influence. I also tried to set the timebase at the very end of the function if it gets reset my the parameters. This is not working


let mut ost = octx.add_stream(codec)?;
ost.set_time_base(Rational::new(1, FPS));

ost.set_parameters(&encoder);
encoder.set_time_base(Rational::new(1, FPS));
ost.set_parameters(&opened_encoder);


By default and in the above example the streams timebase is 0/0. If I leave it out or change it to this manually it has no effect.


I also noticed that changing the value inside set_pts influences the output fps. Although not the timebase. I think this is more of a sideeffect.


I will leave a minimal reproducible example below. Any help or hints would be appreciated


abstract main function


fn main() {
 let output_file = "output.mp4";
 let x264_opts = parse_opts("preset=medium".to_string()).expect("invalid x264 options string");

 ffmpeg_next::init().unwrap();
 let mut octx = format::output(output_file).unwrap();

 let mut encoder = Encoder::new(&mut octx, x264_opts).unwrap();

 format::context::output::dump(&octx, 0, Some(&output_file));
 //This line somehow clears the streams time base
 octx.write_header().unwrap();

 // Without this line, the next logs returns Rational(1/30) Rational(1/15360) indicating streams timebase is wrong. even thought I set it above
 // this line changes it back but only for the print but not the actual output. Because the faulty data is written into the header
 // octx.stream_mut(0)
 // .unwrap()
 // .set_time_base(Rational::new(1, FPS));

 println!(
 "---------------- {:?} {:?}",
 encoder.encoder.time_base(),
 octx.stream(0).unwrap().time_base(),
 );

 for frame_num in 0..100 {
 let mut frame = encoder.create_frame();
 frame.set_pts(Some(frame_num));
 encoder.add_frame(&frame, &mut octx);
 }

 encoder.close(&mut octx);
 octx.write_trailer().unwrap();
}


Encoder struct containing the implementation logic


struct Encoder {
 encoder: encoder::Video,
}

impl Encoder {
 fn new(
 octx: &mut format::context::Output,
 x264_opts: Dictionary,
 ) -> Result {
 let set_header = octx
 .format()
 .flags()
 .contains(ffmpeg_next::format::flag::Flags::GLOBAL_HEADER);

 let codec = encoder::find(codec::Id::H264);
 let mut ost = octx.add_stream(codec)?;
 ost.set_time_base(Rational::new(1, FPS));

 let mut encoder = codec::context::Context::new_with_codec(
 encoder::find(codec::Id::H264)
 .ok_or(ffmpeg_next::Error::InvalidData)
 .unwrap(),
 )
 .encoder()
 .video()
 .unwrap();
 ost.set_parameters(&encoder);

 encoder.set_width(WIDTH);
 encoder.set_height(HEIGHT);
 encoder.set_aspect_ratio(WIDTH as f64 / HEIGHT as f64);
 encoder.set_format(util::format::Pixel::YUV420P);
 encoder.set_frame_rate(Some(Rational::new(FPS, 1)));
 encoder.set_time_base(Rational::new(1, FPS));

 if set_header {
 encoder.set_flags(ffmpeg_next::codec::flag::Flags::GLOBAL_HEADER);
 }

 let opened_encoder = encoder
 .open_with(x264_opts.to_owned())
 .expect("error opening x264 with supplied settings");
 ost.set_parameters(&opened_encoder);

 println!(
 "\nost time_base: {}; encoder time_base: {}; encoder frame_rate: {}\n",
 ost.time_base(),
 &opened_encoder.time_base(),
 &opened_encoder.frame_rate()
 );

 Ok(Self {
 encoder: opened_encoder,
 })
 }

 fn add_frame(&mut self, frame: &frame::Video, octx: &mut format::context::Output) {
 self.encoder.send_frame(frame).unwrap();
 self.process_packets(octx);
 }

 fn close(&mut self, octx: &mut format::context::Output) {
 self.encoder.send_eof().unwrap();
 self.process_packets(octx);
 }

 fn process_packets(&mut self, octx: &mut format::context::Output) {
 let mut encoded = Packet::empty();
 while self.encoder.receive_packet(&mut encoded).is_ok() {
 encoded.set_stream(0);
 encoded.write_interleaved(octx).unwrap();
 }
 }

 fn create_frame(&self) -> frame::Video {
 return frame::Video::new(
 self.encoder.format(),
 self.encoder.width(),
 self.encoder.height(),
 );
 }
}


other util stuff


use ffmpeg_next::{
 codec::{self},
 encoder, format, frame, util, Dictionary, Packet, Rational,
};

const FPS: i32 = 30;
const WIDTH: u32 = 720;
const HEIGHT: u32 = 1080;

fn parse_opts<'a>(s: String) -> Option> {
 let mut dict = Dictionary::new();
 for keyval in s.split_terminator(',') {
 let tokens: Vec<&str> = keyval.split('=').collect();
 match tokens[..] {
 [key, val] => dict.set(key, val),
 _ => return None,
 }
 }
 Some(dict)
}


-
MJPEG decoding is 3x slower when opening a V4L2 input device [closed]
26 octobre 2024, par XenonicI'm trying to decode a MJPEG video stream coming from a webcam, but I'm hitting some performance blockers when using FFmpeg's C API in my application. I've recreated the problem using the example video decoder, where I just simply open the V4L2 input device, read packets, and push them to the decoder. What's strange is if I try to get my input packets from the V4L2 device instead of from a file, the
avcodec_send_packetcall to the decoder is nearly 3x slower. After further poking around, I narrowed the issue down to whether or not I open the V4L2 device at all.

Let's look at a minimal example demonstrating this behavior :


extern "C"
{
#include <libavcodec></libavcodec>avcodec.h>
#include <libavformat></libavformat>avformat.h>
#include <libavutil></libavutil>opt.h>
#include <libavdevice></libavdevice>avdevice.h>
}

#define INBUF_SIZE 4096

static void decode(AVCodecContext *dec_ctx, AVFrame *frame, AVPacket *pkt)
{
 if (avcodec_send_packet(dec_ctx, pkt) < 0)
 exit(1);
 
 int ret = 0;
 while (ret >= 0) {
 ret = avcodec_receive_frame(dec_ctx, frame);
 if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
 return;
 else if (ret < 0)
 exit(1);

 // Here we'd save off the decoded frame, but that's not necessary for the example.
 }
}

int main(int argc, char **argv)
{
 const char *filename;
 const AVCodec *codec;
 AVCodecParserContext *parser;
 AVCodecContext *c= NULL;
 FILE *f;
 AVFrame *frame;
 uint8_t inbuf[INBUF_SIZE + AV_INPUT_BUFFER_PADDING_SIZE];
 uint8_t *data;
 size_t data_size;
 int ret;
 int eof;
 AVPacket *pkt;

 filename = argv[1];

 pkt = av_packet_alloc();
 if (!pkt)
 exit(1);

 /* set end of buffer to 0 (this ensures that no overreading happens for damaged MPEG streams) */
 memset(inbuf + INBUF_SIZE, 0, AV_INPUT_BUFFER_PADDING_SIZE);

 // Use MJPEG instead of the example's MPEG1
 //codec = avcodec_find_decoder(AV_CODEC_ID_MPEG1VIDEO);
 codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG);
 if (!codec) {
 fprintf(stderr, "Codec not found\n");
 exit(1);
 }

 parser = av_parser_init(codec->id);
 if (!parser) {
 fprintf(stderr, "parser not found\n");
 exit(1);
 }

 c = avcodec_alloc_context3(codec);
 if (!c) {
 fprintf(stderr, "Could not allocate video codec context\n");
 exit(1);
 }

 if (avcodec_open2(c, codec, NULL) < 0) {
 fprintf(stderr, "Could not open codec\n");
 exit(1);
 }

 c->pix_fmt = AV_PIX_FMT_YUVJ422P;

 f = fopen(filename, "rb");
 if (!f) {
 fprintf(stderr, "Could not open %s\n", filename);
 exit(1);
 }

 frame = av_frame_alloc();
 if (!frame) {
 fprintf(stderr, "Could not allocate video frame\n");
 exit(1);
 }

 avdevice_register_all();
 auto* inputFormat = av_find_input_format("v4l2");
 AVDictionary* options = nullptr;
 av_dict_set(&options, "input_format", "mjpeg", 0);
 av_dict_set(&options, "video_size", "1920x1080", 0);

 AVFormatContext* fmtCtx = nullptr;


 // Commenting this line out results in fast encoding!
 // Notice how fmtCtx is not even used anywhere, we still read packets from the file
 avformat_open_input(&fmtCtx, "/dev/video0", inputFormat, &options);


 // Just parse packets from a file and send them to the decoder.
 do {
 data_size = fread(inbuf, 1, INBUF_SIZE, f);
 if (ferror(f))
 break;
 eof = !data_size;

 data = inbuf;
 while (data_size > 0 || eof) {
 ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
 data, data_size, AV_NOPTS_VALUE, AV_NOPTS_VALUE, 0);
 if (ret < 0) {
 fprintf(stderr, "Error while parsing\n");
 exit(1);
 }
 data += ret;
 data_size -= ret;

 if (pkt->size)
 decode(c, frame, pkt);
 else if (eof)
 break;
 }
 } while (!eof);

 return 0;
}


Here's a histogram of the CPU time spent in that
avcodec_send_packetfunction call with and without opening the device by commenting out thatavformat_open_inputcall above.

Without opening the V4L2 device :




With opening the V4L2 device :




Interestingly we can see a significant number of function calls are in that 25ms time bin ! But most of them are 78ms... why ?


So what's going on here ? Why does opening the device destroy my decode performance ?


Additionally, if I try and run a seemingly equivalent pipeline through the ffmpeg tool itself, I don't hit this problem. Running this command :


ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -r 30 -c:v mjpeg -i /dev/video0 -c:v copy out.mjpeg


Is generating an output file with a reported speed of just barely over 1.0x, aka. 30 FPS. Perfect, why doesn't the C API give me the same results ? One thing to note is I do get periodic errors from the MJPEG decoder (about every second), not sure if these are a concern or not :


[mjpeg @ 0x5590d6b7b0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 27 >= 27
[mjpeg @ 0x5590d6b7b0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 30 >= 30
...


I'm running on a Raspberry Pi CM4 with FFmpeg 6.1.1


Syndiquer tout le site
