Recherche avancée

Sur d’autres sites (10004)

• Why does subprocess.run() have unexpected behavior in try else block ?

  27 novembre 2023, par Nikita Savenkov

  Trying to make a "to mp4" converter function using ffmpeg that is going to convert a file to mp4, delete the original file, and return True or False for specific conditions.
But I get some unexpected behavior of a subprocess.

  


  Initially I used this construction :

  


  def to_mp4_converter(file):

    input_file = file
    output_file = f"{re.sub(r'\..+$', "", file)}.mp4"

    try:
        subprocess.run(['ffmpeg', '-i', input_file, output_file])
    except subprocess.SubprocessError as e:
        print(f"Subprocess Error: {e}")
        return False
    else:
        try:
            os.remove(path=file)
        except OSError as e:
            print(f"Can't remove {file} file: {e}")
        finally:
            return True


  


  Original file is removed, but output file is half of the expected size and quality of video is low.

  


  But if I place subprocess.run() and os.remove() into separate try else blocks like that :

  


  def to_mp4_converter(file):

    input_file = file
    output_file = f"{re.sub(r'\..+$', "", file)}.mp4"

    try:
        subprocess.run(['ffmpeg', '-i', input_file, output_file])
    except subprocess.SubprocessError as e:
        print(f"Subprocess Error: {e}")
        return False
    else:
        pass

    try:
        os.remove(path=file)
    except OSError as e:
        print(f"Can't remove {file} file: {e}")
    finally:
        return True


  


  Everything works fine.

  


  Isn't subprocess.run() should be a blocking operation, so the else statement in 1st example is unreachable until conversion is done ?

  


• avfilter/vf_showpalette : Fix double-free of AVFilterFormats on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/vf_showpalette : Fix double-free of AVFilterFormats on error
  The query_formats function of the showpalette filter tries to allocate
  
  two lists of formats which on success are attached to more permanent objects
  
  (AVFilterLinks) for storage afterwards. If attaching a list to an
  
  AVFilterLink succeeds, the link becomes one (in this case the only one)
  
  of the owners of the list. Yet if attaching the first list to its link
  
  succeeds and attaching the second list fails, both lists were manually
  
  freed, which means that the first link's pointer to the first list
  
  becomes dangling and there will be a double-free when the first link is
  
  cleaned up automatically.
  This commit fixes this by removing the custom free code ; this will
  
  temporarily add a leaking codepath (if attaching a list to a link fails,
  
  the list will leak), but this will be fixed shortly by making sure that
  
  an AVFilterFormats without owner will be automatically freed when
  
  attaching it to an AVFilterLink fails. Notice at most one list leaks
  
  because as of this commit a new list is only allocated after the old list
  
  has been successfully attached to a link.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/vf_showpalette.c

• avfilter/af_amix : Fix double-free of AVFilterChannelLayouts on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/af_amix : Fix double-free of AVFilterChannelLayouts on error
  The query_formats function of the amix filter tries to allocate a list
  
  of channel layouts which are attached to more permanent objects
  
  (an AVFilter's links) for storage afterwards on success. If attaching
  
  a list to a link succeeds, the link becomes one of the common owners
  
  of the list. Yet if a list has been successfully attached to links (or if
  
  there were no links to attach it to in which case
  
  ff_set_common_channel_layouts() already frees the list) and an error
  
  happens lateron, the list was manually freed, which is wrong, because
  
  the list has either already been freed or it is owned by its links in
  
  which case these links' pointers to their list will become dangling and
  
  there will be double-frees/uses-after-free when these links are cleaned
  
  up automatically.
  This commit fixes this by removing the custom freeing code ; this is made
  
  possible by using the list in ff_set_common_channel_layouts() directly
  
  after its allocation (without anything that can fail in between).
  Notice that ff_set_common_channel_layouts() is buggy itself which can
  
  lead to double-frees on error. This is not fixed in this commit.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/af_amix.c