Recherche avancée

Sur d’autres sites (2410)

• Concatenate / Join MP4 files using ffmpeg and windows command line batch NOT LINUX

  17 juillet 2014, par julesverne

  I’ve written a batch script that attempts to take a generic introductory title video (MP4) that runs for 12 seconds and attaches it to the beginning of 4 other MP4 videos (same video but each has a different language audio track)

  According to ffmpeg syntax here : http://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20concatenate%20%28join,%20merge%29%20media%20files the concat demuxer needs to be run from a text file that looks like this :

  # this is a comment
  
  file '/path/to/file1'
  
  file '/path/to/file2'
  
  file '/path/to/file3'

  I believe everything in my script up until the point of joining the files appears to be working correctly. But I get this error :

  [concat @ 04177d00] Line 2: unknown keyword ''C:\Users\Joe\1May\session3\readyforfinalconversion\frenchfile.mp4'
  
  filelistFrench.txt: Invalid data found when processing input
  
  [concat @ 03b70a80] Line 2: unknown keyword ''C:\Users\Joe\1May\session3\readyforfinalconversion\spanishfile.mp4'
  
  filelistSpanish.txt: Invalid data found when processing input
  
  [concat @ 0211b960] Line 2: unknown keyword ''C:\Users\Joe\1May\session3\readyforfinalconversion\basquefile.mp4'
  
  filelistBasque.txt: Invalid data found when processing input
  
  [concat @ 03a20a80] Line 2: unknown keyword ''C:\Users\Joe\1May\session3\readyforfinalconversion\Englishfile.mp4'
  
  filelistEnglish.txt: Invalid data found when processing input

  I believe the issue lies in the text file I’m creating. Please excuse my n00b ignorance, but sometimes new script makers like myself get confused about developer jargon and may take things literally.

  So when I look at that example text file they gave, am I correct in thinking THIS is what my text file should look like ?

  # this is a comment
  
  Titlefile.mp4 'C:\Users\Joe\1May\session3\readyforfinalconversion\Titlefile.mp4'
  
  Englishfile.mp4 'C:\Users\Joe\1May\session3\readyforfinalconversion\Englishfile.mp4'

  Again, am I being too literal ? are the quotations correct ? Are the slashes correct ? In the example they provide the slashes in the path are / instead of normal windows \ . I’ll provide the entire script in case it helps.

  @echo off
  
  
  
  setlocal EnableDelayedExpansion
  
  
  
  rem Create an array of languages
  
  set i=0
  
  for %%a in (French Spanish Basque English) do (
  
     set /A i+=1
  
     set term[!i!]=%%a
  
  )
  
  
  
  rem Get the title video file name from user
  
  
  
  set /p titlevideofilename=What is the title video file 
  
  
  
  name?
  
  
  
  rem create a path variable for the title video file
  
  
  
  set pathtotitlevideo=%~dp0%titlevideofilename%
  
  
  
  rem Get the names of the different language video files to append to the title video
  
  rem create a path variable for each different language video files
  
  
  
  for /L %%i in (1,1,4) do (
  
     set /p language[%%i]=what is the name of the !term
  
  
  
  [%%i]! file you want to append after the title video?
  
     set pathtofile[%%i]=%~dp0!language[%%i]!
  
  )
  
  
  
  rem create data file for ffmpeg based on variable data
  
  
  
  for /L %%i in (1,1,4) do (
  
      echo # this is a comment>>filelist!term[%
  
  
  
  %i]!.txt
  
      echo file '%pathtotitlevideo%'>>filelist!term[%
  
  
  
  %i]!.txt
  
      echo file '!pathtofile[%%i]!'>>filelist!term[%
  
  
  
  %i]!.txt
  
  )
  
  
  
  cls
  
  
  
  rem join files using ffmpeg concat option
  
  
  
  for /L %%i in (1,1,4) do (
  
     c:\ffmpeg\ffmpeg\bin\ffmpeg.exe -loglevel error -f 
  
  
  
  concat -i filelist!term[%%i]!.txt -c copy !language[%
  
  
  
  %i]!.!term[%%i]!.withtitle.mp4
  
  )
  
  
  
  endlocal
  
  
  
  :eof
  
  exit

  EDIT
  Thanks to @foxidrive making me look at the simplicity of it... it occurred to me that Apparently I wasn’t being literal enough. I made these 3 changes and script works perfectly now
  1 : "file" in there example literally meant the word "file"
  2 : needed the use of single quotes not double quotes as it shows in there example.
  3 : Used "\" instead of "/" as they have in there example.

  So NOW my code to create the text files looks like this :

  rem create data file for ffmpeg based on variable data
  
  
  
  for /L %%i in (1,1,4) do (
  
      echo # this is a comment>>filelist!term[%
  
  
  
  %i]!.txt
  
      echo file '%pathtotitlevideo%'>>filelist!term[%
  
  
  
  %i]!.txt
  
      echo file '!pathtofile[%%i]!'>>filelist!term[%
  
  
  
  %i]!.txt
  
  )

  So NOW my text file looks like this :

  # this is a comment    
  
  file 'C:\Users\Joe\1May\session3\readyforfinalconversion\Titlefile.mp4'
  
  file 'C:\Users\Joe\1May\session3\readyforfinalconversion\Englishfile.mp4'

• Transcoding Modern Formats

  17 août 2014

  I’ve noticed that this blog still gets a decent amount of traffic, particularly to some of the older articles about transcoding. Since I’ve been working on a tool in this space recently, I thought I’d write something up in case it helps folks unravel how to think about transcoding these days.

  The tool I’ve been working on is EditReady, a transcoding app for the Mac. But why do you want to transcode in the first place ?

  Dailies

  After a day of shooting, there are a lot of people who need to see the footage from the day. Most of these folks aren’t equipped with editing suites or viewing stations - they want to view footage on their desktop or mobile device. That can be a problem if you’re shooting ProRes or similar.

  Converting ProRes, DNxHD or MPEG2 footage with EditReady to H.264 is fast and easy. With bulk metadata editing and custom file naming, the management of all the files from the set becomes simpler and more trackable.

  One common workflow would be to drop all the footage from a given shot into EditReady. Use the "set metadata for all" command to attach a consistent reel name to all of the clips. Do some quick spot-checks on the footage using the built in player to make sure it’s what you expect. Use the filename builder to tag all the footage with the reel name and the file creation date. Then, select the H.264 preset and hit convert. Now anyone who needs the footage can easily take the proxies with them on the go, without needing special codecs or players, and regardless of whether they’re working on a PC, a Mac, or even a mobile device.

  If your production is being shot in the Log space, you can use the LUT feature in EditReady to give your viewers a more traditional "video levels" daily. Just load a basic Log to Video Levels LUT for the batch, and your converted files will more closely resemble graded footage.

  Mezzanine Formats

  Even though many modern post production tools can work natively with H.264 from a GoPro or iPhone, there are a variety of downsides to that type of workflow. First and foremost is performance. When you’re working with H.264 in an editor or color correction tool, your computer has to constantly work to decompress the H.264 footage. Those are CPU cycles that aren’t being spent generating effects, responding to user interface clicks, or drawing your previews. Even apps that endeavor to support H.264 natively often get bogged down, or have trouble with all of the "flavors" of H.264 that are in use. For example, mixing and matching H.264 from a GoPro with H.264 from a mobile phone often leads to hiccups or instability.

  By using EditReady to batch transcode all of your footage to a format like ProRes or DNxHD, you get great performance throughout your post production pipeline, and more importantly, you get consistent performance. Since you’ll generally be exporting these formats from other parts of your pipeline as well - getting ProRes effects shots for example - you don’t have to worry about mix-and-match problems cropping up late in the production process either.

  Just like with dailies, the ability to apply bulk or custom metadata to your footage during your initial ingest also makes management easier for the rest of your production. It also makes your final output faster - transcoding from H.264 to another format is generally slower than transcoding from a mezzanine format. Nothing takes the fun out of finishing a project like watching an "exporting" bar endlessly creep along.

  Modernization

  The video industry has gone through a lot of digital formats over the last 20 years. As Mac OS X has been upgraded over the years, it’s gotten harder to play some of those old formats. There’s a lot of irreplaceable footage stored in formats like Sorensen Video, Apple Intermediate Codec, or Apple Animation. It’s important that this footage be moved to a modern format like ProRes or H.264 before it becomes totally unplayable by modern computers. Because EditReady contains a robust, flexible backend with legacy support, you can bring this footage in, select a modern format, and click convert. Back when I started this blog, we were mostly talking about DV and HDV, with a bit of Apple Intermediate Codec mixed in. If you’ve still got footage like that around, it’s time to bring it forward !

  Output

  Finally, the powerful H.264 transcoding pipeline in EditReady means you generate beautiful deliverable H.264 more rapidly than ever. Just drop in your final, edited ProRes, DNxHD, or even uncompressed footage and generate a high quality H.264 for delivery. It’s never been this easy !

  See for yourself

  We released a free trial of EditReady so you can give it a shot yourself. Or drop me a line if you have questions.

• avcodec/ass : accurately preserve colours

  13 novembre 2022, par Oneric

  avcodec/ass : accurately preserve colours
  Colour values used in ASS files without a "YCbCr Matrix" header set to
  
  "None" are subject to colour mangling, due to how ASS was historically
  
  conceived. A more in-depth description can be found in the documetation
  
  inside libass' public ass_types.h header. The important part is, if this
  
  header is not set to "None", the final output colours can deviate from
  
  the literal value specified in the file. When converting from non-ASS
  
  formats we do not want any colour shift to happen, so let's set the
  
  appropiate header.
  NB : ffmpeg's subtitle filter, does not follow libass' documentation
  
  regarding colour mangling, thus hiding the bug. Anything based on
  
  VSFilter, XySubFilter or e.g. mpv do and might show the issue.
  
  (Of course native ASS subs, which _do_ rely on colour mangling won't
  
   work properly with the subtitle filter, but this can be fixed another
  
   time)
  

  • [DH] libavcodec/ass.c
  • [DH] tests/ref/fate/sub-aqtitle
  • [DH] tests/ref/fate/sub-cc
  • [DH] tests/ref/fate/sub-cc-realtime
  • [DH] tests/ref/fate/sub-cc-scte20
  • [DH] tests/ref/fate/sub-charenc
  • [DH] tests/ref/fate/sub-jacosub
  • [DH] tests/ref/fate/sub-microdvd
  • [DH] tests/ref/fate/sub-movtext
  • [DH] tests/ref/fate/sub-mpl2
  • [DH] tests/ref/fate/sub-mpsub
  • [DH] tests/ref/fate/sub-mpsub-frames
  • [DH] tests/ref/fate/sub-pjs
  • [DH] tests/ref/fate/sub-realtext
  • [DH] tests/ref/fate/sub-sami
  • [DH] tests/ref/fate/sub-sami2
  • [DH] tests/ref/fate/sub-scc
  • [DH] tests/ref/fate/sub-srt
  • [DH] tests/ref/fate/sub-srt-badsyntax
  • [DH] tests/ref/fate/sub-stl
  • [DH] tests/ref/fate/sub-subviewer
  • [DH] tests/ref/fate/sub-subviewer1
  • [DH] tests/ref/fate/sub-vplayer
  • [DH] tests/ref/fate/sub-webvtt
  • [DH] tests/ref/fate/sub-webvtt2