Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #60858 > unrolled thread
| Started by | iMath <redstone-cold@163.com> |
|---|---|
| First post | 2013-12-02 03:34 -0800 |
| Last post | 2013-12-03 08:25 +1100 |
| Articles | 11 on this page of 31 — 11 participants |
Back to article view | Back to comp.lang.python
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]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-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]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2013-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]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2013-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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-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]
| From | iMath <redstone-cold@163.com> |
|---|---|
| Date | 2013-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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-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]
| From | iMath <redstone-cold@163.com> |
|---|---|
| Date | 2013-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]
| From | Andreas Perstinger <andipersti@gmail.com> |
|---|---|
| Date | 2013-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]
| From | Alain Ketterlin <alain@dpt-info.u-strasbg.fr> |
|---|---|
| Date | 2013-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]
| From | iMath <redstone-cold@163.com> |
|---|---|
| Date | 2013-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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-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