Recherche avancée
Médias (1)
-
The Great Big Beautiful Tomorrow
28 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Texte
Autres articles (48)
-
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 -
Les formats acceptés
28 janvier 2010, parLes commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
ffmpeg -codecs ffmpeg -formats
Les format videos acceptés en entrée
Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
Les formats vidéos de sortie possibles
Dans un premier temps on (...) -
Ajouter notes et légendes aux images
7 février 2011, parPour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
Modification lors de l’ajout d’un média
Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)
Sur d’autres sites (7384)
-
Confused about x264 and encoding video frames
26 février 2015, par spartygwI built a test driver for encoding a series of images I have captured. I am using libx264 and based my driver off of this guy’s answer :
In my case I am starting out by reading in a JPG image and converting to YUV and passing that same frame over and over in a loop to the x264 encoder.
My expectation was that since the frame is the same that the output from the encoder would be very small and constant.
Instead I find that the NAL payload is varied from a few bytes to a few KB and also varies highly depending on the frame rate I specify in the encoder parameters.
Obviously I don’t understand video encoding. Why does the output size vary so much ?
int main()
{
Image image(WIDTH, HEIGHT);
image.FromJpeg("frame-1.jpg");
unsigned char *data = image.GetRGB();
x264_param_t param;
x264_param_default_preset(&param, "fast", "zerolatency");
param.i_threads = 1;
param.i_width = WIDTH;
param.i_height = HEIGHT;
param.i_fps_num = FPS;
param.i_fps_den = 1;
// Intra refres:
param.i_keyint_max = FPS;
param.b_intra_refresh = 1;
//Rate control:
param.rc.i_rc_method = X264_RC_CRF;
param.rc.f_rf_constant = FPS-5;
param.rc.f_rf_constant_max = FPS+5;
//For streaming:
param.b_repeat_headers = 1;
param.b_annexb = 1;
x264_param_apply_profile(&param, "baseline");
// initialize the encoder
x264_t* encoder = x264_encoder_open(&param);
x264_picture_t pic_in, pic_out;
x264_picture_alloc(&pic_in, X264_CSP_I420, WIDTH, HEIGHT);
// X264 expects YUV420P data use libswscale
// (from ffmpeg) to convert images to the right format
struct SwsContext* convertCtx =
sws_getContext(WIDTH, HEIGHT, PIX_FMT_RGB24, WIDTH, HEIGHT,
PIX_FMT_YUV420P, SWS_FAST_BILINEAR,
NULL, NULL, NULL);
// encoding is as simple as this then, for each frame do:
// data is a pointer to your RGB structure
int srcstride = WIDTH*3; //RGB stride is just 3*width
sws_scale(convertCtx, &data, &srcstride, 0, HEIGHT,
pic_in.img.plane, pic_in.img.i_stride);
x264_nal_t* nals;
int i_nals;
int frame_size =
x264_encoder_encode(encoder, &nals, &i_nals, &pic_in, &pic_out);
int max_loop=15;
int this_loop=1;
while (frame_size >= 0 && --max_loop)
{
cout << "------------" << this_loop++ << "-----------------\n";
cout << "Frame size = " << frame_size << endl;
cout << "output has " << pic_out.img.i_csp << " colorspace\n";
cout << "output has " << pic_out.img.i_plane << " # img planes\n";
cout << "i_nals = " << i_nals << endl;
for (int n=0; n -
PIL image save causes FFMPEG to fail
6 janvier 2023, par XorgonI have been attempting to convert some videos using FFMPEG with image2pipe using PIL. I have found that when the frame is particularly simple (such as all one colour), it causes FFMPEG to fail with the following message :


[image2pipe @ 000001785b599bc0] Could not find codec parameters for stream 0 (Video: none, none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, image2pipe, from 'pipe:':
 Duration: N/A, bitrate: N/A
 Stream #0:0: Video: none, none, 24 tbr, 24 tbn, 24 tbc
Output #0, mp4, to '<your filepath="filepath" here="here">/test.mp4':
Output file #0 does not contain any stream
</your>

The minimum code I have found to reproduce this is as follows :


import numpy as np
from subprocess import Popen, PIPE
from PIL import Image

output_file = "<your filepath="filepath" here="here">/test.mp4"

p = Popen(['ffmpeg',
 '-y', # Overwrite files
 '-f', 'image2pipe', # Input format
 '-r', '24', # Framerate
 '-i', '-', # stdin
 '-c:v', 'libx264', # Codec
 '-preset', 'slow',
 '-crf', f'18', # H264 Constant Rate Factor (quality, lower is better)
 output_file], stdin=PIPE)

# This one works
# vid = np.random.randint(0, 255, (10, 64, 64)) # Create a 64x64 'video' with 10 frames of random noise

# This one does not
vid = np.full((10, 64, 64), 129) # Create a 64x64 'video' with 10 frames of pure grey

for frame in vid:
 im = Image.fromarray(np.uint8(frame))
 im.save(p.stdin, 'JPEG')

p.stdin.close()
p.wait()
</your>

Notably, if I do the same thing with a randomly generated series of frames (commented as "This one works" in the script above), it will output fine.


One workaround I have found so far is to replace 'JPEG' with 'PNG' in the
im.save(...)call. However, I would be interested in understanding what causes it to fail with JPEG.

-
avformat/dashenc : replacing 'min_seg_duration' with 'seg_duration'
16 avril 2018, par Vishwanath Dixitavformat/dashenc : replacing 'min_seg_duration' with 'seg_duration'
There are use cases where average segment duration needs to be configured
and muxer is expected to maintain the average segment duration. So, using
the name 'min_seg_duration' will be misleading. So, changing the parameter
name to 'seg_duration', where it can be minimum segment duration or average
segment duration based on the use-case. The additional updates needed for
this functinality are made the sub-sequent patches of this patch series.
Syndiquer tout le site
