Recherche avancée

Sur d’autres sites (9868)

• Join 8 mono channels into 7.1 audio stream

  10 juin 2020, par Rafal B

  I'm trying to join 8 mono channels into 7.1 channels layout :

  



  ffmpeg -i L.ac3 -i R.ac3 -i C.ac3 -i Sub.ac3 -i BL.ac3 -i BR.ac3 -i SL.ac3 -i SR.ac3 -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a][6:a][7:a]join=inputs=8:channel_layout=7.1[a]"
-map "[a]" final-output.ac3


  



  but I'm getting :

  



  Stream mapping:
  Stream #0:0 (ac3) -> join:input0
  Stream #1:0 (ac3) -> join:input1
  Stream #2:0 (ac3) -> join:input2
  Stream #3:0 (ac3) -> join:input3
  Stream #4:0 (ac3) -> join:input4
  Stream #5:0 (ac3) -> join:input5
  Stream #6:0 (ac3) -> join:input6
  Stream #7:0 (ac3) -> join:input7
  join -> Stream #0:0 (ac3)
Press [q] to stop, [?] for help
Output #0, ac3, to 'final-output.ac3':
  Metadata:
    encoder         : Lavf58.29.100
    Stream #0:0: Audio: ac3, 48000 Hz, **5.1(side)**, fltp, 640 kb/s (default)
    Metadata:
      encoder         : Lavc58.54.100 ac3


  



  Why the output file is 5.1(side) ?

  



  Audio
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Commercial name                          : Dolby Digital
Duration                                 : 54 min 5 s
Bit rate mode                            : Constant
Bit rate                                 : 640 kb/s
Channel(s)                               : 6 channels
Channel layout                           : L R C LFE Ls Rs
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 SPF)
Compression mode                         : Lossy
Stream size                              : 248 MiB (100%)
Service kind                             : Complete Main


  



  I did not found anything that would explain this behavior.
I'm using latest ffmpeg and tried different methods : join, amerge. Always output file is 5.1(side)

  


• ffmpeg : Converting animated GIF files to video while upscaling produces a file with inaccurate colors

  14 juin 2020, par Metamoran

  I apologize if this is a dumb question, but even after using the search function I have not seen anyone asking about this.

  



  I'm trying to both 
(1) : Convert some low-resolution animated GIF files (pixel art in particular) to video, and
(2) : Upscale them at the same time, using nearest-neighbor to preserve the hard edges.

  



  ffmpeg does everything with no warnings or errors whatsoever, but the end result's colors look off. If I convert without upscaling, the color accuracy is preserved. I have tried both using and NOT using "palettegen", but it does not make a difference. For brevity, I'm only pasting the lines with palettegen in them. The end results are the same either way.

  



  This is what I've been using for upscaling :

  



  ffmpeg -i input.gif -c:v libx264 -b:v 10000K -y -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse,scale=2*iw:2*ih:flags=neighbor" output.mp4


  



  This is what I used for testing conversion (with no upscaling) :

  



  ffmpeg -i input.gif -c:v libx264 -b:v 10000K -y -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.mp4


  



  Here's the input file :

  



  Original animated GIF file

  



  Here's a screenshot of how the final video looks if I don't upscale (colors look exactly like in the input file) :

  



  Screenshot - Final - No Upscaling

  



  And here's the result if I upscale (2x Nearest-Neighbor upscaling, with the screenshot downsized 50% to make comparison easier. Colors were not altered during the process.) :

  



  Screenshot - Final - 2x Upscaling (Nearest-Neighbor) [Downsized]

  



  Folder with all relevant files :
Google Drive

  



  Is there something I'm missing ? Or is there some sort of technical limitation, a step that will alter the colors of the video no matter what I try ? I'm not technically inclined, I'd like to know if that is the case. Thank you for your time.

  


• avformat/dhav : fix backward scanning for get_duration and optimize seeking

  21 mars, par Justin Ruggles

  avformat/dhav : fix backward scanning for get_duration and optimize seeking
  The backwards scanning done for incomplete final packets should not
  
  assume a specific alignment at the end of the file. Truncated files
  
  result in hundreds of thousands of seeks if the final packet does not
  
  fall on a specific byte boundary, which can be extremely slow.
  
  For example, with HTTP, each backwards seek results in a separate
  
  HTTP request.
  This changes the scanning to check for the end tag 1 byte at a time
  
  and buffers the last 1 MiB to avoid additional seek operations.
  Co-authored-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
  
  Signed-off-by : Justin Ruggles <justinr@vimeo.com>
  
  Signed-off-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
  

  • [DH] libavformat/dhav.c