<br><br><div class="gmail_quote">On 13 December 2010 08:45, Raymond Wagner <span dir="ltr">&lt;<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 12/12/2010 17:00, D. R. Newman wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 12/12/10 21:08, Raymond Wagner wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The only reason to ever do a multi-pass encode is if you&#39;re trying to<br>
fit an exact file size.  Otherwise, just set a quantizer for an<br>
acceptable quality, and let the codec do its thing.<br>
</blockquote>
Don&#39;t two pass encodings use a higher bit rate where there is a lot of<br>
movement, and lower bit rates when there are just a few people talking?<br>
I set Avidemux to 2-pass encode to an average bit rate of 700 bps (for<br>
PAL originals), assuming that it would still manage the fast scenes<br>
while not taking up too much space.<br>
</blockquote>
<br></div>
Using a quantizer allows the compressor to use more or less bitrate as needed to achieve the quality level set by the quantizer.  All a first pass does is figures out how to distribute that to accurately hit a desired bitrate.  If you don&#39;t care how big a video is going to end up, there is no need for it.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

See <a href="http://mythtv.org/wiki/Mythvidexport.py" target="_blank">http://mythtv.org/wiki/Mythvidexport.py</a><br>
It already does most of those operations as a user job, plus allows user<br>
defined formatting of the resultant filename, and metadata pulling from<br>
the defined data grabbers in MythVideo.<br>
</blockquote>
Thanks for the reference. I knew about mytharchive, and the different<br>
job it does, but had not come across mythvidexport.py . I take it that<br>
it doesn&#39;t transcode the file, just moves it? (I have to ask, because<br>
Python isn&#39;t one of the languages I have used.)<br>
</blockquote>
<br></div>
Correct.  It copies the recording as it exists over to MythVideo.  It does not do any transcoding.<div><div></div><div class="h5"><br>
<br></div></div></blockquote><div><br>Silly question but what is the point of that? <br>other then grouping everything in mythvideo?<br>I thought the whole point of mythvideo was to play back anything that wasn&#39;t a recording or a place to export recordings after transcoding to reduce storage requirements?<br>
<br>please enlighten me<br><br>Cheers,<br><br>Anthony <br></div></div><br>