
Recherche avancée
Autres articles (39)
-
Submit bugs and patches
13 avril 2011Unfortunately a software is never perfect.
If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
You may also (...) -
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 (...)
-
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...)
Sur d’autres sites (8033)
-
ffmpeg-next how can I enable multithreading on a decoder ?
14 décembre 2022, par Brandon PiñaI'm using the rust crate
ffmpeg-next
to decode some video into individual frames for usage in another library. Problem is when I run my test it only seems to use a single core. I've tried modifying the threading configuration for my decoder as you can see below, but It doesn't seem to be do anything

let context_decoder =
 ffmpeg_next::codec::context::Context::from_parameters(input_stream.parameters())?;
 let mut decoder = context_decoder.decoder().video()?;
 let mut threading_config = decoder.threading();
 threading_config.count = num_cpus::get();
 threading_config.kind = ThreadingType::Frame;

 decoder.set_threading(threading_config);



-
Revision 085f76e535 : Add experimental VBR adaptation method. Add code to monitor over and under spen
15 avril 2014, par Paul WilkinsChanged Paths :
Modify /vp9/encoder/vp9_firstpass.c
Modify /vp9/encoder/vp9_onyx_if.c
Modify /vp9/encoder/vp9_ratectrl.c
Modify /vp9/encoder/vp9_ratectrl.h
Add experimental VBR adaptation method.Add code to monitor over and under spend and
apply limited correction to the data rate of subsequent
frames. To prevent the problem of starvation or overspend
on individual frames (especially near the end of a clip) the
maximum adjustment on a single frame is limited to a %
of its un-modified allocation.Change-Id : I6e1ca035ab8afb0c98eac4392115d0752d9cbd7f
-
ffmpeg inconsistent speed results by version breaking large audio file into multiple pieces with -ss/-to positional parameters [closed]
2 novembre 2024, par BenHI am trying to chop a large (12 hour+) audio file up into multiple segments using multiple -ss/-to positional operations.


ffmpeg.exe -loglevel error -stats -i "C:\data\chapters\joined_output.mp3" -ss -1 -to 1159 -c copy "C:\data\chapters\001 - Chapter 1.mp3" -ss 1159 -to 1800 -c copy "C:\data\chapters\002 - Chapter 2.mp3" -ss 1800 -to 3181 -c copy "C:\data\chapters\003 - Chapter 3.mp3" ... output.mp3



The '...' indicates that I have more than 20 of such repeated statements to break up into 20 or more chapter files.


I arrived on this because using individual command were processing the entire file each time to parse out the section I wanted. I realize there is an option to place -ss/-to prior to the input file, and have since discovered that this appears to work quicker, but I have not found syntax to use this in a single command and therefore must create a separate command for each chapter.


The above syntax appears to work fine, but was taking about 4 minutes to process. When I reverted to older versions this operation completes much quicker. About 20 seconds with version 6.1 and about 10 seconds on version 5.


There is some discrepancy with how the old versions report the length of the file (it appears to show only about 6.5 hours processed in "out_time" value), but the resulting output files appear to be correct. I think it might be reporting out_time of only the longest section it is processing as the 6.5 hours appear to match the length of that output section.


To be clear, version 5 using my above syntax appears to create all my output files correctly in 10 seconds.


If I split them up into individual commands with -ss/-to before the input, then it actually takes longer with ffmpeg version 5/6 (about 45 seconds compared to 10-20 seconds).
With the latest version 7 it takes about 1 min, 15 secs. Much better than the 4 minutes using my syntax above but still well slower than using version 5/6 with that same syntax.


So, in short, why am I able to (apparently) properly split this 12 hour file into about 25 different segments in about 10 seconds using the syntax above on version 5, but it takes 2x that long on 6, and 30x that long on 7 ? I assume there are just syntax changes I can't figure out or some changes to default behavior ?