Hello all, My situation is that I need to encode the same content from a video grab card to two different bitrates at the same time. The files need to be ready for use at roughly the same time (ie, the end of the show!). Unlike Windows Media Encoder, or Helix Producer, it's not possible with mencoder to grab to two different output rates at the same time (or am I wrong???). What I have to do is grab from the tv capture card to filename.avi, and while it's still grabbing from the tv card, run mencoder against filename.avi to also produce an identical file at a lower bitrate. My problem is that the second mencoder runs faster than real time, catches up with the end of the file, and then exits while the primary encode is still running. Is it possible to slow down mencoder so that it also runs in realtime, so that if I start it running 10 seconds after the initial grab, it'll run second by second against the file being grabbed, instead of 'as fast as computerly possible'? Or is there some other way to feed the content of filename.avi into mencoder in real time for encoding? Cheers, Jonathan ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
What I have to do is grab from the tv capture card to filename.avi, and while it's still grabbing from the tv card, run mencoder against filename.avi to also produce an identical file at a lower bitrate. My problem is that the second mencoder runs faster than real time, catches up with the end of the file, and then exits while the primary encode is still running.
What about using pipes and tee, something like this (I cannot test this as I currently have no Linux available): # make a named pipe mkfifo testfilename.avi # start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality tee splits the input from the capturing program and writes it to both stdout and the named pipe. I think something like this should work, but I am not shure if mencoder supports encoding from stdin :-) -- Martin Ankerl | http://martinus.geekisp.com/
wrote:
What I have to do is grab from the tv capture card to filename.avi, and while it's still grabbing from the tv card, run mencoder against filename.avi to also produce an identical file at a lower bitrate. My problem is that the second mencoder runs faster than real time, catches up with the end of the file, and then exits while the primary encode is still running.
What about using pipes and tee, something like this (I cannot test this as I currently have no Linux available):
# make a named pipe mkfifo testfilename.avi
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
tee splits the input from the capturing program and writes it to both stdout and the named pipe. I think something like this should work, but I am not shure if mencoder supports encoding from stdin :-)
Interesting.. mencoder _is_ the captureprog though... J. ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
On Thursday 10 March 2005 17:39, Martin Ankerl wrote:
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
Whats the cat for?... That's redundant This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so: mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi & mencoder output1 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=10000 -oac mp3lame -o badquality.avi Change options as necessary obviously. Do NOT use mencoder for capturing directly to stdout and then to tee. MEncoder outputs too much garbage on stdout and on stderr. Hope your CPU can handle it, you'll drop frames otherwise. - ods15
On Thu, Mar 10, 2005 at 09:24:02PM +0200, Oded Shimon wrote:
On Thursday 10 March 2005 17:39, Martin Ankerl wrote:
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
Whats the cat for?... That's redundant
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Change options as necessary obviously. Do NOT use mencoder for capturing directly to stdout and then to tee. MEncoder outputs too much garbage on stdout and on stderr.
Very true.. :) Rich
D Richard Felker III wrote:
Whats the cat for?... That's redundant
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Genius! This appears to actually work.. thanks very much for the suggestions.. J. ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
D Richard Felker III wrote:
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Hmm, ok snag hit.. After 351 seconds every time I run it, the two mencoders that are encoding to a file stop writing to the file. Though the mencoder processes continue running, a message on the console says ODML: Starting new RIFF chunk at 0MB. When I kill the processes the summary says that they have encoded 350 seconds or thereabouts, but the mencoder process that is capturing from the tv card reports that it encoded however many seconds it was until I actually manually killed it.. Thoughts? Cheers, J. ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
-noodml report if that works - ods15
Oded Shimon wrote:
-noodml report if that works
This appears to have worked, thanks again, your help is much appreciated Jonathan ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
Ok the encoding works, but I am encountering difficulties under Windows. It's vital for me that these files work with Direct Show as they are going to be transcoded using Windows Media Encoder and Helix Producer. I have the XviD codec installed under windows, but the files will not render, Windows reports that the codec is not installed. I have another XviD file that I downloaded, which seems to have been created with VirtualDub under windows, and when I use THAT file as the input into mencoder instead of mencoder as the capture program, the resulting XviD AVI from mencoder WILL render under windows in windows media player. Also the GSpot codec identifying program reports _identical_ file attributes for the virtualdub->mencoder file as it does for the mencoder_capture->mencoder file. Thoughts? Cheers, Jonathan. D Richard Felker III wrote:
On Thu, Mar 10, 2005 at 09:24:02PM +0200, Oded Shimon wrote:
On Thursday 10 March 2005 17:39, Martin Ankerl wrote:
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
Whats the cat for?... That's redundant
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Change options as necessary obviously. Do NOT use mencoder for capturing directly to stdout and then to tee. MEncoder outputs too much garbage on stdout and on stderr.
Very true.. :)
Rich
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users
****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
On Tue, 29 Mar 2005 14:06:18 +0100 Jonathan Lundberg <lundbej@rte.ie> wrote:
I have the XviD codec installed under windows, but the files will not render, Windows reports that the codec is not installed.
You're probably want to force mencoder to write a fourcc of something like "divx", instead of it's default.
Hi guys, Only looking at this situation again now after a few months hiatus.. Running the following script: ================================= #!/bin/sh cd /root/grabs DATE=`date` /bin/echo $DATE >> test.log /bin/echo "Starting Capture" >> test.log /usr/local/bin/mencoder -noodml -tv driver=v4l:width=352:height=288 tv:// -o input -ovc raw -oac pcm & /usr/bin/tee output1 < input | /usr/local/bin/mencoder - -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000 -oac lavc -o good.avi & /usr/local/bin/mencoder output1 -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=250 -oac lavc -o bad.avi & sleep 5 # Run Mplayer to monitor output mplayer bad.avi -nosound & mplayer good.avi -nosound & =================================== But every time, after 1079.6 seconds, both of the mencoders working on the fifo's die off like so: Flushing video frames Writing AVI header... Fixing AVI header... ODML: Aspect information not (yet?) available or unspecified, not writing vprp header. Video Stream: 1000.525kbit/s etc etc Audio Strea: 224.000 kbit/s etc etc /usr/bin/tee: standard output: Broken pipe /usr/bin/tee: output1: Broken pipe and same for the 2nd encoder.. while the primary encoder capturing from the card continues on.. Any thoughts? Cheers, Jonathan D Richard Felker III wrote:
On Thu, Mar 10, 2005 at 09:24:02PM +0200, Oded Shimon wrote:
On Thursday 10 March 2005 17:39, Martin Ankerl wrote:
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
Whats the cat for?... That's redundant
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Change options as necessary obviously. Do NOT use mencoder for capturing directly to stdout and then to tee. MEncoder outputs too much garbage on stdout and on stderr.
Very true.. :)
Rich
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users
****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
What version of mencoder are you using? I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to run multiple instances, but switching a more recent build (from CVS) fixed that. Pete
-----Original Message----- From: mencoder-users-bounces@mplayerhq.hu [mailto:mencoder-users- bounces@mplayerhq.hu] On Behalf Of Jonathan Lundberg Sent: Thursday, August 18, 2005 9:44 AM To: MEncoder usage discussions Subject: Re: [MEncoder-users] Can you slow down mencoder?
Hi guys,
Only looking at this situation again now after a few months hiatus..
Running the following script:
================================= #!/bin/sh
cd /root/grabs
DATE=`date` /bin/echo $DATE >> test.log
/bin/echo "Starting Capture" >> test.log
/usr/local/bin/mencoder -noodml -tv driver=v4l:width=352:height=288 tv:// -o input -ovc raw -oac pcm &
/usr/bin/tee output1 < input | /usr/local/bin/mencoder - -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000 -oac lavc -o good.avi &
/usr/local/bin/mencoder output1 -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=250 -oac lavc -o bad.avi &
sleep 5 # Run Mplayer to monitor output mplayer bad.avi -nosound & mplayer good.avi -nosound &
===================================
But every time, after 1079.6 seconds, both of the mencoders working on the fifo's die off like so:
Flushing video frames
Writing AVI header... Fixing AVI header... ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
Video Stream: 1000.525kbit/s etc etc Audio Strea: 224.000 kbit/s etc etc /usr/bin/tee: standard output: Broken pipe /usr/bin/tee: output1: Broken pipe
and same for the 2nd encoder.. while the primary encoder capturing from the card continues on..
Any thoughts?
Cheers,
Jonathan
D Richard Felker III wrote:
On Thu, Mar 10, 2005 at 09:24:02PM +0200, Oded Shimon wrote:
On Thursday 10 March 2005 17:39, Martin Ankerl wrote:
# start capturing captureprog | tee testfilename.avi | mencoder settings-for-high-quality cat testfilename.avi | mencoder settings-for-low-quality
Whats the cat for?... That's redundant
This is very hackish, but it does work and I don't see a better solution. You said your capture program is MEncoder, so:
mkfifo input output1 mencoder tv:// -endpos 30:00 -o input -ovc raw -oac pcm & cat input | tee output1 | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Do NOT use cat here. All it will do is increase cpu usage. Instead: tee output1 < input | mencoder - -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=100000 -oac pcm -o goodquality.avi &
Change options as necessary obviously. Do NOT use mencoder for capturing directly to stdout and then to tee. MEncoder outputs too much garbage on stdout and on stderr.
Very true.. :)
Rich
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users
************************************************************************** **** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ************************************************************************** **** _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote:
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to run multiple instances, but switching a more recent build (from CVS) fixed that.
Huh? This is nonsense, they have no knowledge of one another.. Rich
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to run multiple instances, but switching a more recent build (from CVS) fixed
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote: that.
Huh? This is nonsense, they have no knowledge of one another..
Rich
Rich, I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS. I have no explanation for it. Pete
On Thu, Aug 18, 2005 at 09:45:57PM -0500, Pete Davis wrote:
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to run multiple instances, but switching a more recent build (from CVS) fixed
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote: that.
Huh? This is nonsense, they have no knowledge of one another..
Rich
Rich,
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It
This means you have a hardware problem, probably cpu overheating or bad ram.
only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
I have no explanation for it.
See above. Random crash like that is ALWAYS caused by hardware problems. Rich
Rich Felker wrote:
On Thu, Aug 18, 2005 at 09:45:57PM -0500, Pete Davis wrote:
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote:
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to run multiple instances, but switching a more recent build (from CVS) fixed
that.
Huh? This is nonsense, they have no knowledge of one another..
Rich
Rich,
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It
This means you have a hardware problem, probably cpu overheating or bad ram.
only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
I have no explanation for it.
See above. Random crash like that is ALWAYS caused by hardware problems.
Rich
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mencoder-users
Actually I have also noticed that mplayer will often crash on a film if "mplayer *" is chosen where it can play each film just fine if they are played individually (i.e. mplayer film1..pause...mplayer film2...pause..etc.). Don't know if this is relevant. Just my 2.5 cents (adjusted for inflation). Raphael
On Thu, Aug 18, 2005 at 09:45:57PM -0500, Pete Davis wrote:
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote:
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to
run
multiple instances, but switching a more recent build (from CVS) fixed that.
Huh? This is nonsense, they have no knowledge of one another..
Rich
Rich,
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It
This means you have a hardware problem, probably cpu overheating or bad ram.
Rich, on the advice of someone here, I did run a RAM test. No problems found. I don't think it was CPU overheating either. I had the problem for several weeks while running pre7. It was fairly reliable and happened at least a dozen times, again, only when running 2 or more instances of mencoder. But again, the problem went away as soon as I upgraded and has not come back since. That was about a month ago. The machine is constantly running at 100% CPU because it runs boinc as well as doing pretty much 24 hour transcoding, so if it was a CPU overheating issue, surely it would have cropped up again by now.
only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
I have no explanation for it.
See above. Random crash like that is ALWAYS caused by hardware problems.
I've been a programmer, professionally, for about 18 years and I can say without a doubt that that statement is absolutely, 100% false. I'm sure hardware problems can be the cause of many random crashes, but certainly not "ALWAYS". Any number of things can cause "apparently random" crashes like that. Bad pointers being one of the more common. They seem random only because we don't know what the exact cause is. But it wasn't terribly random. There was one thing that every crash had in common, and that was 2 or more instances of mencoder running. In fact, I'm tracking down a bug right now that's causing similar apparently random crashes (on another machine). I have absolutely no doubt that it's a bug in my code. Pete
On Fri, Aug 19, 2005 at 09:52:57AM -0500, Pete Davis wrote:
On Thu, Aug 18, 2005 at 09:45:57PM -0500, Pete Davis wrote:
On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote:
What version of mencoder are you using?
I believe 1.0pre7 has problem running multiple instances of mencoder simultaneously. I know it was periodically causing me problems to
run
multiple instances, but switching a more recent build (from CVS) fixed that.
Huh? This is nonsense, they have no knowledge of one another..
Rich
Rich,
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It
This means you have a hardware problem, probably cpu overheating or bad ram.
Rich, on the advice of someone here, I did run a RAM test. No problems found. I don't think it was CPU overheating either. I had the problem for several weeks while running pre7. It was fairly reliable and happened at least a dozen times, again, only when running 2 or more instances of mencoder.
But again, the problem went away as soon as I upgraded and has not come back since. That was about a month ago. The machine is constantly running at 100% CPU because it runs boinc as well as doing pretty much 24 hour transcoding, so if it was a CPU overheating issue, surely it would have cropped up again by now.
No. Such issues are _random_ and will happen with some binaries, not with others. Again, mencoder has NO CODE that's at all aware or dependent upon other processes on the system. It will behave identically regardless of whether it's interrupted by context switches and how often it's interrupted, aside from the timing measurements to estimate time to finish encoding. Faulty hardware is very odd. It ususally only crashes under very strange circumstances. Two processes rapidly interrupting one another and causing context switches could very well trigger such a crash when one running by itself does not. However, this is NOT A BUG IN THE PROGRAM.
only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
I have no explanation for it.
See above. Random crash like that is ALWAYS caused by hardware problems.
I've been a programmer, professionally, for about 18 years and I can say without a doubt that that statement is absolutely, 100% false. I'm sure hardware problems can be the cause of many random crashes, but certainly not "ALWAYS".
Any number of things can cause "apparently random" crashes like that. Bad pointers being one of the more common. They seem random only because we
That will not be random but deterministic.
don't know what the exact cause is. But it wasn't terribly random. There was one thing that every crash had in common, and that was 2 or more instances of mencoder running.
This is not something in common. Something in common would be crashes at exactly the same frame number.
In fact, I'm tracking down a bug right now that's causing similar apparently random crashes (on another machine). I have absolutely no doubt that it's a bug in my code.
This only happens if you do stupid coding practices like threading that make debugging impossible due to nondeterministic behavior on a given input. Again, I am completely positive that your crash is due to faulty hardware or buggy OS. It is unrelated to mencoder. Rich
Any number of things can cause "apparently random" crashes like that. Bad pointers being one of the more common. They seem random only because we
That will not be random but deterministic.
I didn't say it's random, that's why I put it in quotes and said, "apparently random." In other words, deterministic. But a bug in the code wouldn't necessarily show up on the same frame number every time, it may show up when there's some sort of unexpected and improperly handled collision on a resource of some type that may not happen at precisely the same time every time. When you take into consideration that both instances were started by hand at different offsets in time, each encoding a different file each time, there's no reason I'd expect it to happen on the same frame.
Again, I am completely positive that your crash is due to faulty hardware or buggy OS. It is unrelated to mencoder.
Rich
And again, all evidence to the contrary, I'm going to have to disagree. And it's not as if mencoder is entirely bug free. I've had it crash for a variety of reasons from various CVS updates I've done. Pete
On Fri, Aug 19, 2005 at 02:47:28PM -0500, Pete Davis wrote:
Any number of things can cause "apparently random" crashes like that. Bad pointers being one of the more common. They seem random only because we
That will not be random but deterministic.
I didn't say it's random, that's why I put it in quotes and said, "apparently random." In other words, deterministic. But a bug in the code wouldn't necessarily show up on the same frame number every time, it may show up when there's some sort of unexpected and improperly handled collision on a resource of some type that may not happen at precisely the same time every time.
I've told you again and again: there is no possibility of "resource collision". This only happens when you're writing programs that are threaded or otherwise have "realtime inputs". MEncoder is not such a program!! The ONLY realtime input, unless you're capturing from tv-in, is the system clock, and it's only used for predicting total encode time and showing the current average encode rate. Unless you think the crash is in the code to printf the status line, there is no room for such an error.
When you take into consideration that both instances were started by hand at different offsets in time, each encoding a different file each time, there's no reason I'd expect it to happen on the same frame.
Then you're an idiot. There's no interaction between the two. A program with deterministic inputs behaves exactly the same time each time it's run, regardless of any other system load.
Again, I am completely positive that your crash is due to faulty hardware or buggy OS. It is unrelated to mencoder.
Rich
And again, all evidence to the contrary, I'm going to have to disagree.
And it's not as if mencoder is entirely bug free. I've had it crash for a variety of reasons from various CVS updates I've done.
I agree totally that MEncoder is full of bugs. However you have not found one of them. All you have found is your own faulty hardware. Rich
Any number of things can cause "apparently random" crashes like that. Bad pointers being one of the more common. They seem random only because we
That will not be random but deterministic.
I didn't say it's random, that's why I put it in quotes and said, "apparently random." In other words, deterministic. But a bug in the code wouldn't necessarily show up on the same frame number every time, it may show up when there's some sort of unexpected and improperly handled collision on a resource of some type that may not happen at precisely
On Fri, Aug 19, 2005 at 02:47:28PM -0500, Pete Davis wrote: the
same time every time.
I've told you again and again: there is no possibility of "resource collision". This only happens when you're writing programs that are threaded or otherwise have "realtime inputs". MEncoder is not such a program!! The ONLY realtime input, unless you're capturing from tv-in, is the system clock, and it's only used for predicting total encode time and showing the current average encode rate. Unless you think the crash is in the code to printf the status line, there is no room for such an error.
When you take into consideration that both instances were started by hand at different offsets in time, each encoding a different file each time, there's no reason I'd expect it to happen on the same frame.
Then you're an idiot. There's no interaction between the two. A program with deterministic inputs behaves exactly the same time each time it's run, regardless of any other system load.
Again, I am completely positive that your crash is due to faulty hardware or buggy OS. It is unrelated to mencoder.
Rich
And again, all evidence to the contrary, I'm going to have to disagree.
And it's not as if mencoder is entirely bug free. I've had it crash for a variety of reasons from various CVS updates I've done.
I agree totally that MEncoder is full of bugs. However you have not found one of them. All you have found is your own faulty hardware.
Rich
Rich, I'm not going to respond to you anymore after this because frankly, from your history of posts, it's clear you're a smug, arrogant prick. You call everyone stupid and calling me an idiot means nothing to me coming from you. You're certainly entitled to your opinion, but I'm also entitled to mine. You can disagree, and that's fine. I'm really just sick of you calling people stupid and acting like you're so fucking superior, because the fact is, you're just some little prick with an inferiority complex that feels better about himself by trying to put other people down. Grow up. Pete
On Fri, Aug 19, 2005 at 06:31:55PM -0500, Pete Davis wrote:
Rich, I'm not going to respond to you anymore after this because frankly, from your history of posts, it's clear you're a smug, arrogant prick. You call everyone stupid and calling me an idiot means nothing to me coming from you.
Look, I don't go doing this to everyone. But when you refuse to listen to facts and claim to have found bugs in MEncoder when it's obviously faulty hardware, it pisses me off..
You're certainly entitled to your opinion, but I'm also entitled to mine.
Whether this is a bug in MEncoder or not is not a matter of opinion.
You can disagree, and that's fine. I'm really just sick of you calling people stupid and acting like you're so fucking superior, because the fact is, you're just some little prick with an inferiority complex that feels better about himself by trying to put other people down.
I'm glad you know me so well..
Grow up.
Too late.. Rich
On Friday 19 August 2005 05:45, Pete Davis wrote:
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
Running two instances in the same directory when doing a 2 pass encoding, or doing 2 pass divtc, would be a Bad Idea(TM).
On Sat, Aug 20, 2005 at 04:59:37AM +0300, Jan Knutar wrote:
On Friday 19 August 2005 05:45, Pete Davis wrote:
I'm aware the processes are isolated, but the fact remains that when running 2 or more instances of mencoder 1.0pre7, it was crashing periodically. It only happened when I had 2 or more instances running and the problem went away when I upgraded later out of CVS.
Running two instances in the same directory when doing a 2 pass encoding, or doing 2 pass divtc, would be a Bad Idea(TM).
Well yes, I would hope he wasn't doing this... :) Rich
On Thu, Aug 18, 2005 at 03:43:40PM +0100, Jonathan Lundberg wrote:
Hi guys,
Only looking at this situation again now after a few months hiatus..
Running the following script:
================================= #!/bin/sh
cd /root/grabs
DATE=`date` /bin/echo $DATE >> test.log
/bin/echo "Starting Capture" >> test.log
/usr/local/bin/mencoder -noodml -tv driver=v4l:width=352:height=288 tv:// -o input -ovc raw -oac pcm &
/usr/bin/tee output1 < input | /usr/local/bin/mencoder - -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000 -oac lavc -o good.avi &
/usr/local/bin/mencoder output1 -of avi -noodml -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=250 -oac lavc -o bad.avi &
sleep 5 # Run Mplayer to monitor output mplayer bad.avi -nosound & mplayer good.avi -nosound &
I'm not sure, but try removing the '-noodml' from the 2 "encoders".. leave it for the "capturer" though. - ods15
Oded Shimon wrote:
I'm not sure, but try removing the '-noodml' from the 2 "encoders".. leave it for the "capturer" though.
It's the same without the -noodml as it is with it in. In fact I only put in the -noodml to try and stop this problem (as per your previous suggestion some months ago) Cheers, Jonathan ****************************************************************************** The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please note that emails to, from and within RTÉ may be subject to the Freedom of Information Act 1997 and may be liable to disclosure. ******************************************************************************
On Thu, Mar 10, 2005 at 03:24:36PM +0000, Jonathan Lundberg wrote:
Hello all,
My situation is that I need to encode the same content from a video grab card to two different bitrates at the same time. The files need to be ready for use at roughly the same time (ie, the end of the show!). Unlike Windows Media Encoder, or Helix Producer, it's not possible with mencoder to grab to two different output rates at the same time (or am I wrong???).
What I have to do is grab from the tv capture card to filename.avi, and while it's still grabbing from the tv card, run mencoder against filename.avi to also produce an identical file at a lower bitrate. My problem is that the second mencoder runs faster than real time, catches up with the end of the file, and then exits while the primary encode is still running.
Is it possible to slow down mencoder so that it also runs in realtime, so that if I start it running 10 seconds after the initial grab, it'll run second by second against the file being grabbed, instead of 'as fast as computerly possible'?
Or is there some other way to feed the content of filename.avi into mencoder in real time for encoding?
Look up fifos (mkfifo) and the "tee" program. These should be able to help you do the trick. Rich
On Thu, 10 Mar 2005 15:24:36 +0000 Jonathan Lundberg <lundbej@rte.ie> wrote:
Is it possible to slow down mencoder so that it also runs in realtime, so that if I start it running 10 seconds after the initial grab, it'll run second by second against the file being grabbed,
You might get lucky if you run the first instance of mencoder with "nice -n -19", and the second instance of mencoder with "nice -n 19" (or something similar).
participants (10)
-
D Richard Felker III -
Jan Knutar -
Jonathan Lundberg -
Martin Ankerl -
Oded Shimon -
Pete Davis -
R C -
Raphael -
RC
-
Rich Felker