<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000001">
<div class="moz-cite-prefix"><br>
<pre class="moz-signature" cols="72">--</pre>
On 12/10/2013 7:42 PM, A. F. Cano wrote:<br>
</div>
<blockquote cite="mid:20131211014252.GA2422@shibaya.lonestar.org"
type="cite">
<pre wrap="">On Mon, Dec 09, 2013 at 04:40:29PM +0000, John Pilkington wrote:
</pre>
<blockquote type="cite">
<pre wrap="">...
First; why are you recording HD? Is that the only version that is
available to you?
</pre>
</blockquote>
<pre wrap="">
As other people in another part of this thread have pointed out, that
is the only choice I have. I use an antenna and the material comes
in HD.
</pre>
<blockquote type="cite">
<pre wrap="">Second; it looks as if your transcode isn't working. Here in the UK
</pre>
</blockquote>
<pre wrap="">
Interestingly, when I tried to transcode manually with the command you
gave below, mythffmpeg was not installed. I installed it via aptitude.
We'll see if this has any effect next time I record a show.
</pre>
<blockquote type="cite">
<pre wrap="">a good-quality SD recording stripped to just the video and one audio
channel comes at around 1.4 GB per hour; I can usually get 3
one-hour shows onto a DVD, with no re-encoding.
</pre>
</blockquote>
<pre wrap="">
It looks like the default parameters cause extreme lossy compression.
>From 5.2G to 254M just by specifying 960 x 512 (1/2 the height and 1/2
the width). Obviously this is not the optimal setup. I can watch other
videos full screen (with mplayer) and they look much better even though
they are of lower resolution. I'll have to try with the -b:v and -b:a
parameters.
254M Dec 10 17:45 2131_20131127030000.mpg
5.2G Nov 26 23:00 2131_20131127030000HD.mpg
</pre>
<blockquote type="cite">
<pre wrap="">I have done conversion from HD to SD like this:
mythffmpeg -threads 2 -v verbose -i infile.mpg -target pal-dvd -b:v
6000k -s 720x576 -acodec mp2 -b:a 256k -ac 2 -aspect 16:9
outfile.mpg
</pre>
</blockquote>
<pre wrap="">
This is what I tried:
mythffmpeg -threads auto -v verbose -i 2131_20131127030000HD.mpg -s
960x512 -acodec mp2 -ac 2 -aspect 16:9 2131_20131127030000.mpg
Also ran mythcommflag manually, but it finished quickly with an
error. It might be because the file was quite corrupted because
of reception problems. When I tried to watch it within myth, it
gave a long list of errors and exited back to the "watch recordings"
window, which incidentally still says that it's 1080i, so something
didn't get updated properly.
</pre>
<blockquote type="cite">
<pre wrap="">and on my 2006-vintage laptop throughput is around 30 fps. Input
filesize (all streams) around 3 GB per hour, output filesize around
2 GB per hour.
</pre>
</blockquote>
<pre wrap="">
The above transcode took about 2:45 for the 1 hour show.
</pre>
<blockquote type="cite">
<pre wrap="">Obviously this may need modifying for location, and maybe omit
--threads or set it to 1, but it should give you a start if no-one
comes up with a Myth-based solution. Rename the input file to
xxxHD.mpg, use xxx.mpg as output and when done use mythcommflag
--rebuild --file xxx.mpg to fix the database.
</pre>
</blockquote>
<pre wrap="">
Thanks a bunch. At least now I can watch the highly pixelated shows
with mplayer and the slow cpu can keep up.
One other question. I deleted a test recording from within myth. It
says that deleting the show from the list does not remove the file.
Is there a way to manually remove recordings completely? the mpg file,
the data that gets stored in the database, etc... I'm aware that there
is some expiration time, but since the disk is not full, myth is
apparently not removing shows.
Thanks.
Augustine
</pre>
</blockquote>
That message about the deletion just "deleting the listing and not
removing the file" sounds like you deleted from the "Previous
Recordings" screen and not the "watch recordings" screen. Deleting
from the "watch recordings" screen will delete the actual file.<br>
<br>
Deleting from the "Previous Recordings" screen just deletes the
entry in the "previous recordings" data base so that MythTV will no
longer think that that show was ever previously recorded. So if
Myth is asked to record that show again it will think that it was
never previously recorded and will thus record it again. Hence the
message about just "removing the entry and not the actual file".<br>
Ziggy<br>
</body>
</html>