Recherche avancée

Sur d’autres sites (6447)

• Video length missing in FLV converted by ffmpeg-php

  19 janvier 2013, par Andrew

  I'm converting MP4 videos to FLV using ffmpeg-php on my CentOS server (without intervention from flvtool2 because it's not installed).

  The FLV videos are created, but no player is capable of retrieving the video duration, this creates serious issues when trying to seek the video. I'm using the player created by Moyea's Flash Video MX Pro, but the problem also happens with other FLV players as well, so I'm sure that ffmpeg-php is not createing the FLV with the proper length data.

  My MP4 videos are compatible because ffmpeg-php CAN get the video length properly from then, yet it does not apply that length information into the FLV file. I assume flvtool2 is ONLY to retrieve meta-data and has nothing to do with the output FLV video length, let me know if this is correct.

  This command I use for conversion :

  $command = "ffmpeg -i myvideo.mp4 -ar 22050 -ab 64k -f flv -s 320x240 -y myvideo.flv";
  
  $result = @shell_exec($command);

  This is my ffmpeg-php version :

  FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  
    configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --incdir=/usr/include --extra-cflags=-fPIC --enable-libamr-nb --enable-libamr-wb --enable-libdirac --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-gpl --enable-nonfree --enable-postproc --enable-pthreads --enable-shared --enable-swscale --enable-x11grab
  
    libavutil     49.15. 0 / 49.15. 0
  
    libavcodec    52.20. 0 / 52.20. 0
  
    libavformat   52.31. 0 / 52.31. 0
  
    libavdevice   52. 1. 0 / 52. 1. 0
  
    libswscale     0. 7. 1 /  0. 7. 1
  
    libpostproc   51. 2. 0 / 51. 2. 0
  
    built on Jul 24 2009 01:40:27, gcc: 4.1.2 20080704 (Red Hat 4.1.2-44)

  Any help on this issue will be greatly appreciated.

• FFMPEG Segmenting skips when m3u8 changes file

  25 septembre 2012, par user792164

  I am attempting to segment a large video file in to segments. When streamed (even locally) by opening the m3u8 file it will jump forward in time by some period of time less than 1 second.

  The following commands are executed :

  First mp4 —> ts :

  ffmpeg -i input_file.mp4 -bsf:v h264_mp4toannexb -acodec libfaac -vcodec libx264 -f mpegts -threads 0 output.ts

  Then I split using :

  ffmpeg -i output.ts -vcodec copy -acodec copy -map 0 -f segment -segment_time 30 -segment_list output.m3u8 -segment_list_type m3u8 -segment_format mpegts output%03d.ts 

  Note : Changing segment time has no effect on issue.

  Generated manifest :

  #EXTM3U
  
  #EXT-X-VERSION:4
  
  #EXTINF:30.947578,
  
  output000.ts
  
  #EXTINF:30.155111,
  
  output001.ts
  
  ...
  
  #EXTINF:24.023989,
  
  output082.ts
  
  #EXT-X-TARGETDURATION:37
  
  #EXT-X-ENDLIST

  ---

  Meta Data :

  $> ffmpeg -version
  
  ffmpeg version git-2012-08-19-a93c221
  
  built on Aug 19 2012 13:18:58 with gcc 4.4.5 (Debian 4.4.5-8)
  
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib/ --mandir=/usr/share/man --extra-cflags='-O3 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions \ -fstack-protector --param=ssp-buffer-size=4 -mtune=generic' --enable-gpl --enable-shared --enable-nonfree --enable-version3 --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-pthreads --enable-libxvid --enable-postproc --enable-libgsm --enable-libspeex --enable-avfilter --disable-decoder=libdirac --enable-libfreetype --enable-libschroedinger --disable-decoder=libschroedinger --enable-libopenjpeg --disable-ffplay --disable-ffserver
  
  libavutil      51. 70.100 / 51. 70.100
  
  libavcodec     54. 53.100 / 54. 53.100
  
  libavformat    54. 25.104 / 54. 25.104
  
  libavdevice    54.  2.100 / 54.  2.100
  
  libavfilter     3. 11.101 /  3. 11.101
  
  libswscale      2.  1.101 /  2.  1.101
  
  libswresample   0. 15.100 /  0. 15.100
  
  libpostproc    52.  0.100 / 52.  0.100

  -

  $> ffprobe input_file.mp4
  
  
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input_file.mp4':
  
  Metadata:
  
  major_brand     : isom
  
  minor_version   : 1
  
  compatible_brands: isom
  
  creation_time   : 2011-09-08 11:43:25
  
  Duration: 00:41:31.00, start: 0.000000, bitrate: 1146 kb/s
  
  Stream #0.0(und): Video: h264 (High), yuv420p, 720x404 [PAR 1:1 DAR 180:101], 1015 kb/s,    23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc
  
  Metadata:
  
    creation_time   : 2011-09-08 11:43:25
  
  Stream #0.1(und): Audio: aac, 48000 Hz, stereo, s16, 124 kb/s
  
  Metadata:
  
    creation_time   : 2011-09-08 11:43:25

  -

  $> ffprobe output_file.ts
  
  Input #0, mpegts, from 'output_file.ts':
  
  Duration: 00:41:30.98, start: 1.400000, bitrate: 807 kb/s
  
  Program 1 
  
  Metadata:
  
    service_name    : Service01
  
    service_provider: FFmpeg
  
  Stream #0.0[0x100]: Video: h264 (High), yuv420p, 720x404 [PAR 1:1 DAR 180:101], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
  
  Stream #0.1[0x101](und): Audio: aac, 48000 Hz, stereo, s16, 141 kb/

  ---

  Is it possible to remove this jump, if so, what encoding parameters or incorrect assumptions have I made ? Thanks.

• Evolution #2881 (Fermé) : Table spip_meta et plugin champs extra

  3 mai 2013, par cedric -

  je pense que le bug concerne le plugin Champs extra qui devrait gérer ça, soit avec une table meta dédiée, soit en modifiant la taille des champs SQL. Mais il faut avoir conscience que charger toutes ces données à chaque hit dans les meta est dispendieux, alors qu’on en a besoin que lors du calcul/compilation d’une page, et dans l’espace privé.
  Cela plaide donc pour une table meta dédiée au plugin.
  Je ferme car étendre les champs SQL de spip_meta par defaut conduira a augmenter le volume de données stockées dans spip_meta et poser des pb de perf (données chargées à chaque hit). Il ne faut donc pas faire de stockage lourd dans spip_meta.