Recherche avancée

Recherche
Choix de la période de publication
Date minimale :

Date maximale :

Type de date :
Choix de la langue
Choix du type de média
Choix de la rubrique
Choix de la licence de publication
Choix de l’auteur

Médias (3)

Mot : - Tags -/image

Elephants Dream - Cover of the soundtrack

17 octobre 2011, par kent1

Mis à jour : Octobre 2011

Langue : English

Type : Image

Tags : image, Elephant dreams, soundtrack

1
2
3
4
5
Valkaama DVD Label

4 octobre 2011, par kent1

Mis à jour : Février 2013

Langue : English

Type : Image

Tags : image, psd, creative commons, doc2img, opensource, open film making, Valkaama

1
2
3
4
5
Publier une image simplement

13 avril 2011, par kent1, Webmaster - Bij de Brest

Mis à jour : Février 2012

Langue : français

Type : Video

Tags : publier, publishing, media, image

1
2
3
4
5

Autres articles (73)

Initialisation de MediaSPIP (préconfiguration)

20 février 2010, par kent1

Lors de l’installation de MediaSPIP, celui-ci est préconfiguré pour les usages les plus fréquents.
Cette préconfiguration est réalisée par un plugin activé par défaut et non désactivable appelé MediaSPIP Init.
Ce plugin sert à préconfigurer de manière correcte chaque instance de MediaSPIP. Il doit donc être placé dans le dossier plugins-dist/ du site ou de la ferme pour être installé par défaut avant de pouvoir utiliser le site.
Dans un premier temps il active ou désactive des options de SPIP qui ne le (...)
Le profil des utilisateurs

12 avril 2011, par kent1

Chaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...)
Configurer la prise en compte des langues

15 novembre 2010, par kent1

Accéder à la configuration et ajouter des langues prises en compte
Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...)

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ... | 25

Sur d’autres sites (9628)

Anomalie #4128 (En cours) : Bug de génération de boucle avec les modèles Spip

11 avril 2018, par Julien PORIAU

Dans les modèles personnalisés Spip, les images (boucle documents ou logos) sont mal générées et provoque un bug d’encodage visible dans le front-end lors du passage dans une autre langue (balises multi).
Nous n’avons pas trouvé où était le souci dans Spip, mais les caractères qui remontent dans le code source, ressemblent aux octets qui composent le fichier binaire d’une image.
Voir en live ici : http://spip-dev.nidecker.com/probleme-de-langue.html?lang=ca.

Pour essayer d’isoler cette anomalie, nous avons procédé de la sorte avec l’aide de mon développeur :

1. Nous sommes reparti d’un SPIP 3.1.7 entièrement neuf (minimal), avec deux modèles Spip, rien d’autre.
Le bug se reproduit, ce qui exclus un problème lié aux squelettes ou autres plugins.

Nous n’avons pas réussi a déterminer précisément ce qui génère ce bug, à part que c’est dans un contexte où on appelle une langue pas définie dans le multi.
En fonction du contenu de l’article, du nombre de modèles dans l’article, en fonction des boucles dans les inclure, le bug n’arrive pas au même endroit...

Le problème vient de la génération des logos ou documents : si on supprime les balises #LOGO_* ou si on renomme IMG en IMG_, plus d’erreur.
Même sans traitements, avec juste [(#LOGO_*)], rien à faire.

2. Nous avons pensé que c’était peut être une image au mauvais format : On a alors tenté de passer ImageOptim sur tout le répertoire /IMG, redimensionné tous les logos en vignettes png de 320x240, rien à faire...

3. On a fini par passer ce site de test en 3.2, pas mieux.

4. Nous avons épluché les caches générés dans /tmp/cache et /tmp/cache/skel, tout paraît normal de ce côté là..

5. On a ensuite un peu avancé en enlevant dans mes_options.php la variable $GLOBALS['forcer_lang'] = true".
Sur la version minimal, plus de bug. Mais sur le site de production, le problème réside toujours.
Mais en faisant des tests avec et sans (et en supprimant bien /tmp/cache/ à chaque fois), ça se confirme pour la version minimal.

6. A partir d’une copie de la version production, nous avons désactivé tout les plugins, passer ImageOptim sur /IMG et rien a faire.. Impossible de déterminé d’où vient le problème :(

7. Nous avons essayé d’écrire comme ceci : [<img src="http://core.spip.org/projects/spip/(#LOGO_MOT|image_reduire{50,*}|extraire_attribut{src})" alt="" style='max-width: 300px; max-height: 300px' />]
Cela fonctionne sur la version minimal mais pas sur la version production.

8. Dans la version minimal, j’ai encore récemment testé une dernière chose. J’ai supprimé les documents non sollicités sur ma page de teste (spip.php ?article1441&lang=ca).
Avec la requête SQL suivante : DELETE FROM jones_documents WHERE id_document NOT IN (1948,1949,2534,2535,630,631,1783,1784,1785,1786,1787,1788,1781,1782)
Le bug n’apparait plus..

Je sèche..

Vous trouverez ici en téléchargement une archive de la version minimal (Spip 3.1.7) : https://www.dropbox.com/s/dek0zg7jafl8uxe/jones.zip?dl=0] ( 20mo)
Pour reproduire le bug, il suffit de passer la variable "&lang=ca" dans l’article 1441 (localhost/spip.php ?article1441&lang=ca).

Je donne volontiers un accès à la version production si besoin.
Can I know which byte range to read from a remote mp4 file for FFMpeg to decode a keyframe ?

12 octobre 2023, par db9117
I need to decode a of keyframe of a video file (mp4, h264 encoded). I know the timestamp of the keyframe I want to extract/decode. I want to minimize amount of data being read in memory. For this, I need to know beforehand exactly the minimal byte range I would require that encompasses this keyframe. How do I know what is the minimal byte range in the whole mp4 byte stream I need to read in order to be able to decode the keyframe ?




I currently find the appropriate keyframe in the index_entries contained in the header. I get its byte position (pos attribute) and timestamp (timestamp attribute). I calculate the range as follows :




startBytes : minimum of :



1. the pos of the keyframe
2. the pos of the nearest index entry in the audio stream happening at or before the keyframe's timestamp.



This way when it's decoding the frame, if it also needs the audio content for demuxing, it would have it.




endBytes : maximum of :



1. the pos of the next frame in the video stream's index, after the keyframe
2. the pos of the next frame in the audio stream's index after the timestamp of the wished keyframe.



This way I know that I have everything up until the next frame in the index, which theoretically should be enough to decode the keyframe only.




I then read the appropriate byte range.




When I try to decode the frame, I run in a loop until I succeed :



- avcodec_read_frame
- avcodec_send_packet
- avcodec_receive_frame



I ignore AVERROR(EAGAIN) errors.




avcodec_receive_frame fails multiple times with error AVERROR(EAGAIN) which I ignore, until it fails saying that the memory it wants to read isn't available (wants to read after endBytes). I explicitly tell it to fail if it wants to read more than it has already read.




Note : for other keyframes at other positions in other videos, it sometimes succeeds (probably because the range is big enough by chance), but it fails more often than not.




My question is : Why is the end of the range not enough to be able to decode only the one keyframe ? Is there any way to more precisely calculate the exact range in bytes I would need in order to decode a particular keyframe ?

MediaCodec hardware decoder much slower with different server configuration ?

19 octobre 2013, par mathieujofis

I've been using the Android MediaCodec in order to (hardware) decode H.264 frames on my Galaxy S4 coming from a Live 555 RTSP live (real-time) stream. After changing my Live 555 server configuration from using ffmpeg (with x264) to encode frames, to using strictly x264 to encode frames, the time to decode frames with MediaCodec takes much longer. Basically, MediaCodec can't keep up with the stream, and displays the video in slow motion, getting slower and slower as time goes on. Going back to ffmpeg isn't a solution for me, because I need the ability to encode into discrete NAL units, rather than a whole frame like ffmpeg does.

I was wondering if this was either : A) An issue with the way my server is encoding NAL units, or B) An issue with my Android client, specifically the way it is receiving and decoding NAL units.

My encoding configuration with x264 is :

x264_param_default_preset(&amp;param,"ultrafast", "zerolatency:fastdecode");

param.i_threads = 1;

param.i_bframe = 1;

param.i_width = image_width;

param.i_height = image_height;

param.i_fps_num = 60;

param.i_fps_den = 1;

param.i_keyint_max = 10;



param.rc.i_rc_method = X264_RC_ABR;

param.rc.i.bitrate = 6000;

param.i_sps_id = 7;

param.b_repeat_headers = 1;

param.b_annexb = 0;

My Android MediaCodec client is set up as follows :

I receive each individual NAL unit on a separate Live 555 RTSP client thread. Each NAL is put into a queue along with its size and presentation time. A separate decoder thread grabs NALs from this queue, and if there are none available, waits until there are.

Some notes :

What I generally see happen is the queue starts filling up with NALs, instead of staying close to empty. So, I know that the decoder thread is not working fast enough. I don't think this is an inherent problem with decoding on an Android phone (for example, processing limitations) because it does the same thing for very low bitrates— also again, it DID work when I was using ffmpeg to encode. If I omit certain NAL units, the decoder can start to keep up. Since I'm using Cyanogenmod 10.1, bumping up the minimum CPU frequency helps, too.

Edit :

Here is a log of the Android client, as well as a log highlighting the garbage collector specifically—

Entire Logcat :

10-15 16:40:03.955: D/DecodeActivity(18859): INFO_OUTPUT_BUFFERS_CHANGED

10-15 16:40:03.995: E/OMX-VDEC-1080P(288): Sync frame received

10-15 16:40:03.995: E/OMX-VDEC-1080P(288):  No color conversion required

10-15 16:40:03.995: E/OMX-VDEC-1080P(288): Get_parameter: OMX_IndexParamPortDefinition: nPortIndex (1), nFrameWidth (1280), nFrameHeight (720), nStride (1280), nSliceHeight (736), nBitrate (-1073741824), xFramerate (0x1e), nBufferSize (1433600), nBufferCountMin (4), nBufferCountActual (8), bBuffersContiguous (1918394328), nBufferAlignment (1075643347), bEnabled (1), bPopulated (1), eCompressionFormat (0x0), eColorFormat (0x7fa30c03)

10-15 16:40:03.995: D/DecodeActivity(18859): New format {height=720, what=1869968451, color-format=2141391875, slice-height=736, crop-left=0, width=1280, crop-bottom=719, crop-top=0, mime=video/raw, stride=1280, crop-right=1279}

10-15 16:40:04.005: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4966) fps(201.369308)

10-15 16:40:04.015: W/IInputConnectionWrapper(1069): showStatusIcon on inactive InputConnection

10-15 16:40:04.025: I/ActivityManager(698): Displayed com.mathieu.alloclient.javadecoder/.MainActivity: +617ms

10-15 16:40:04.025: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4766) fps(209.819550)

10-15 16:40:04.125: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4733) fps(211.282486)

10-15 16:40:04.445: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4711) fps(212.269150)

10-15 16:40:04.495: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4700) fps(212.765961)

10-15 16:40:05.676: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4688) fps(213.310577)

10-15 16:40:06.087: D/dalvikvm(698): WAIT_FOR_CONCURRENT_GC blocked 1ms

10-15 16:40:06.207: D/dalvikvm(698): GC_EXPLICIT freed 4120K, 39% free 24216K/39664K, paused 7ms+9ms, total 117ms

10-15 16:40:06.537: D/ALSADevice(288): standby: handle 0x40024450 h 0x0

10-15 16:40:06.577: D/alsa_ucm(288): snd_use_case_set(): uc_mgr 0x400fbfb0 identifier _verb value Inactive

10-15 16:40:06.577: D/alsa_ucm(288): Set mixer controls for HiFi Lowlatency enable 0

10-15 16:40:06.577: D/alsa_ucm(288): Setting mixer control: SLIMBUS_0_RX Audio Mixer MultiMedia5, value: 0

10-15 16:40:06.577: D/alsa_ucm(288): snd_use_case_set(): uc_mgr 0x400fbfb0 identifier _disdev value Line

10-15 16:40:06.577: D/alsa_ucm(288): disdev: device Line not enabled, no need to disable

10-15 16:40:06.577: D/alsa_ucm(288): snd_use_case_set(): uc_mgr 0x400fbfb0 identifier _disdev value Speaker

10-15 16:40:06.577: D/alsa_ucm(288): Set mixer controls for Speaker enable 0

10-15 16:40:06.577: D/alsa_ucm(288): Setting mixer control: RX5 MIX1 INP1, value: ZERO

10-15 16:40:06.587: D/alsa_ucm(288): Setting mixer control: RX5 MIX1 INP2, value: ZERO

10-15 16:40:06.587: D/alsa_ucm(288): Setting mixer control: LINEOUT2 Volume, value: 0

10-15 16:40:06.587: D/alsa_ucm(288): Setting mixer control: LINEOUT4 Volume, value: 0

10-15 16:40:06.587: D/alsa_ucm(288): Setting mixer control: RX5 Digital Volume, value: 0

10-15 16:40:06.587: D/AudioUsbALSA(288): exitPlaybackThread, mproxypfdPlayback: -1

10-15 16:40:06.587: D/AudioUsbALSA(288): closeDevice handle 0x0

10-15 16:40:06.587: D/AudioUsbALSA(288): closeDevice handle 0x0

10-15 16:40:17.638: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4677) fps(213.812271)

10-15 16:40:17.698: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4644) fps(215.331604)

10-15 16:40:20.681: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4633) fps(215.842865)

10-15 16:40:21.111: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4611) fps(216.872696)

10-15 16:40:25.746: D/dalvikvm(698): GC_CONCURRENT freed 5829K, 41% free 23778K/39664K, paused 10ms+24ms, total 165ms

10-15 16:40:28.448: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:2.800000 hotplug_avg_load_dw: 74

10-15 16:40:28.448: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:243.000000

10-15 16:40:30.841: W/SystemClock(698): time going backwards: prev 16555345563411(ioctl) vs now 16555345441341(ioctl), tid=764

10-15 16:40:44.684: D/dalvikvm(698): GC_CONCURRENT freed 5302K, 41% free 23774K/39664K, paused 6ms+9ms, total 107ms

10-15 16:40:57.467: E/OMX-VDEC-1080P(288): set_frame_rate: frm_int(4577) fps(218.483719)

10-15 16:41:14.383: D/dalvikvm(698): GC_CONCURRENT freed 5371K, 41% free 23768K/39664K, paused 7ms+8ms, total 146ms

10-15 16:41:14.403: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:4.500000 hotplug_avg_load_dw: 89

10-15 16:41:14.403: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:41:14.403: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:41:14.403: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:922.000000

10-15 16:41:27.466: E/kickstart(862): Total bytes received so far: 48

10-15 16:41:27.466: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_HELLO

10-15 16:41:27.466: E/kickstart(862): EVENT: SENDING --> SAHARA_HELLO_RESPONSE

10-15 16:41:27.466: E/kickstart(862): EVENT: sahara_mode                         = 2

10-15 16:41:27.466: E/kickstart(862): EVENT: m_comm->sahara_hello_packet_rx.mode = 2

10-15 16:41:27.466: E/kickstart(862): EVENT: helloRx.mode                        = 2

10-15 16:41:27.466: E/kickstart(862): Total bytes received so far: 64

10-15 16:41:27.466: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_MEMORY_DEBUG

10-15 16:41:27.466: E/kickstart(862): Total bytes received so far: 116

10-15 16:41:27.466: E/kickstart(862): EVENT: 0x46980000, len=000C0000, "m9kefs1", ""

10-15 16:41:27.466: E/kickstart(862): EVENT: STATE &lt;-- SAHARA_WAIT_MEMORY_REGION

10-15 16:41:27.466: E/kickstart(862): EVENT: Saving "/dev/block/platform/msm_sdcc.1/by-name/m9kefs1"

10-15 16:41:27.526: E/kickstart(862): Total bytes received so far: 786548

10-15 16:41:27.526: E/kickstart(862): EVENT: Received: 786432 bytes

10-15 16:41:27.526: E/kickstart(862): EVENT: Writing to disk

10-15 16:41:27.526: E/kickstart(862): EVENT: Successfully wrote to disk

10-15 16:41:27.526: E/kickstart(862): Received file "m9kefs1"

10-15 16:41:27.576: E/kickstart(862): Sync finish Received file "m9kefs1"

10-15 16:41:27.576: E/kickstart(862): 786432 bytes transferred in 0.106s (7.10 MBps)

10-15 16:41:27.576: E/kickstart(862): EVENT: num_debug_entries not >=0

10-15 16:41:27.576: E/kickstart(862): Successfully downloaded files from target 

10-15 16:41:27.576: E/kickstart(862): EVENT: SENDING --> SAHARA_RESET

10-15 16:41:27.576: E/kickstart(862): Total bytes received so far: 786556

10-15 16:41:27.576: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_RESET_RESP

10-15 16:41:27.576: E/kickstart(862): Sahara protocol completed

10-15 16:41:27.576: E/kickstart(862): EVENT: STATE &lt;-- SAHARA_WAIT_HELLO

10-15 16:41:27.746: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:2.100000 hotplug_avg_load_dw: 79

10-15 16:41:27.746: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:244.000000

10-15 16:41:49.598: D/dalvikvm(698): GC_CONCURRENT freed 5339K, 41% free 23775K/39664K, paused 10ms+7ms, total 134ms

10-15 16:42:17.225: I/ActivityManager(698): Start proc com.cyanogenmod.lockclock for service com.cyanogenmod.lockclock/.weather.WeatherUpdateService: pid=18954 uid=10028 gids={50028, 3003, 1028}

10-15 16:42:17.865: D/WeatherXmlParser(18954): Weather updated: WeatherInfo for Santa Barbara@ Tue Oct 15 16:42:17 PDT 2013: Fair(34), temperature 29°C, low 11°, high 27°, humidity 14%, wind 11km/h at W

10-15 16:42:17.945: I/ActivityManager(698): No longer want com.google.android.apps.uploader (pid 13565): empty #17

10-15 16:42:24.021: D/dalvikvm(698): GC_CONCURRENT freed 5277K, 41% free 23770K/39664K, paused 8ms+11ms, total 106ms

10-15 16:42:35.983: W/ThrottleService(698): unable to find stats for iface rmnet0

10-15 16:42:59.476: D/dalvikvm(698): GC_CONCURRENT freed 5345K, 41% free 23770K/39664K, paused 6ms+13ms, total 168ms

10-15 16:43:02.098: E/kickstart(862): Total bytes received so far: 48

10-15 16:43:02.098: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_HELLO

10-15 16:43:02.098: E/kickstart(862): EVENT: SENDING --> SAHARA_HELLO_RESPONSE

10-15 16:43:02.098: E/kickstart(862): EVENT: sahara_mode                         = 2

10-15 16:43:02.098: E/kickstart(862): EVENT: m_comm->sahara_hello_packet_rx.mode = 2

10-15 16:43:02.098: E/kickstart(862): EVENT: helloRx.mode                        = 2

10-15 16:43:02.098: E/kickstart(862): Total bytes received so far: 64

10-15 16:43:02.098: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_MEMORY_DEBUG

10-15 16:43:02.108: E/kickstart(862): Total bytes received so far: 116

10-15 16:43:02.108: E/kickstart(862): EVENT: 0x46980000, len=000C0000, "m9kefs2", ""

10-15 16:43:02.108: E/kickstart(862): EVENT: STATE &lt;-- SAHARA_WAIT_MEMORY_REGION

10-15 16:43:02.108: E/kickstart(862): EVENT: Saving "/dev/block/platform/msm_sdcc.1/by-name/m9kefs2"

10-15 16:43:02.158: E/kickstart(862): Total bytes received so far: 786548

10-15 16:43:02.158: E/kickstart(862): EVENT: Received: 786432 bytes

10-15 16:43:02.158: E/kickstart(862): EVENT: Writing to disk

10-15 16:43:02.168: E/kickstart(862): EVENT: Successfully wrote to disk

10-15 16:43:02.168: E/kickstart(862): Received file "m9kefs2"

10-15 16:43:02.218: E/kickstart(862): Sync finish Received file "m9kefs2"

10-15 16:43:02.218: E/kickstart(862): 786432 bytes transferred in 0.113s (6.65 MBps)

10-15 16:43:02.218: E/kickstart(862): EVENT: num_debug_entries not >=0

10-15 16:43:02.218: E/kickstart(862): Successfully downloaded files from target 

10-15 16:43:02.218: E/kickstart(862): EVENT: SENDING --> SAHARA_RESET

10-15 16:43:02.218: E/kickstart(862): Total bytes received so far: 786556

10-15 16:43:02.218: E/kickstart(862): EVENT: RECEIVED &lt;-- SAHARA_RESET_RESP

10-15 16:43:02.218: E/kickstart(862): Sahara protocol completed

10-15 16:43:02.218: E/kickstart(862): EVENT: STATE &lt;-- SAHARA_WAIT_HELLO

10-15 16:43:17.563: W/SystemClock(698): time going backwards: prev 16722067121029(ioctl) vs now 16722066968441(ioctl), tid=764

10-15 16:43:34.610: D/dalvikvm(698): GC_CONCURRENT freed 5359K, 41% free 23772K/39664K, paused 9ms+9ms, total 113ms

10-15 16:43:36.452: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:3.900000 hotplug_avg_load_dw: 100

10-15 16:43:36.452: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:43:36.452: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:43:36.452: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:194.000000

10-15 16:44:09.965: D/dalvikvm(698): GC_CONCURRENT freed 5369K, 41% free 23779K/39664K, paused 8ms+8ms, total 103ms

10-15 16:44:09.965: D/dalvikvm(698): WAIT_FOR_CONCURRENT_GC blocked 30ms

10-15 16:44:10.605: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:2.800000 hotplug_avg_load_dw: 133

10-15 16:44:10.605: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:244.000000

10-15 16:44:12.707: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:4.100000 hotplug_avg_load_dw: 116

10-15 16:44:12.707: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:44:12.707: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:44:12.707: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:97.000000

10-15 16:44:14.008: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:1.700000 hotplug_avg_load_dw: 140

10-15 16:44:14.008: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:240.000000

10-15 16:44:14.759: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:4.900000 hotplug_avg_load_dw: 132

10-15 16:44:14.759: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:44:14.759: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:44:14.759: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:97.000000

10-15 16:44:15.360: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:2.300000 hotplug_avg_load_dw: 139

10-15 16:44:15.360: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:243.000000

10-15 16:44:15.560: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:3.900000 hotplug_avg_load_dw: 133

10-15 16:44:15.560: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:44:15.560: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:44:15.560: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:95.000000

10-15 16:44:16.361: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:2.500000 hotplug_avg_load_dw: 132

10-15 16:44:16.361: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:242.000000

10-15 16:44:16.661: E/MP-Decision(1385): num online cores: 3 reqd : 4 available : 4 rq_depth:3.700000 hotplug_avg_load_dw: 127

10-15 16:44:16.661: E/MP-Decision(1385): UP cpu:1 core_idx:1 Nw:1.900000 Tw:140 total_time_up:0.000000

10-15 16:44:16.661: E/MP-Decision(1385): UP cpu:2 core_idx:2 Nw:2.700000 Tw:90 total_time_up:0.000000

10-15 16:44:16.661: E/MP-Decision(1385): UP cpu:3 core_idx:3 Nw:3.500000 Tw:90 total_time_up:97.000000

10-15 16:44:20.605: E/MP-Decision(1385): num online cores: 4 reqd : 3 available : 4 rq_depth:1.700000 hotplug_avg_load_dw: 122

10-15 16:44:20.605: E/MP-Decision(1385): DOWN cpu:3 core_idx:3 Ns:3.100000 Ts:240 total_time_down:244.000000

10-15 16:44:20.615: W/ProcessStats(698): Skipping unknown process pid 19038

10-15 16:44:20.615: W/ProcessStats(698): Skipping unknown process pid 19041

Garbage collector entries in Logcat :

10-15 16:40:06.087: D/dalvikvm(698): WAIT_FOR_CONCURRENT_GC blocked 1ms

10-15 16:40:06.207: D/dalvikvm(698): GC_EXPLICIT freed 4120K, 39% free 24216K/39664K,   paused 7ms+9ms, total 117ms

10-15 16:40:25.746: D/dalvikvm(698): GC_CONCURRENT freed 5829K, 41% free 23778K/39664K, paused 10ms+24ms, total 165ms

10-15 16:40:44.684: D/dalvikvm(698): GC_CONCURRENT freed 5302K, 41% free 23774K/39664K, paused 6ms+9ms, total 107ms

10-15 16:41:14.383: D/dalvikvm(698): GC_CONCURRENT freed 5371K, 41% free 23768K/39664K, paused 7ms+8ms, total 146ms

10-15 16:41:49.598: D/dalvikvm(698): GC_CONCURRENT freed 5339K, 41% free 23775K/39664K, paused 10ms+7ms, total 134ms

10-15 16:42:24.021: D/dalvikvm(698): GC_CONCURRENT freed 5277K, 41% free 23770K/39664K, paused 8ms+11ms, total 106ms

10-15 16:42:59.476: D/dalvikvm(698): GC_CONCURRENT freed 5345K, 41% free 23770K/39664K, paused 6ms+13ms, total 168ms

10-15 16:43:34.610: D/dalvikvm(698): GC_CONCURRENT freed 5359K, 41% free 23772K/39664K, paused 9ms+9ms, total 113ms

10-15 16:44:09.965: D/dalvikvm(698): GC_CONCURRENT freed 5369K, 41% free 23779K/39664K, paused 8ms+8ms, total 103ms

10-15 16:44:09.965: D/dalvikvm(698): WAIT_FOR_CONCURRENT_GC blocked 30ms

10-15 16:44:24.389: D/dalvikvm(698): GC_EXPLICIT freed 3618K, 41% free 23768K/39664K, paused 12ms+11ms, total 123ms

1 | ... | 1732 | 1733 | 1734 | 1735 | 1736 | 1737 | 1738 | 1739 | 1740 | ... | 3210

Recherche avancée

Médias (3)

Elephants Dream - Cover of the soundtrack

Valkaama DVD Label

Publier une image simplement

Autres articles (73)

Initialisation de MediaSPIP (préconfiguration)

Le profil des utilisateurs

Configurer la prise en compte des langues

Sur d’autres sites (9628)

Anomalie #4128 (En cours) : Bug de génération de boucle avec les modèles Spip

Can I know which byte range to read from a remote mp4 file for FFMpeg to decode a keyframe ?

MediaCodec hardware decoder much slower with different server configuration ?

Se connecter

Navigation

Syndication

Boussole SPIP