Recherche avancée

Sur d’autres sites (8232)

• Concat multiple (self-generated) videos using ffmpeg on raspbian linux

  25 février 2016, par Thomas Kekeisen

  I am a very talented sleep talker, so I decided to write a solution that records the things I talk at night to make funny videos with subtitles of it. The project is nearly done, but I got a big problem with concating videos I generated before.

  The video parts are generated from single png frames using this command :

  ffmpeg -y -framerate 15 -i "${images_file_path}" -c:v libx264 -r 30 -pix_fmt yuv420p "${video_file_path}"

  Then the sound is added using this command (got this from #9049970 and #11779490) :

  ffmpeg -y -i "${video_file_path}" -i "${mp3_file_path}" -map 0:v -map 1:a -vcodec copy -acodec copy -shortest "${final_video_file_path}"

  All this is causing no problems so far, but I think it may be relevant to know how the videos are generated. I can watch all this and get valid video and sound - the full source code of this first part can be found here.

  Now I added a feature that is able to generate "full videos" containing a title and a various number of previously generated "video parts" using this command :

  ffmpeg -f concat -i "${video_list_path}" -filter_complex "${filter_string} concat=n=${input_file_counter}:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" "${full_video_path}"

  But something is wrong with it and I get this error :

  Invalid file index 1 in filtergraph description [0:v:0] [1:v:0] [2:v:0] [2:a:0] [3:v:0] [4:v:0] [4:a:0] [5:v:0] [6:v:0] [6:a:0] [7:v:0] concat=n=8:v=1:a=1 [v] [a].

  The full output is :

  ffmpeg version N-77213-g7c1c453 Copyright (c) 2000-2015 the FFmpeg developers
  
    built with gcc 4.9.2 (Raspbian 4.9.2-10)
  
    configuration: --enable-shared --enable-gpl --prefix=/usr --enable-nonfree --enable-libmp3lame --enable-libfaac --enable-libx264 --enable-version3 --disable-mmx
  
    libavutil      55. 10.100 / 55. 10.100
  
    libavcodec     57. 17.100 / 57. 17.100
  
    libavformat    57. 20.100 / 57. 20.100
  
    libavdevice    57.  0.100 / 57.  0.100
  
    libavfilter     6. 20.100 /  6. 20.100
  
    libswscale      4.  0.100 /  4.  0.100
  
    libswresample   2.  0.101 /  2.  0.101
  
    libpostproc    54.  0.100 / 54.  0.100
  
  [mov,mp4,m4a,3gp,3g2,mj2 @ 0xc2e900] Auto-inserting h264_mp4toannexb bitstream filter
  
  Input #0, concat, from '/usr/sleeptalk/records-rendered/3enguzpuu2gw0ogk8wkko/videos.txt':
  
    Duration: N/A, start: 0.000000, bitrate: 61 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 58 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 2 kb/s
  
      Metadata:
  
        handler_name    : SoundHandler
  
  Invalid file index 1 in filtergraph description [0:v:0] [1:v:0] [2:v:0] [2:a:0] [3:v:0] [4:v:0] [4:a:0] [5:v:0] [6:v:0] [6:a:0] [7:v:0] concat=n=8:v=1:a=1 [v] [a].

  I also wrote a test case so you can reproduce this on your local machine. Download the files from my dropbox. Also, the full script that renders the "final move" can be found here.

  Would be great to get an Idea, got struggle to fix this the last two days.

• avformat/icodec : ico probe with unknown data

  16 février 2016, par Mark Harris

  avformat/icodec : ico probe with unknown data
  Fix cases where unknown data (data beyond p->buf_size) could produce a
  
  higher ico probe score than if the unknown data was known and valid.
  
  For example :
  
      Header :  OK, 2 frames
  
      Frame 0 : Unknown (offset points beyond end of probe buffer)
  
      Frame 1 : Invalid
  
  Previously this example had a score of 25, even though the score would
  
  be 1 if the unknown frame was known to be valid or 0 if it was known
  
  to be invalid.  For this example the score is now 1.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/icodec.c

• lavc/ccaption_dec : do not ignore repeated character commands

  15 février 2016, par Aman Gupta

  lavc/ccaption_dec : do not ignore repeated character commands
  control codes in a cc stream can be repeated, and must be ignored.
  
  however, repeated characters must not be ignored. the code attempted to
  
  wipe prev_cmd in handle_char to allow repeated characters to be
  
  processed, but prev_cmd would previously get reset _after_ handle_char()
  i also moved the prev_cmd reset out from handle_char() so it can be
  
  re-used for special character sets, which _must_ be ignored when
  
  repeated.
  

  • [DH] libavcodec/ccaption_dec.c