Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #60858 > unrolled thread

using ffmpeg command line with python's subprocess module

Started byiMath <redstone-cold@163.com>
First post2013-12-02 03:34 -0800
Last post2013-12-03 08:25 +1100
Articles 11 on this page of 31 — 11 participants

Back to article view | Back to comp.lang.python


Contents

  using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-02 03:34 -0800
    Re: using ffmpeg command line with python's subprocess module Chris Angelico <rosuav@gmail.com> - 2013-12-02 22:40 +1100
    Re: using ffmpeg command line with python's subprocess module Ben Finney <ben+python@benfinney.id.au> - 2013-12-03 08:19 +1100
      Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-02 17:15 -0800
        Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-02 17:42 -0800
          Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-03 17:42 -0800
          Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-03 17:42 -0800
            Re: using ffmpeg command line with python's subprocess module Andreas Perstinger <andipersti@gmail.com> - 2013-12-04 10:38 +0100
              Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-05 22:23 -0800
                Re: using ffmpeg command line with python's subprocess module Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-06 09:23 +0000
                  Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-06 06:52 -0800
                    Re: using ffmpeg command line with python's subprocess module Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-06 15:12 +0000
                      Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-06 07:15 -0800
                    Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-06 07:13 -0800
                    Re: using ffmpeg command line with python's subprocess module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-06 15:34 +0000
                      Re: using ffmpeg command line with python's subprocess module Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-06 15:53 +0000
                        Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-06 08:19 -0800
                          Re: using ffmpeg command line with python's subprocess module Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-06 16:25 +0000
                            Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-06 08:45 -0800
                      Re: using ffmpeg command line with python's subprocess module MRAB <python@mrabarnett.plus.com> - 2013-12-06 16:41 +0000
                        Re: using ffmpeg command line with python's subprocess module rusi <rustompmody@gmail.com> - 2013-12-06 08:53 -0800
                          Re: using ffmpeg command line with python's subprocess module Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-07 13:01 +1300
                Re: using ffmpeg command line with python's subprocess module Ned Batchelder <ned@nedbatchelder.com> - 2013-12-06 06:31 -0500
            Re: using ffmpeg command line with python's subprocess module Chris Angelico <rosuav@gmail.com> - 2013-12-04 21:51 +1100
              Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-06 06:54 -0800
                Re: using ffmpeg command line with python's subprocess module Chris Angelico <rosuav@gmail.com> - 2013-12-07 01:59 +1100
                  Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-09 01:04 -0800
                    Re: using ffmpeg command line with python's subprocess module Andreas Perstinger <andipersti@gmail.com> - 2013-12-10 13:59 +0100
      Re: using ffmpeg command line with python's subprocess module Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-12-03 10:33 +0100
        Re: using ffmpeg command line with python's subprocess module iMath <redstone-cold@163.com> - 2013-12-03 05:59 -0800
    Re: using ffmpeg command line with python's subprocess module Chris Angelico <rosuav@gmail.com> - 2013-12-03 08:25 +1100

Page 2 of 2 — ← Prev page 1 [2]


#61171

Fromrusi <rustompmody@gmail.com>
Date2013-12-06 08:53 -0800
Message-ID<a8c3126b-fecf-4571-8122-cea5c88ec1b2@googlegroups.com>
In reply to#61166
On Friday, December 6, 2013 10:11:04 PM UTC+5:30, MRAB wrote:
> On 06/12/2013 15:34, Steven D'Aprano wrote:
> > On Fri, 06 Dec 2013 06:52:48 -0800, iMath wrote:
> >> yes ,I am a native Chinese speaker.I always post question by Google
> >> Group not through  email ,is there something wrong with it ? your
> >> english is a little strange to me .

> > Mark is writing in fake old-English style, the way people think English
> > was spoken a thousand years ago. I don't know why he did that. Perhaps he
> > thought it was amusing.
> [snip]

> You're exaggerating. It's more like 500 years ago. :-)

I was going to say the same until I noticed the "the way people think English
was spoken..."

That makes it unarguable -- surely there are some people who (wrongly) think so?

[toc] | [prev] | [next] | [standalone]


#61196

FromGregory Ewing <greg.ewing@canterbury.ac.nz>
Date2013-12-07 13:01 +1300
Message-ID<bgf6pvF6vijU1@mid.individual.net>
In reply to#61171
rusi wrote:
> On Friday, December 6, 2013 10:11:04 PM UTC+5:30, MRAB wrote:
> 
>>You're exaggerating. It's more like 500 years ago. :-)
> 
> I was going to say the same until I noticed the "the way people think English
> was spoken..."
> 
> That makes it unarguable -- surely there are some people who (wrongly) think so?

Probably. They're surprisingly far off, though. Here's
a sample of actual 1000-year-old English:

http://answers.yahoo.com/question/index?qid=20100314001840AAygUaq

-- 
Greg

[toc] | [prev] | [next] | [standalone]


#61135

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-12-06 06:31 -0500
Message-ID<mailman.3640.1386329505.18130.python-list@python.org>
In reply to#61114
On 12/6/13 4:23 AM, Mark Lawrence wrote:
> On 06/12/2013 06:23, iMath wrote:
>
> Dearest iMath, wouldst thou be kind enough to partake of obtaining some
> type of email client that dost not sendeth double spaced data into this
> most illustrious of mailing lists/newsgroups.  Thanking thee for thine
> participation in my most humble of requests.  I do remain your most
> obedient servant.
>

iMath seems to be a native Chinese speaker.  I think this message, 
though amusing, will be baffling and won't have any effect...

--Ned.

[toc] | [prev] | [next] | [standalone]


#61008

FromChris Angelico <rosuav@gmail.com>
Date2013-12-04 21:51 +1100
Message-ID<mailman.3554.1386154312.18130.python-list@python.org>
In reply to#60986
On Wed, Dec 4, 2013 at 8:38 PM, Andreas Perstinger <andipersti@gmail.com> wrote:
> "fp" is a file object, but subprocess expects a list of strings as
> its first argument.

More fundamentally: The subprocess's arguments must include the *name*
of the file. This means you can't use TemporaryFile at all, as it's
not guaranteed to return an object that actually has a file name.

There's another problem, too, and that's that you're not closing the
file before expecting the subprocess to open it. And once you do that,
you'll find that the file no longer exists once it's been closed. In
fact, you'll need to research the tempfile module a bit to be able to
do what you want here; rather than spoon-feed you an exact solution,
I'll just say that there is one, and it can be found here:

http://docs.python.org/3.3/library/tempfile.html

ChrisA

[toc] | [prev] | [next] | [standalone]


#61154

FromiMath <redstone-cold@163.com>
Date2013-12-06 06:54 -0800
Message-ID<60f2e393-658c-4e18-85b1-fc7d0b07ddb4@googlegroups.com>
In reply to#61008
在 2013年12月4日星期三UTC+8下午6时51分49秒,Chris Angelico写道:
> On Wed, Dec 4, 2013 at 8:38 PM, Andreas Perstinger <andipersti@gmail.com> wrote:
> 
> > "fp" is a file object, but subprocess expects a list of strings as
> 
> > its first argument.
> 
> 
> 
> More fundamentally: The subprocess's arguments must include the *name*
> 
> of the file. This means you can't use TemporaryFile at all, as it's
> 
> not guaranteed to return an object that actually has a file name.
> 
> 
> 
> There's another problem, too, and that's that you're not closing the
> 
> file before expecting the subprocess to open it. And once you do that,
> 
> you'll find that the file no longer exists once it's been closed. In
> 
> fact, you'll need to research the tempfile module a bit to be able to
> 
> do what you want here; rather than spoon-feed you an exact solution,
> 
> I'll just say that there is one, and it can be found here:
> 
> 
> 
> http://docs.python.org/3.3/library/tempfile.html
> 
> 
> 
> ChrisA

I think you mean I should create a temporary file by NamedTemporaryFile(). After tried it many times, I found there is nearly no convenience in creating a temporary file or a persistent one here ,because we couldn't use the temporary file while it has not been closed ,so we couldn't depend on the convenience of letting the temporary file automatically delete itself when closing, we have to delete it later by os.remove() after it has been used in that command line.

code without the with statement is here ,but it is wrong ,it shows this line 

c:\docume~1\admini~1\locals~1\temp\tmp0d8959: Invalid data found when processing input


    fp=tempfile.NamedTemporaryFile(delete=False)
    fp.write(("file '"+fileName1+"'\n").encode('utf-8')) 
    fp.write(("file '"+fileName2+"'\n").encode('utf-8')) 
    

    subprocess.call(['ffmpeg', '-f', 'concat','-i',fp.name, '-c',  'copy', fileName])
    fp.close()

[toc] | [prev] | [next] | [standalone]


#61155

FromChris Angelico <rosuav@gmail.com>
Date2013-12-07 01:59 +1100
Message-ID<mailman.3652.1386341991.18130.python-list@python.org>
In reply to#61154
On Sat, Dec 7, 2013 at 1:54 AM, iMath <redstone-cold@163.com> wrote:
>     fp=tempfile.NamedTemporaryFile(delete=False)
>     fp.write(("file '"+fileName1+"'\n").encode('utf-8'))
>     fp.write(("file '"+fileName2+"'\n").encode('utf-8'))
>
>
>     subprocess.call(['ffmpeg', '-f', 'concat','-i',fp.name, '-c',  'copy', fileName])
>     fp.close()

You need to close the file before getting the other process to use it.
Otherwise, it may not be able to open the file at all, and even if it
can, you might find that not all the data has been written.

But congrats! You have successfully found the points I was directing
you to. Yes, I was hinting that you need NamedTemporaryFile, the .name
attribute, and delete=False. Good job!

ChrisA

[toc] | [prev] | [next] | [standalone]


#61372

FromiMath <redstone-cold@163.com>
Date2013-12-09 01:04 -0800
Message-ID<6030eab0-17f7-4b7b-b057-d0889031b3d2@googlegroups.com>
In reply to#61155
在 2013年12月6日星期五UTC+8下午10时59分43秒,Chris Angelico写道:
> On Sat, Dec 7, 2013 at 1:54 AM, iMath <redstone-cold@163.com> wrote:
> 
> >     fp=tempfile.NamedTemporaryFile(delete=False)
> 
> >     fp.write(("file '"+fileName1+"'\n").encode('utf-8'))
> 
> >     fp.write(("file '"+fileName2+"'\n").encode('utf-8'))
> 
> >
> 
> >
> 
> >     subprocess.call(['ffmpeg', '-f', 'concat','-i',fp.name, '-c',  'copy', fileName])
> 
> >     fp.close()
> 
> 
> 
> You need to close the file before getting the other process to use it.
> 
> Otherwise, it may not be able to open the file at all, and even if it
> 
> can, you might find that not all the data has been written.
> 
> 
> 
> But congrats! You have successfully found the points I was directing
> 
> you to. Yes, I was hinting that you need NamedTemporaryFile, the .name
> 
> attribute, and delete=False. Good job!
> 
> 
> 
> ChrisA

we don't have permission to use the temporary file while it has not been closed,but when the file is closed , it will be destroyed by default(delete=True),but once we set delete=False,then we couldn't depend on the convenience of letting the temporary file automatically delete itself after it has been used(then we have to delete it later by os.remove()) ,thus there is nearly no convenience in creating a temporary file or a persistent one when using NamedTemporaryFile.

I think this is a design flaw and should be improved like this :when delete=True,the file should be removed upon destruction of the object or on function return or on garbage collected,only when delete=False,the file can remain on the disk .

[toc] | [prev] | [next] | [standalone]


#61468

FromAndreas Perstinger <andipersti@gmail.com>
Date2013-12-10 13:59 +0100
Message-ID<mailman.3827.1386683859.18130.python-list@python.org>
In reply to#61372
iMath <redstone-cold@163.com> wrote:
>we don't have permission to use the temporary file while it has not
>been closed,but when the file is closed , it will be destroyed by
>default(delete=True),but once we set delete=False,then we couldn't
>depend on the convenience of letting the temporary file automatically
>delete itself after it has been used(then we have to delete it later
>by os.remove()) ,thus there is nearly no convenience in creating a
>temporary file or a persistent one when using NamedTemporaryFile.

In your OP you asked for a platform independent solution thus I don't
think it's possible to do what you want if the OS doesn't support
opening a file another time while it's still open.

Otherwise, on my Linux system this works:

>>> import tempfile, subprocess
>>> with tempfile.NamedTemporaryFile() as fp:                                   
...   fp.write(b"foo\nbar\nbaz\n")
...   fp.flush()
...   subprocess.call(["cat", fp.name])
... 
12
foo
bar
baz
0

Bye, Andreas

[toc] | [prev] | [next] | [standalone]


#60924

FromAlain Ketterlin <alain@dpt-info.u-strasbg.fr>
Date2013-12-03 10:33 +0100
Message-ID<87li029t4a.fsf@dpt-info.u-strasbg.fr>
In reply to#60885
Ben Finney <ben+python@benfinney.id.au> writes:

> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Mon, Dec 2, 2013 at 10:34 PM, iMath <redstone-cold@163.com> wrote:
>> > ffmpeg -f concat -i <(for f in ./*.wav; do echo "file '$f'"; done) -c copy output.wav
>> > ffmpeg -f concat -i <(printf "file '%s'\n" ./*.wav) -c copy output.wav
>> > ffmpeg -f concat -i <(find . -name '*.wav' -printf "file '%p'\n") -c copy output.wav
>>
>> In bash, the <(...) notation is like piping: it executes the command
>> inside the parentheses and uses that as standard input to ffmpeg.
>
> Not standard input, no. What it does is create a temporary file to
> contain the result, and inserts that file name on the command line. This
> is good for programs that require an actual file, not standard input.

Just in case (it may not be relevant to the current discussion): it may
not be a file, it will more probably be a FIFO (i.e., not seekable).
Here is the relevant part of the manual page:

|    Process Substitution
|        Process substitution is supported on systems that support named
|        pipes (FIFOs) or the /dev/fd method of naming open files. It
|        takes the form of <(list) or >(list). The process list is run
|        with its input or output connected to a FIFO or some file in
|        /dev/fd. The name of this file is passed as an argument to the
|        current command as the result of the expansion.

-- Alain.

[toc] | [prev] | [next] | [standalone]


#60936

FromiMath <redstone-cold@163.com>
Date2013-12-03 05:59 -0800
Message-ID<32aae712-6ffe-4640-9254-53fae264be61@googlegroups.com>
In reply to#60924
在 2013年12月3日星期二UTC+8下午5时33分09秒,Alain Ketterlin写道:
> Ben Finney <ben+python@benfinney.id.au> writes:
> 
> 
> 
> > Chris Angelico <rosuav@gmail.com> writes:
> 
> >
> 
> >> On Mon, Dec 2, 2013 at 10:34 PM, iMath <redstone-cold@163.com> wrote:
> 
> >> > ffmpeg -f concat -i <(for f in ./*.wav; do echo "file '$f'"; done) -c copy output.wav
> 
> >> > ffmpeg -f concat -i <(printf "file '%s'\n" ./*.wav) -c copy output.wav
> 
> >> > ffmpeg -f concat -i <(find . -name '*.wav' -printf "file '%p'\n") -c copy output.wav
> 
> >>
> 
> >> In bash, the <(...) notation is like piping: it executes the command
> 
> >> inside the parentheses and uses that as standard input to ffmpeg.
> 
> >
> 
> > Not standard input, no. What it does is create a temporary file to
> 
> > contain the result, and inserts that file name on the command line. This
> 
> > is good for programs that require an actual file, not standard input.
> 
> 
> 
> Just in case (it may not be relevant to the current discussion): it may
> 
> not be a file, it will more probably be a FIFO (i.e., not seekable).
> 
> Here is the relevant part of the manual page:
> 
> 
> 
> |    Process Substitution
> 
> |        Process substitution is supported on systems that support named
> 
> |        pipes (FIFOs) or the /dev/fd method of naming open files. It
> 
> |        takes the form of <(list) or >(list). The process list is run
> 
> |        with its input or output connected to a FIFO or some file in
> 
> |        /dev/fd. The name of this file is passed as an argument to the
> 
> |        current command as the result of the expansion.
> 
> 
> 
> -- Alain.

thanks for your reply, but is there any method that we can convert this to python ?

[toc] | [prev] | [next] | [standalone]


#60887

FromChris Angelico <rosuav@gmail.com>
Date2013-12-03 08:25 +1100
Message-ID<mailman.3480.1386019510.18130.python-list@python.org>
In reply to#60858
On Tue, Dec 3, 2013 at 8:19 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Mon, Dec 2, 2013 at 10:34 PM, iMath <redstone-cold@163.com> wrote:
>> > ffmpeg -f concat -i <(for f in ./*.wav; do echo "file '$f'"; done) -c copy output.wav
>> > ffmpeg -f concat -i <(printf "file '%s'\n" ./*.wav) -c copy output.wav
>> > ffmpeg -f concat -i <(find . -name '*.wav' -printf "file '%p'\n") -c copy output.wav
>>
>> In bash, the <(...) notation is like piping: it executes the command
>> inside the parentheses and uses that as standard input to ffmpeg.
>
> Not standard input, no. What it does is create a temporary file to
> contain the result, and inserts that file name on the command line. This
> is good for programs that require an actual file, not standard input.

Ah, sorry, my bad - bit rusty on my arcane bashisms. In any case, the
general point of what I was saying is: Figure out what's happening,
and replicate that. In this case, that means creating a file, then,
rather than putting it on stdin - that's probably actually easier
anyway.

ChrisA

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python


csiph-web