
Recherche avancée
Autres articles (36)
-
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
-
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 (...) -
Selection of projects using MediaSPIP
2 mai 2011, parThe examples below are representative elements of MediaSPIP specific uses for specific projects.
MediaSPIP farm @ Infini
The non profit organizationInfini develops hospitality activities, internet access point, training, realizing innovative projects in the field of information and communication technologies and Communication, and hosting of websites. It plays a unique and prominent role in the Brest (France) area, at the national level, among the half-dozen such association. Its members (...)
Sur d’autres sites (4105)
-
ffmpeg : recommended bitrate vs resolution [duplicate]
15 octobre 2016, par Santhosh YedidiThis question already has an answer here :
-
FFMPEG sensible defaults
2 answers
I have high resolution video
Duration: 00:06:28.80, start: 0.000000, bitrate: 15968 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 15809 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
Metadata:
creation_time : 2016-10-11 05:35:02
handler_name : Alias Data Handler
encoder : AVC Coding
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 157 kb/s (default)
Metadata:
creation_time : 2016-10-11 05:35:02
handler_name : Alias Data HandlerIts 6+min video.
I am ok with resolution of 240p (because i want to send it on whatsapp)
In order my video to look good quality what is the recommended bitrate for 240p. Also is what is the minimum bitrate below which the chances of pixelating will be there in the video.
I dont want to go for high bitrate also. Because ultimately i want the size to be not more than 240p.
I use mpv to see the video. I scale the original video to 240p, the quality after conversion should match the quality visible in mpv. That will give me first hand idea of how good is the conversion.
I expect a good amount of reduction in size(MB : where original is 740mb) of the file when reduced from 1920x1080 to 240p
I have found some information regarding this.
How much is this true
-
FFMPEG sensible defaults
-
avcodec_decode_video2 fails to decode after frame resolution change
7 octobre 2016, par Krzysztof KansyI’m using ffmpeg in Android project via JNI to decode real-time H264 video stream. On the Java side I’m only sending the the byte arrays into native module. Native code is running a loop and checking data buffers for new data to decode. Each data chunk is processed with :
int bytesLeft = data->GetSize();
int paserLength = 0;
int decodeDataLength = 0;
int gotPicture = 0;
const uint8_t* buffer = data->GetData();
while (bytesLeft > 0) {
AVPacket packet;
av_init_packet(&packet);
paserLength = av_parser_parse2(_codecPaser, _codecCtx, &packet.data, &packet.size, buffer, bytesLeft, AV_NOPTS_VALUE, AV_NOPTS_VALUE, AV_NOPTS_VALUE);
bytesLeft -= paserLength;
buffer += paserLength;
if (packet.size > 0) {
decodeDataLength = avcodec_decode_video2(_codecCtx, _frame, &gotPicture, &packet);
}
else {
break;
}
av_free_packet(&packet);
}
if (gotPicture) {
// pass the frame to rendering
}The system works pretty well until incoming video’s resolution changes. I need to handle transition between 4:3 and 16:9 aspect ratios. While having AVCodecContext configured as follows :
_codecCtx->flags2|=CODEC_FLAG2_FAST;
_codecCtx->thread_count = 2;
_codecCtx->thread_type = FF_THREAD_FRAME;
if(_codec->capabilities&CODEC_FLAG_LOW_DELAY){
_codecCtx->flags|=CODEC_FLAG_LOW_DELAY;
}I wasn’t able to continue decoding new frames after video resolution change. The
got_picture_ptr
flag thatavcodec_decode_video2
enables when whole frame is available was never true after that.
This ticket made me wonder if the issue isn’t connected with multithreading. Only useful thing I’ve noticed is that when I changethread_type
toFF_THREAD_SLICE
the decoder is not always blocked after resolution change, about half of my attempts were successfull. Switching to single-threaded processing is not possible, I need more computing power. Setting up the context to one thread does not solve the problem and makes the decoder not keeping up with processing incoming data.
Everything work well after app restart.I can only think of one workoround (it doesn’t really solve the problem) : unloading and loading the whole library after stream resolution change (e.g as mentioned in here). I don’t think it’s good tho, it will propably introduce other bugs and take a lot of time (from user’s viewpoint).
Is it possible to fix this issue ?
EDIT :
I’ve dumped the stream data that is passed to decoding pipeline. I’ve changed the resolution few times while stream was being captured. Playing it with ffplay showed that in moment when resolution changed and preview in application froze, ffplay managed to continue, but preview is glitchy for a second or so. You can see full ffplay log here. In this case video preview stopped when I changed resolution to 960x720 for the second time. (Reinit context to 960x720, pix_fmt: yuv420p
in log). -
How to convert VP8 track with different frame resolution to h264
13 septembre 2016, par NikitaI have a .webm file with VP8 track, recorded from WebRTC stream by external service (TokBox Archiving). The stream is adaptive, so each frame in track could have different resolution. Most players (in webkit browsers) use video resolution from track description (which is always 640x480) and scale frames to this resolution. Firefox and VLC player uses real frame resolution, changing video resolution respectively.
I want to achieve 2 goals :
- play this video in Internet Explorer 9+ without additional plugin installation.
- change frames resolution to one fixed resolution, so the video will look identically in different browsers.
So, my plan is :
- extract frames from source webm file to images with real frame resolution (e.g. PNG or BMP) (how could I do that ?)
- find max width and max height of images
- add black padding to images, so smaller frames will be in the center of a new frame (of size MAX_WIDHTxMAX_HEIGHT)
- combine images to h264 track using ffmpeg
Is all correct ? How can I achieve this ? Can this algorithm be optimized some way ?
I tried ffmpeg to extract images, but it does not parse real frame resolution, using resolution from track header.
I think some libwebm functions can help me (to parse frame headers and extract images). Maybe someone has some code snippets to do this ?Example .webm (download source, do not play google-converted version) : https://drive.google.com/file/d/0BwFZRvYNn9CKcndhMzlVa0psX00/view?usp=sharing
Official description of adaptive stream from TokBox support : https://support.tokbox.com/hc/en-us/community/posts/206241666-Archived-video-resolution-is-supposed-to-be-720x1280-but-reports-as-640x480