Recherche avancée
Autres articles (68)
-
La file d’attente de SPIPmotion
28 novembre 2010, parUne file d’attente stockée dans la base de donnée
Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...) -
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
Contribute to documentation
13 avril 2011Documentation is vital to the development of improved technical capabilities.
MediaSPIP welcomes documentation by users as well as developers - including : critique of existing features and functions articles contributed by developers, administrators, content producers and editors screenshots to illustrate the above translations of existing documentation into other languages
To contribute, register to the project users’ mailing (...)
Sur d’autres sites (6480)
-
Can't playback huge video which was uploaded to google storage. I Get Error : Unable to retrieve manifest /stream.m3u8 -Error : Could not retrieve file
18 juillet 2022, par Dmytro PetskovychI upload file to google storage using "@ffmpeg-installer/ffmpeg" and @google-cloud/storage in my node.js App.
Step 1. file uploading to fs is in child processes - one process for each type of resolution (totaly six).
step 2. encription (converting to stream)
step 3. upload to google storage


This way is working fine only with small file. When i upload large file I Get server Error : Unable to retrieve manifest /stream.m3u8 or Unable to retrieve .


It seems that not all splits are uploaded to the cloud. but i checked they are there.


I am currently using "Upload a directory to a bucket" in order to send the video from the client to the Google Cloud Storage bucket.


when I upload video, actually I upload six videos, one for each type resolution


for example when I upload video with duration one hour it split on chunk and totally I get more three thousands files.


not all of this files are accessible when i try playback video. that's why I can't play video in all types of resolution and get error like


maybe someone had the similar problem and helps fix it
.
i have no idea why i get that behavior only with huge file


-
VLC huge buffering times over rtp for local H264 stream
15 mars 2022, par mikeI'm outputting an H264 stream, encoded by my application using ffmpeg. I can display it using
ffplay, but when trying to view the stream in VLC, I only get the first frame, or it looks like that's the case.

The messages output shows that it is "buffering", taking around a minute to get to 100% when the frame updates.
When using
ffplay, the latency is about 50-100ms at worst.

I am sending to
rtp://127.0.0.1:6666?pkt_size=1316with the formatrtp_mpegts.
I am new to this and it's highly likely I haven't set the frame up completely correctly. The process is (minus declarations and error checking)

codec_name = "libx264";
codec = avcodec_find_encoder_by_name(codec_name.c_str());
context = avcodec_alloc_context3(codec);
pkt = av_packet_alloc();
context->bit_rate = 5 * Mega;
context->width = info.DisplayWidth;
context->height = info.DisplayHeight;
context->time_base = { 1, FPS };
context->framerate = { FPS, 1 };
context->gop_size = 100;
context->max_b_frames = 1; 
context->pix_fmt = AV_PIX_FMT_YUV420P;
if (codec->id == AV_CODEC_ID_H264)
 {
 check_ret("set option: preset", av_opt_set(context->priv_data, "preset", "fast", 0));
 check_ret("set option: tune", av_opt_set(context->priv_data, "tune", "zerolatency", 0));
 check_ret("set option: profile", av_opt_set(context->priv_data, "profile", "baseline", 0)); 
 }
check_ret("open codec", avcodec_open2(context, codec, NULL));

// setup the stream 
fmt = (AVOutputFormat*)av_guess_format("rtp_mpegts", NULL, NULL);

avformat_alloc_output_context2(&avfctx, fmt, fmt->name,
 "rtp://127.0.0.1:6666?pkt_size=1316"); 
 
avio_open(&avfctx->pb, avfctx->url, AVIO_FLAG_WRITE);
AVStream* stream = avformat_new_stream(avfctx, codec);
avcodec_parameters_from_context(stream->codecpar, context);
stream->time_base.num = 1;
stream->time_base.den = FPS;
avformat_write_header(avfctx, NULL);

// then the encoding (in an output loop)
<not get="get" frame="frame" from="from" rgba="rgba" to="to" yuv="yuv">
yuvFrame->pts = i++; // i is incremented every frame
avcodec_send_frame(enc_ctx, yuvFrame);
 while (ret >= 0) {
 ret = avcodec_receive_packet(enc_ctx, pkt); 
 //ret = av_interleaved_write_frame(avfctx, pkt); was using this, don't seem to need it
 ret = av_write_frame(avfctx, pkt);
 av_packet_unref(pkt);
}
</not>

The VLC output looks like this :


main debug: using hw decoder module "d3d11va"
avcodec info: Using D3D11VA (NVIDIA GeForce RTX 2080 Super with Max-Q Design, vendor 10de(NVIDIA), device 1e93, revision a1) for hardware decoding
qt debug: Logical video size: 1280x720
main debug: resized to 1280x720
main debug: VoutDisplayEvent 'resize' 1280x720
main debug: Received first picture
main debug: Buffering 1%
main debug: Buffering 2%
main debug: Buffering 3%
main debug: auto hiding mouse cursor
main debug: Buffering 4%
main debug: Buffering 5%
main debug: Buffering 6%
main debug: Buffering 7%
main debug: Buffering 8%
main debug: Buffering 9%
main debug: Buffering 10%
main debug: auto hiding mouse cursor
main debug: Buffering 11%
rtp warning: 1 packet(s) lost
rtp warning: 1 packet(s) lost
rtp warning: 1 packet(s) lost
ts warning: discontinuity received 0x3 instead of 0xd (pid=256)
ts warning: discontinuity received 0x5 instead of 0xf (pid=256)
ts warning: discontinuity received 0x1 instead of 0xb (pid=256)
main debug: Buffering 12%
main debug: Buffering 13%
main debug: Buffering 14%
main debug: Buffering 15%
main debug: Buffering 16%
main debug: Buffering 17%
main debug: Buffering 18%
main debug: auto hiding mouse cursor
main debug: Buffering 19%
main debug: Buffering 20%


-
Revision c8ed36432e : Non-uniform quantization experiment This framework allows lower quantization bi
4 mars 2015, par Deb MukherjeeChanged Paths :
Modify /configure
Modify /vp9/common/vp9_blockd.h
Modify /vp9/common/vp9_onyxc_int.h
Modify /vp9/common/vp9_quant_common.c
Modify /vp9/common/vp9_quant_common.h
Modify /vp9/common/vp9_rtcd_defs.pl
Modify /vp9/decoder/vp9_decodeframe.c
Modify /vp9/decoder/vp9_detokenize.c
Modify /vp9/encoder/vp9_block.h
Modify /vp9/encoder/vp9_encodemb.c
Modify /vp9/encoder/vp9_encodemb.h
Modify /vp9/encoder/vp9_quantize.c
Modify /vp9/encoder/vp9_quantize.h
Modify /vp9/encoder/vp9_rdopt.c
Non-uniform quantization experimentThis framework allows lower quantization bins to be shrunk down or
expanded to match closer the source distribution (assuming a generalized
gaussian-like central peaky model for the coefficients) in an
entropy-constrained sense. Specifically, the width of the bins 0-4 are
modified as a factor of the nominal quantization step size and from 5
onwards all bins become the same as the nominal quantization step size.
Further, different bin width profiles as well as reconstruction values
can be used based on the coefficient band as well as the quantization step
size divided into 5 ranges.A small gain currently on derflr of about 0.16% is observed with the
same paraemters for all q values.
Optimizing the parameters based on qstep value is left as a TODO for now.Results on derflr with all expts on is +6.08% (up from 5.88%).
Experiments are in progress to tune the parameters for different
coefficient bands and quantization step ranges.Change-Id : I88429d8cb0777021bfbb689ef69b764eafb3a1de
Syndiquer tout le site
