Recherche avancée

Sur d’autres sites (5135)

• Stream to Azure Media Service from ffmpeg, stream can not be played

  24 juillet 2015, par Simon

  i try to send a stream from my RaspberryPI with debian wheezy to the AzureMediaService.
  I followed the instructions of this nice post.
  http://gtrifonov.com/2015/07/02/streaming-live-video-from-raspberrypi-to-azure-media-services/

  After a lot of trouble with the ffmpeg and libx264 builds i think i have it working now, to stream to the rtmp urls.

  INGESTURI="rtmp://office-klokklokmediastream.channel.mediaservices.windows.net:1935/live/3e541bc149754ebd975b95ec3583c949/mystream1"
  
  ffmpeg -framerate 30 -r 30 -s 640x480 -i /dev/video0 -vcodec libx264 -preset ultrafast -acodec libfaac -ab 48k -b:v 500k -maxrate 500k -bufsize 500k -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -f flv $INGESTURI

  But when i try to watch the link in azure portal publish link or with the azure amsmediaplayer it tells me (i have reseted the channel already) :

  "The video could not be loaded, either because the server or network failed or because the format is not supported."

  The public stream url is :

  http://klokklokmediastream.streaming.mediaservices.windows.net/30c3920e-420a-4d33-8938-e79d0db240ff/c9fd3479-0d4b-4643-a3f9-5fd5831985d0.ism/Manifest

  In the linux shell i see the following output while streaming, looks for me as send stream is working :

  "root@raspberrypi:/home/pi/klokklok# ./azure_ffmpeg
  
  ffmpeg version N-73894-g830d3a0 Copyright (c) 2000-2015 the FFmpeg developers
  
    built with gcc 4.6 (Debian 4.6.3-14+rpi1)
  
    configuration: --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree
  
    libavutil      54. 28.100 / 54. 28.100
  
    libavcodec     56. 50.101 / 56. 50.101
  
    libavformat    56. 40.101 / 56. 40.101
  
    libavdevice    56.  4.100 / 56.  4.100
  
    libavfilter     5. 25.100 /  5. 25.100
  
    libswscale      3.  1.101 /  3.  1.101
  
    libswresample   1.  2.101 /  1.  2.101
  
    libpostproc    53.  3.100 / 53.  3.100
  
  Input #0, video4linux2,v4l2, from '/dev/video0':
  
    Duration: N/A, start: -140462028.282167, bitrate: 110592 kb/s
  
      Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 640x480, 110592 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
  
  [libx264 @ 0x3321920] using cpu capabilities: none!
  
  [libx264 @ 0x3321920] profile Constrained Baseline, level 3.0
  
  [libx264 @ 0x3321920] 264 - core 146 r2538 121396c - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=60 keyint_min=31 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=cbr mbtree=0 bitrate=500 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=500 vbv_bufsize=500 nal_hrd=none filler=0 ip_ratio=1.40 aq=0
  
  Output #0, flv, to 'rtmp://office-klokklokmediastream.channel.mediaservices.windows.net:1935/live/3e501bc149754ebd975b95ec3583c949/mystream1':
  
    Metadata:
  
      encoder         : Lavf56.40.101
  
      Stream #0:0: Video: h264 (libx264) ([7][0][0][0] / 0x0007), yuv420p, 640x480, q=-1--1, 500 kb/s, 30 fps, 1k tbn, 30 tbc
  
      Metadata:
  
        encoder         : Lavc56.50.101 libx264
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
  
  Press [q] to stop, [?] for help
  
  DTS 140462610481701, next:33333 st:0 invalid dropping
  
  PTS 140462610481701, next:33333 invalid dropping st:0
  
  DTS 140462610515017, next:66666 st:0 invalid dropping
  
  PTS 140462610515017, next:66666 invalid dropping st:0
  
  DTS 140462610548333, next:99999 st:0 invalid dropping
  
  PTS 140462610548333, next:99999 invalid dropping st:0
  
  frame=    4 fps=0.0 q=31.0 size=       7kB time=00:00:00.10 bitrate= 554.6kbits/DTS 140462610581650, next:133332 st:0 invalid dropping
  
  PTS 140462610581650, next:133332 invalid dropping st:0
  
  DTS 140462610614965, next:166665 st:0 invalid dropping
  
  PTS 140462610614965, next:166665 invalid dropping st:0
  
  frame=    6 fps=5.1 q=29.0 size=       9kB time=00:00:00.16 bitrate= 462.5kbits/DTS 140462610648281, next:199998 st:0 invalid dropping
  
  PTS 140462610648281, next:199998 invalid dropping st:0
  
  DTS 140462610681598, next:233331 st:0 invalid dropping
  
  PTS 140462610681598, next:233331 invalid dropping st:0
  
  DTS 140462610714914, next:266664 st:0 invalid dropping
  
  PTS 140462610714914, next:266664 invalid dropping st:0
  
  frame=   14 fps=4.6 q=23.0 size=      21kB time=00:00:00.43 bitrate= 396.0kbits/DTS 140462610914810, next:466662 st:0 invalid dropping
  
  PTS 140462610914810, next:466662 invalid dropping st:0
  
  [flv @ 0x3320ae0] Failed to update header with correct duration.
  
  [flv @ 0x3320ae0] Failed to update header with correct filesize.
  
  frame=   15 fps=3.9 q=22.0 Lsize=      25kB time=00:00:00.50 bitrate= 407.8kbits/s
  
  video:24kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.373589%
  
  [libx264 @ 0x3321920] frame I:1     Avg QP:31.00  size:  2777
  
  [libx264 @ 0x3321920] frame P:14    Avg QP:26.68  size:  1531
  
  [libx264 @ 0x3321920] mb I  I16..4: 100.0%  0.0%  0.0%
  
  [libx264 @ 0x3321920] mb P  I16..4: 12.4%  0.0%  0.0%  P16..4: 29.7%  0.0%  0.0%  0.0%  0.0%    skip:57.9%
  
  [libx264 @ 0x3321920] coded y,uvDC,uvAC intra: 6.3% 13.9% 0.5% inter: 5.7% 21.4% 0.1%
  
  [libx264 @ 0x3321920] i16 v,h,dc,p: 52% 17% 16% 14%
  
  [libx264 @ 0x3321920] i8c dc,h,v,p: 63% 14% 20%  3%
  
  [libx264 @ 0x3321920] kb/s:387.47
  
  Exiting normally, received signal 2.
  
  "

  I cant find a solution for that so thanks a lot for any advice.

• images->video->web canvas : RGB/YUV issues

  5 février 2016, par nrob

  We’ve written an web app which :

  1. takes 3D, time dependent weather data
  2. tiles each 3D time point to make a 2D frame (written out as a png image)
  3. stitches these frames together into a video (using ffmpeg/avconv)
  4. streams this video into a web app
  5. polls the canvas for frames
  6. sends the frames to the GPU where they are converted back to 3D and ray traced

  You can see the app here, code here and you can see the data video here

  Currently the pngs are written as RGB images, the video codec is in YUV and getting frames from the canvas returns RGB. As such there is a significant loss of information due to the conversion between image spaces.

  Does anyone have suggestions what is the best way round this ?

  I’ve tried a bunch of RGB video codecs, but I can’t get any to work, and I don’t know if the web browser will support it anyway. Can anyone suggest a good RGB codec (both lossy and lossless would be great)

  Also, is it possible to write to YUV images/read them from a video canvas in HTML5 ?

  Ultimately, I don’t even want anything to do with images/videos, I’m just hacking the codecs to stream/compress large animated 3D data volumes

• Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

  23 juillet 2015, par Peet du

  Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

  Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
  Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

  Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
  Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

  SUGGESTION
  Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
  Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
  Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

  Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

  SUGGESTION 2
  L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

  SUGGESTION 3
  même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

  • cvtautosave_formulaire_charger
  • cvtautosave_formulaire_traiter

  en _dist ?