
Recherche avancée
Autres articles (96)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Multilang : améliorer l’interface pour les blocs multilingues
18 février 2011, parMultilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela. -
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 (8055)
-
Anomalie #4430 : image_reduire gère mal les arrondis
4 février 2020, par jluc -L’image initiale fait 640 × 427 pixels.
|image_proportions1,1,focus produit correctement une image de 427x427. Il est donc probable qu’on reproduit le pb directement à partir d’une image de 427x427En tout cas le résultat final fait réellement 200x201.
-
Why iFrame is a good idea
15 octobre 2009I’ve seen some hilariously uninformed posts about the new Apple iFrame specification. Let me take a minute to explain what it actually is.
First off, as opposed to what the fellow in the Washington Post writes, it’s not really a new format. iFrame is just a way of using formats that we’ve already know and love. As the name suggests, iFrame is just an i-frame only H.264 specification, using AAC audio. An intraframe version of H.264 eh ? Sounds a lot like AVC-Intra, right ? Exactly. And for exactly the same reasons - edit-ability. Whereas AVC-Intra targets the high end, iFrame targets the low end.
Even when used in intraframe mode, H.264 has some huge advantage over the older intraframe codecs like DV or DVCProHD. For example, significantly better entropy coding, adaptive quantization, and potentially variable bitrates. There are many others. Essentially, it’s what happens when you take DV and spend another 10 years working on making it better. That’s why Panasonic’s AVC-Intra cameras can do DVCProHD quality video at half (or less) the bitrate.
Why does iFrame matter for editing ? Anyone who’s tried to edit video from one of the modern H.264 cameras without first transcoding to an intraframe format has experienced the huge CPU demands and sluggish performance. Behind the scenes it’s even worse. Because interframe H.264 can have very long GOPs, displaying any single frame can rely on dozens or even hundreds of other frames. Because of the complexity of H.264, building these frames is very high-cost. And it’s a variable cost. Decoding the first frame in a GOP is relatively trivial, while decoding the middle B-frame can be hugely expensive.
Programs like iMovie mask that from the user in some cases, but at the expensive of high overhead. But, anyone who’s imported AVC-HD video into Final Cut Pro or iMovie knows that there’s a long "importing" step - behind the scenes, the applications are transcoding your video into an intraframe format, like Apple Intermediate or ProRes. It sort of defeats one of the main purposes of a file-based workflow.
You’ve also probably noticed the amount of time it takes to export a video in an interframe format. Anyone who’s edited HDV in Final Cut Pro has experienced this. With DV, doing an "export to quicktime" is simply a matter of Final Cut Pro rewriting all of the data to disk - it’s essentially a file copy. With HDV, Final Cut Pro has to do a complete reencode of the whole timeline, to fit everything into the new GOP structure. Not only is this time consuming, but it’s essentially a generation loss.
iFrame solves these issues by giving you an intraframe codec, with modern efficiency, which can be decoded by any of the H.264 decoders that we already know and love.
Having this as an optional setting on cameras is a huge step forward for folks interested in editing video. Hopefully some of the manufacturers of AVC-HD cameras will adopt this format as well. I’ll gladly trade a little resolution for instant edit-ability.
-
MediaMetadataRetriever setDataSource failed : status = 0xFFFFFFED
10 octobre 2019, par darjaI need to fetch frames from video located in the web. That’s how I do this :
class PlayerWrapper {
private static final MediaMetadataRetriever mMediaMetadataRetriever = new MediaMetadataRetriever();
…
public void initPlayback(final Context context, final VideoSurfaceView videoSurface, final String url) {
new Thread(new Runnable() {
@Override
public void run() {
…
try {
mMediaMetadataRetriever.setDataSource(url, new HashMap());
} catch (Exception e) {
DPLog(e);
}
}
}).start();
}
public Bitmap getFrameAt(int positionMillis) {
if (mMediaMetadataRetriever != null) {
DPLog.d("Creating frame for position [%s]", positionMillis);
try {
return mMediaMetadataRetriever.getFrameAtTime(positionMillis * 1000);
} catch (Exception e) {
…
return null;
}
} else {
return null;
}
}
}This works fine on several devices with Android 4.4, 5 and 6. But on one device with Android 4.1.2
setDataSource
function fails with following stack trace :java.lang.RuntimeException: setDataSource failed: status = 0xFFFFFFED
at android.media.MediaMetadataRetriever._setDataSource(MediaMetadataRetriever.java)
at android.media.MediaMetadataRetriever.setDataSource(MediaMetadataRetriever.java:99)
at co.unreel.videoapp.playback.UnreelPlayer$3.run(UnreelPlayer.java:138)
at java.lang.Thread.run(Thread.java:856)Also tried this code on emulator, got almost the same but with status
0x80000000
Url is got from YouTube API, looks like this :
https://r2---sn-n3toxu-axqe.googlevideo.com/videoplayback?gcr=ru&sver=3&mm=31&mn=sn-n3toxu-axqe&key=yt6&signature=D1CE7B8615F3D96A58A9D2679057D676E7777E05.5A318AD8C5F48FCED2D1A9149348CD269F466FA9&mt=1456173450&pl=24&mv=m&ms=au&lmt=1455616987173757&itag=22&requiressl=yes&ip=188.242.217.203&source=youtube&dur=848.248&id=o-ABIn_CbRwqIO6qpvlaWe_ekyTZPLVd0w_eM80awd6uRQ&fexp=9408087%2C9416126%2C9419451%2C9420452%2C9421340%2C9422596%2C9423661%2C9423662%2C9425078%2C9425963%2C9427767%2C9427801%2C9428013%2C9428432%2C9428660%2C9429602&mime=video%2Fmp4&upn=P5qxGGbPoc0&sparams=dur%2Cgcr%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&expire=1456195127&initcwndbps=3140000&ratebypass=yes&ipbits=0
Permissions :
Why this can happen and what to do ?
I also tried to use
FFmpegMediaMetadataRetriever
with the same logic, but it doesn’t work at all,setDataSource
causes exceptions with status0xFFFFFFFF
on all devices. As I found on SO, that means that url is invalid, but it is ok and played byMediaPlayer
without any issues. Also I found that ffmpeg has issues with urls longer than 1024, but that’s not my case too.May be there are another way to get frames from video ?