Recherche avancée
Médias (29)
-
#7 Ambience
16 octobre 2011, par
Mis à jour : Juin 2015
Langue : English
Type : Audio
-
#6 Teaser Music
16 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Audio
-
#5 End Title
16 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Audio
-
#3 The Safest Place
16 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Audio
-
#4 Emo Creates
15 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Audio
-
#2 Typewriter Dance
15 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Audio
Autres articles (35)
-
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 -
Encoding and processing into web-friendly formats
13 avril 2011, parMediaSPIP automatically converts uploaded files to internet-compatible formats.
Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
All uploaded files are stored online in their original format, so you can (...) -
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 (...)
Sur d’autres sites (7373)
-
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
