Recherche avancée

Sur d’autres sites (7995)

• Proprietary codecs on Linux. What is legal ?

  17 octobre 2016, par George Eco

  So, assuming we got a distribution without proprietary codecs installed.
  Let’s take Linux Mint for example. I want to store and playback wav and ogg format sounds, either by using my own software, or by using another developer’s software. So far so good right ?

  Imagine now that we have the following scenario. For some reason, I wanna playback a file that is either an mp4 or mp3 or mpeg or any other format, made by proprietary codecs. Instantly, I will need a codec for these formats.

  I read somewhere that Fluendo sells solutions for "legal codec usage" for linux distros.
  URL of fluendo : http://www.fluendo.com/en/

  So here comes the questions :

  Using VLC and ffmpeg is enough for me to convert a file to an ogg or ogv so I can playback a song or a video using an open format. You can also playback playback files made by proprietary formats. But are VLC and ffmpeg legal to use, to playback such files made by proprietary codecs ? For example, ss VLC codecs okay to be used without paying anyone for mp4 playback ? Is it okay to convert a file from mp4 to ogv ?
  If not, are there any legal and open source and free (as in freedom) codecs around that can solve the issue, or does someone have to pay a product, to be ethically correct, to the developers of the proprietaty codecs ?

  Note that I do not ask for Windows, since codec licenses are included to the price of the operating system. I ask exclusively for a free linux distribution.

• avformat/dashdec, hls : Update correct pointer to AVDictionary

  7 septembre 2020, par Andreas Rheinhardt

  avformat/dashdec, hls : Update correct pointer to AVDictionary
  open_url() in the DASH as well in the hls demuxer share a common bug :
  
  They modify an AVDictionary (i.e. set a new entry) given to them as
  
  AVDictionary *, yet if this new entry leads to reallocation and
  
  relocation of the AVDictionary, the caller's pointer will become
  
  dangling, leading to use-after-frees. So pass an AVDictionary **.
  (With the current implementation of AVDictionary the above can only
  
  happen if the AVDictionary was empty initially (in which case the
  
  new AVDictionary leaks) ; furthermore if the I/O is ordinary (i.e. opened
  
  by avio_open2() or ffio_open_whitelist()), the dict is never empty (it
  
  contains an rw_timeout entry from save_avio_options()). So this issue
  
  could only happen if the caller sets a nondefault io_open callback, but
  
  no AVIOContext (the AVFMT_FLAG_CUSTOM_IO flag won't be set in this
  
  case). In case of the HLS demuxer, it was also necessary that setting
  
  the "seekable" entry failed. Yet one should simply not rely on internals
  
  of the AVDict API.)
  Reviewed-by : Steven Liu <lq@chinaffmpeg.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/dashdec.c
  • [DH] libavformat/hls.c

• First Frame of SaveVideo playing longer, and last frame playing shortly

  19 décembre 2018, par Ricardo Alonso Esparza Gamez

  I’m using SaveVideo to create an animation based on different ggplots.
  Here’s what I am doing :

  saveVideo({for(i in 1:12){p <- ggplot()+...etc,video.name = "months.mp4")

  And these are my animation options :

  ani.options(interval=1.5,ani.width=1280,ani.dev = function(...){png(res=75*2.5,...)},ani.height=720, other.opts = '-analyzeduration 2M -probesize 1M')

  On the published video, the first frame lasts for like 5 seconds, then the other frames play normally, until the last frame which goes really quickly (less than 1 second). I have played around with different analyzeduration and probesize options with no results. Any idea how to solve this ?
  Thanks !