Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
Entraide Linux Autres OS Linux Debian Ffmpeg ou avconv gèle Debian

Ffmpeg ou avconv gèle Debian

12 réponses
Avatar
Alain Rpnpif
Bonjour,

La commande "ffmpeg -i unfilm.wmv unfilm.mkv" g=C3=A8le Debian apr=C3=A8s
environ 3 min. Plus rien ne r=C3=A9agit que ce soit sous Xorg ou en console
pure. C'est le seul film qui fait =C3=A7a.
ffmpeg derni=C3=A8re version (2.1.4) ou avconv de Wheezy ont le m=C3=AAme e=
ffet.

Que ce soit avec le noyau Linux de wheezy (3.2.0-4-686-pae) ou avec le
3.12.14 de Linus.
ffmpeg -i unfilm.wmv
ffmpeg version 2.1.4 Copyright (c) 2000-2014 the FFmpeg developers
built on Mar 29 2014 18:17:03 with gcc 4.7 (Debian 4.7.2-5)
configuration: --arch=3Di386 --enable-runtime-cpudetect
--libdir=3D/usr/local/lib/ --prefix=3D/usr/local --enable-bzlib
--enable-libdc1394 --enable-libfreetype --enable-frei0r --enable-gnutls
--enable-libgsm --enable-libmp3lame --enable-librtmp
--enable-libopenjpeg --enable-libspeex --enable-libtheora
--enable-libvorbis --enable-zlib --enable-gpl --enable-postproc
--enable-swscale --enable-x11grab --enable-libvpx --enable-libx264
--enable-libxvid --shlibdir=3D/usr/local/lib/i686/cmov --cpu=3Di686
--enable-shared --disable-static=20
libavutil 52. 48.101 / 52. 48.101
libavcodec 55. 39.101 / 55. 39.101=20
libavformat 55. 19.104 / 55. 19.104=20
libavdevice 55. 5.100 / 55. 5.100=20
libavfilter 3.90.100 / 3. 90.100=20
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104=20
libpostproc 52. 3.100 / 52.3.100=20
Guessed Channel Layout for Input Stream #0.0 : stereo=20
Input #0, asf, from 'unfilm.wmv':=20
Metadata:
Application : Windows Movie Maker 2.0.3312.0
WMFSDKVersion : 9.00.00.4506 WMFSDKNeeded : 0.0.0.0000
artist : AK=20
title : unfilm.wmv
IsVBR : 0 DeviceConformanceTemplate: MP@ML
WM/WMADRCPeakReference: 32767
WM/WMADRCAverageReference: 12717
Duration: 00:08:57.84, start: 0.000000, bitrate: 556 kb/s
Stream #0:0(fre): Audio: wmav2 (a[1][0][0] / 0x0161), 44100
Hz, stereo, fltp, 128 kb/s=20
Stream #0:1(fre): Video: wmv3 (Main) (WMV3 / 0x33564D57),
yuv420p, 640x480, 1000 kb/s, SAR 1:1 DAR
4:3, 25 tbr, 1k tbn, 1k tbc

Aucun message d'erreur.
Comme tout est bloqu=C3=A9, c'est impossible d'avoir des logs. La seule
solution est l'extinction du PC.

Je n'ai jamais ce genre de probl=C3=A8me avec les autres programmes ni avec
les autres films, sachant que cet ancien PC est utilis=C3=A9 de tr=C3=A8s
fr=C3=A9quemment.

Auriez-vous une id=C3=A9e pour comprendre ce qui se passe ?

Merci de m'avoir lu.
--=20
Alain Rpnpif

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140329185409.C77CD1051AC@chro.home
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Josselin Poisbeau
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-677399511-1396123422=:24507
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On Sat, 29 Mar 2014, Alain Rpnpif wrote:

Je n'ai jamais ce genre de problème avec les autres programmes ni avec
les autres films, sachant que cet ancien PC est utilisé de trè s
fréquemment.

Auriez-vous une idée pour comprendre ce qui se passe ?



Absolument aucune. :D

Plus sérieusement, as-tu essayé de convertir ce même fichi er à partir
d'un autre ordinateur, avec une autre version de ffmpeg, ou encore avec
un autre encodeur (de mémoire, il me semble que mencoder se base sur
autre chose que ffmeg, mais je peux me tromper) ?

Cela permettra certainement d'avoir une vision plus précise du
problème, à savoir si le souci vient de ta version de ffmpeg, d e ton
ordinateur, ou bien du fichier d'origine lui même.

Cordialement,

--
Josselin Poisbeau
--8323329-677399511-1396123422=:24507--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Bzzz
On Sat, 29 Mar 2014 19:54:09 +0100
Alain Rpnpif wrote:

Auriez-vous une idée pour comprendre ce qui se passe ?



On ne le dira jamais assez: weendauze c'est caca.

Tu pourrais recompiler le source en ajoutant des printf()
de contrôle; ça peut prendre un certain temps, mais tu vas
fatalement finir par tomber sur l'endroit où ça pêche.

Après, c'est soit un bug, soit autre chose… (comme le passage
de little à big indian pour la taille du fichier, par ex.)

--
Mauditation: j'ai rien à faire de toute la soirée
Reta: tu voulais pas aller au ciné ?
Mauditation: je crois pas, trop de choses à faire

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Dominique Dumont
On Saturday 29 March 2014 19:54:09 Alain Rpnpif wrote:
La commande "ffmpeg -i unfilm.wmv unfilm.mkv" gèle Debian après
environ 3 min. Plus rien ne réagit que ce soit sous Xorg ou en cons ole
pure. C'est le seul film qui fait ça.



Ca donne l'impression que toute la RAM est utilisée. Tu peux vérifi er ce qui
est consommé avec free, top ou gkrellm.

Si c'est une fuite mémoire, on tombe dans le cas d'un bug plus classi que qui
peux être remonté directement à l'équipe «upstream» qui gè re ffmpeg.

A+

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Alain Rpnpif
Le 29 mars 2014, Dominique Dumont a écrit :

On Saturday 29 March 2014 19:54:09 Alain Rpnpif wrote:
> La commande "ffmpeg -i unfilm.wmv unfilm.mkv" gèle Debian aprà ¨s
> environ 3 min. Plus rien ne réagit que ce soit sous Xorg ou en con sole
> pure. C'est le seul film qui fait ça.

Ca donne l'impression que toute la RAM est utilisée. Tu peux vé rifier ce qui
est consommé avec free, top ou gkrellm.

Si c'est une fuite mémoire, on tombe dans le cas d'un bug plus class ique qui
peux être remonté directement à l'équipe «upstre am» qui gère ffmpeg.



Un indice : ça bloque toujours à peu près même endroit du film en
transcodage.

À Bzzz,
Je l'ai déjà compilé deux fois au cas où j'aurais fait une erreur à la
première.
Bonne idée les printf. Dès que j'ai une demi-journée, j'essa ie
ça.
Le CPU ne supporte pas SSE2. Normalement, ffmpeg détecte ça
automatiquement. C'est ce qui pourrait faire planter ?

PS : ce n'est pas moi qui l'ai fabriqué avec avec MSW Maker (beurk).
Je veux justement le convertir dans un format plus durable C'est
pourtant un film simple : un diaporama sonorisé avec des transitions.

À Dominique,
Pas de fuite mémoire.

À Josselin,
Même problème avec mencoder... tiens, tiens.
Le processus est à 100% CPU me dit top à ce moment-là. Ce qu i fait un
total > 100% avec les autres tâches !?
Mais, je viens d'essayer sur un autre ordinateur, portable celui-là,
avec la même version de Debian. Pas de gel ou plantage, seulement un
échauffement plus important (60°C).
Donc le premier PC surchaufferait pendant le transcodage (63 à 64  °C)
d'après le greffon de capteurs de Xfce.
La surchauffe relative pourrait geler le PC ? le monde à l'envers ;-).

Merci de votre aide.
--
Alain Rpnpif

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Bzzz
On Sun, 30 Mar 2014 14:27:22 +0200
Alain Rpnpif wrote:

Un indice : ça bloque toujours à peu près même endroi t du film en
transcodage.



Déjà dit, mais ça ne règle pas le PB de savoir ce qui g énère le
blocage.

Le CPU ne supporte pas SSE2. Normalement, ffmpeg détecte ça
automatiquement. C'est ce qui pourrait faire planter ?



Nan.

PS : ce n'est pas moi qui l'ai fabriqué avec avec MSW Maker
(beurk). Je veux justement le convertir dans un format plus
durable C'est pourtant un film simple : un diaporama sonorisé avec
des transitions.



Vi, mais on déjà vu assez foireux de la part de m$ (détection
d'un autre DOS que le sien et plante en règle de himem, chgt
inopiné de specs dans le protocol cifs, histoire de planter
samba, backdoors, récemment suppression d'un soft normal
au prétexte que "la base des détections" n'avait pas étà ©
remise à jour, etc).

Je n'accuse pas, je parle juste d'un passé augurant mal d'un
futur quelque peu transparent et ce, dans tous les domaines…

À Dominique,
Pas de fuite mémoire.



Tu aurais un memory leak, le kernel aurait flingué des processes
pour respirer un peu.

Le processus est à 100% CPU me dit top à ce moment-là. Ce qui fait
un total > 100% avec les autres tâches !?



Normal: top considère que: 1 core == 100%.

Mais, je viens d'essayer sur un autre ordinateur, portable
celui-là, avec la même version de Debian. Pas de gel ou plantag e,
seulement un échauffement plus important (60°C).



Vu la Qté de travail, c'est normal que ça chauffe.

Maintenant, qu'il ne plante pas avec la même version de ffmpeg,
c'est anormal.
Je dirais que tu as des PBs avec l'exe ou l'une/toutes
ses libs; donc plutôt un PB de HD ou de corruption de RAM.

La surchauffe relative pourrait geler le PC ? le monde à
l'envers ;-).



C'est bleu-suppo, mais @64°C il y peu de chances que ça soit à §a.

Histoire de voir si ton system est vraiment bloqué, tu peux
* lancer la manip dans un xterm,
* passer sur un autre xterm et lancer un truc du genre:
watch -n5 ps aux, déjà tu verras s'il bloque ou pas.

--
No matter where I go, the place is always called "here".

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
maderios
On 03/30/2014 02:27 PM, Alain Rpnpif wrote:

PS : ce n'est pas moi qui l'ai fabriqué avec avec MSW Maker (beurk).
Je veux justement le convertir dans un format plus durable C'est
pourtant un film simple : un diaporama sonorisé avec des transitions.



Si tel est l'objectif laisse tomber ffmpeg et utilise gstreamer
https://packages.debian.org/jessie/transmageddon
--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
BERTRAND Joël
Bzzz a écrit :
On Sat, 29 Mar 2014 19:54:09 +0100
Alain Rpnpif wrote:

Auriez-vous une idée pour comprendre ce qui se passe ?



On ne le dira jamais assez: weendauze c'est caca.

Tu pourrais recompiler le source en ajoutant des printf()
de contrôle; ça peut prendre un certain temps, mais tu vas
fatalement finir par tomber sur l'endroit où ça pêche.



Sauf s'il y a un problème de concurrence où les printf() risquent fort
de masquer le problème. Maintenant, si le blocage est un blocage hard,
ça vaudrait le coup de faire tourner la chose en l'instrumentant
sérieusement (par exemple avec valgrind ou
purify-je-sais-ça-pue-c'est-pas-libre) et je ne suis pas sûr qu'un
programme en mode utilisateur puisse bloquer le noyau sans un bug
sérieux dans le noyau ou la libc.

Après, c'est soit un bug, soit autre chose… (comme le passage
de little à big indian pour la taille du fichier, par ex.)



Je ne vois pas trop le rapport avec un plantage complet de la machine.
Ça devrait se terminer brutalement au mieux par une erreur récupérée par
le programme, au pire par un coup de pied aux fesses façon segfault.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Bzzz
On Sun, 30 Mar 2014 23:37:55 +0200
BERTRAND Joël wrote:

Sauf s'il y a un problème de concurrence où les printf()
risquent fort de masquer le problème. Maintenant, si le blocage



Et alors, il peut utiliser une VAR de comptage ≠ par appel
si besoin est ou une seule protégée par un sémaphore.

De toute façon, tout cela est caduque puisque ça tourne
correctement sur la même branche mai un autre µ; donc soit
HD, soit RAM, soit les 2, voire une surchauffe mais c'est peu
probable.

--
<ptilu> hep, tu crois que les geek, quand ils meurent, ils vont aller au
paradis du geek ? => une espèce de Sillicon Valley dans la p laine
d'Hyrule, cablée en fibre optique o/
<Odin> No, quand un geek meurt, il va à la corbeille.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
BERTRAND Joël
Bzzz a écrit :
On Sun, 30 Mar 2014 23:37:55 +0200
BERTRAND Joël wrote:

Sauf s'il y a un problème de concurrence où les printf()
risquent fort de masquer le problème. Maintenant, si le blocage



Et alors, il peut utiliser une VAR de comptage ≠ par appel
si besoin est ou une seule protégée par un sémaphore.



Même pas. Si c'est un problème de concurrence, changer le code va
provoquer des symptômes différents.

De toute façon, tout cela est caduque puisque ça tourne
correctement sur la même branche mai un autre µ; donc soit
HD, soit RAM, soit les 2, voire une surchauffe mais c'est peu
probable.



Soit instruction non disponible sur le processeur et TRAP géré
incorrectement par le noyau. Il serait surprenant qu'avec de la mémoire
HS, le truc plante toujours au même endroit avec le même outil. Idem
pour le disque. Ça devrait gratouiller, cracher des erreurs, mais pas
planter totalement.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Alain Rpnpif
Le 31 mars 2014, BERTRAND Joël a écrit :

Soit instruction non disponible sur le processeur et TRAP géré
incorrectement par le noyau. Il serait surprenant qu'avec de la mémo ire
HS, le truc plante toujours au même endroit avec le même outil. Idem
pour le disque. Ça devrait gratouiller, cracher des erreurs, mais pa s
planter totalement.



À mon avis aussi mais de non-expert, une incompatibilité
ibstruction-processeur, c'est la piste la plus probable (sauf
surchauffe brutale ??? parce que j'ai un doute sur le refroidissement).
J'essaierai de recompiler sans les extensions spécifiques au µP.

J'ai fait les 4 premiers tests de memtest et tout baigne (j'ai déjà   eu
dans le passé de la RAM pourrie et je vois ce que cela fait).

À suivre.
--
Alain Rpnpif

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
1 2