Recherche avancée

Sur d’autres sites (9304)

• ffmpeg - HLS stream audio error between segmets

  2 février 2019, par Carl

  I have a huge amount of mp4 files to create HLS segments from, more than 200 hours worth of files. I don’t see the point of re-encoding these videos because they are already in mp4 format. I’m using the following command which copies the video into segments instead of encoding it again.

  ffmpeg -i filename.mp4 -codec: copy -start_number 0 -hls_time 4 -hls_list_size 0 -f hls filename.m3u8

  The problem is when it comes to stitching these segments, I’m getting micro audio errors between segments. It’s hard to explain but imagine somebody turning audio off for 0.1 seconds. I doesn’t happen in all of the segments but in 20%-30% of them. Is there anything I can do stop these errors from popping up apart from reencoding all the videos. There are no problems with video btw.

  Here’s media info from one of the files :

  General
  Complete name : C :\video_test\video_file.mp4
  Format : MPEG-4
  Format profile : Base Media / Version 2
  Codec ID : mp42 (isom/iso2/avc1/mp41/mp42)
  File size : 45.7 MiB
  Duration : 7 min 34 s
  Overall bit rate mode : Variable
  Overall bit rate : 844 kb/s
  Writing application : Lavf53.32.100
  

  Video
  ID : 1
  Format : AVC
  Format/Info : Advanced Video Codec
  Format profile : High@L4
  Format settings, CABAC : Yes
  Format settings, RefFrames : 8 frames
  Codec ID : avc1
  Codec ID/Info : Advanced Video Coding
  Duration : 7 min 34 s
  Bit rate : 767 kb/s
  Width : 1 280 pixels
  Height : 720 pixels
  Display aspect ratio : 16:9
  Frame rate mode : Constant
  Frame rate : 30.000 FPS
  Color space : YUV
  Chroma subsampling : 4:2:0
  Bit depth : 8 bits
  Scan type : Progressive
  Bits/(Pixel*Frame) : 0.028
  Stream size : 41.5 MiB (91%)
  Writing library : x264 core 136
  Encoding settings : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=6 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=48 / lookahead_threads=5 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=60 / keyint_min=30 / scenecut=0 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

  Audio
  ID : 2
  Format : AAC
  Format/Info : Advanced Audio Codec
  Format profile : LC
  Codec ID : 40
  Duration : 7 min 34 s
  Bit rate mode : Variable
  Bit rate : 72.0 kb/s
  Maximum bit rate : 96.0 kb/s
  Channel(s) : 2 channels
  Channel positions : Front : L R
  Sampling rate : 44.1 kHz
  Frame rate : 43.066 FPS (1024 SPF)
  Compression mode : Lossy
  Stream size : 3.92 MiB (9%)
  Language : English
  Default : Yes
  Alternate group : 1
  

  Edit : I just tried copying video and reencoding the audio with the following command but problem still persists.

  ffmpeg -i filename.mp4 -vcodec copy -c:a aac -ar 48000 -b:a 128k -start_number 0 -hls_time 4 -hls_list_size 0  -f hls filename.m3u8

• MP3 files created using FFmpeg are not starting playback in browser immediately. Is there any major difference between FFmpeg and AVCONV ?

  23 janvier 2019, par AR5

  I am working on a website that streams music. We recently changed server from Debian (with avconv) to a Centos7 (with FFmpeg) server.
  The mp3 files created on Debian server start playback on browser (I have tested Chrome and Firefox) start almost at the same time they start loading into the browser (I used Network tab on Developer Tools to monitor this)

  Now after the switch to Centos/FFmpeg server, the files being created on this new server are displaying a strange behavior. They only start playback after about 1MB is loaded into the browser.

  I have used identical settings for converting original file into MP3 in both AVCONV and FFmpeg but the files created using FFmpeg are showing this issue. Is there something that might be causing such an issue ? Are there differences in terms of audio conversion between AVCONV and FFmpeg ?

  I have already tried

  I first found that the files created on old server (Debian/Avconv) were VBR (variable bitrate) and the ones created on new server were CBR (constant bitrate), so I tried switching to VBR but the issue still persisted.

  I checked the mp3 files using MediaInfo app and there seems to be no difference between the files.

  I also checked if both files were being served as 206 Partial Content and they both are indeed.

  I am trying to create mp3 files using FFmpeg that work exactly like the ones created before using avconv

  I am trying to make the streaming site work on the new server but the mp3 files created using FFmpeg are not playing back correctly as compared to the ones created on the old server. I am trying to figure out what I might be doing wrong ? or if there is a difference between avconv and FFmpeg that is causing this issue.

  I am really stuck on this issue, any help will be really appreciated.

  ---

  Edit

  I don’t have access to old server anymore so I couldn’t retrieve the log output of avconv. The command that I was using was as follows :

  avconv -y -i "/test/Track 01.mp3" -ac 2 -ar 44100 -acodec libmp3lame -b:a 128k "/test/Track 01 (converted).mp3"

  Here is the command and log output from new server :

  ffmpeg -y -i "/test/Track 01.mp3" -ac 2 -ar 44100 -acodec libmp3lame -b:a 128k "/test/Track 01 (converted).mp3"
  
  ffmpeg version 2.8.15 Copyright (c) 2000-2018 the FFmpeg developers
  
    built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
  
    configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' --extra-ldflags='-Wl,-z,relro ' --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-version3 --enable-bzlib --disable-crystalhd --enable-gnutls --enable-ladspa --enable-libass --enable-libcdio --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libx264 --enable-libx265 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
  
    libavutil      54. 31.100 / 54. 31.100
  
    libavcodec     56. 60.100 / 56. 60.100
  
    libavformat    56. 40.101 / 56. 40.101
  
    libavdevice    56.  4.100 / 56.  4.100
  
    libavfilter     5. 40.101 /  5. 40.101
  
    libavresample   2.  1.  0 /  2.  1.  0
  
    libswscale      3.  1.101 /  3.  1.101
  
    libswresample   1.  2.101 /  1.  2.101
  
    libpostproc    53.  3.100 / 53.  3.100
  
  [mp3 @ 0xd60be0] Skipping 0 bytes of junk at 240044.
  
  Input #0, mp3, from '/test/Track 01.mp3':
  
    Metadata:
  
      album           : Future Hndrxx Presents: The WIZRD
  
      artist          : Future
  
      genre           : Hip-Hop
  
      title           : Never Stop
  
      track           : 1
  
      lyrics-eng      : rgf.is
  
      WEB SITE        : rgf.is
  
      TAGGINGTIME     : rgf.is
  
      WEB             : rgf.is
  
      date            : 2019
  
      encoder         : Lavf56.40.101
  
    Duration: 00:04:51.40, start: 0.025056, bitrate: 121 kb/s
  
      Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 114 kb/s
  
      Metadata:
  
        encoder         : Lavc56.60
  
      Stream #0:1: Video: png, rgb24(pc), 333x333 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
  
      Metadata:
  
        comment         : Cover (front)
  
  [mp3 @ 0xd66ec0] Frame rate very high for a muxer not efficiently supporting it.
  
  Please consider specifying a lower framerate, a different muxer or -vsync 2
  
  Output #0, mp3, to '/test/Track 01 (converted).mp3':
  
    Metadata:
  
      TALB            : Future Hndrxx Presents: The WIZRD
  
      TPE1            : Future
  
      TCON            : Hip-Hop
  
      TIT2            : Never Stop
  
      TRCK            : 1
  
      lyrics-eng      : rgf.is
  
      WEB SITE        : rgf.is
  
      TAGGINGTIME     : rgf.is
  
      WEB             : rgf.is
  
      TDRC            : 2019
  
      TSSE            : Lavf56.40.101
  
      Stream #0:0: Video: png, rgb24, 333x333 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 90k fps, 90k tbn, 90k tbc
  
      Metadata:
  
        comment         : Cover (front)
  
        encoder         : Lavc56.60.100 png
  
      Stream #0:1: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p, 128 kb/s
  
      Metadata:
  
        encoder         : Lavc56.60.100 libmp3lame
  
  Stream mapping:
  
    Stream #0:1 -> #0:0 (png (native) -> png (native))
  
    Stream #0:0 -> #0:1 (mp3 (native) -> mp3 (libmp3lame))
  
  Press [q] to stop, [?] for help
  
  [libmp3lame @ 0xd9b0c0] Trying to remove 1152 samples, but the queue is emptys/s
  
  frame=    1 fps=0.1 q=-0.0 Lsize=    4788kB time=00:04:51.39 bitrate= 134.6kbits/s
  
  video:234kB audio:4553kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.014809%

  Samples of MP3 files

  I have uploaded samples of mp3 files created using both avconv and FFmpeg. Please find these here : https://drive.google.com/drive/folders/1gRTmMM2iSK0VWQ4Zaf_iBNQe5laFJl08?usp=sharing

• Heroku django weird tempfile behavior

  13 février 2019, par BenFire

  I’m writing a django application, where, a user records a message, the message is converted with FFMPEG and uploaded to a FS,now, FFMPEG doesn’t allow file overwrite, so i’m creating a new file and than replacing the old one before inserting it my filesystem. so basically :

  The file is recorded in the front-end -> sent to the backend and stored as a tempfile (automatically by django) -> the files gets converted -> the file is uploaded to the fs.

  (the file is converted from around 2mb to 200kb, which is an indicator to if the file was converted)

  now, to replace the original file, I use shutil.move(), and when i run it on my system, and then I look in my fs, the file sure is only 200kb, but when i push the same code to Heroku, i do the same operation, when look in the fs I see that the new file is still 2mb, also, I know the conversion was done from the server logs, whitch means that the file replacing failed but only on Heroku, am i missing something ?