Recherche avancée
Médias (3)
-
Elephants Dream - Cover of the soundtrack
17 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Image
-
Valkaama DVD Label
4 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Image
-
Publier une image simplement
13 avril 2011, par ,
Mis à jour : Février 2012
Langue : français
Type : Video
Autres articles (42)
-
Le profil des utilisateurs
12 avril 2011, parChaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Personnaliser les catégories
21 juin 2013, parFormulaire de création d’une catégorie
Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
On peut modifier ce formulaire dans la partie :
Administration > Configuration des masques de formulaire.
Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)
Sur d’autres sites (5976)
-
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
