<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 12, 2015 at 6:29 AM, John Pilkington <span dir="ltr"><<a href="mailto:J.Pilk@tesco.net" target="_blank">J.Pilk@tesco.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/05/15 10:17, Mike Perkins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/05/15 02:49, Michael Stucky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On May 11, 2015 4:17 PM, "Jay Foster" <<a href="mailto:jayf0ster@roadrunner.com" target="_blank">jayf0ster@roadrunner.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 5/11/2015 12:46 PM, Michael Stucky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote></blockquote>
<deletia><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry for the delay, it was a busy weekend+... I am not an ffmpeg<br>
expert<br>
</blockquote></blockquote>
so all the syntax came either from the original shell script or searches<br>
for a better way to deinterlace. But I have done some additional<br>
searching<br>
and testing have updated my script on the wiki accordingly.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"yadif=1" has become "yadif=0:-1:1" (mode 0 = one frame out for one<br>
</blockquote></blockquote>
frame in, parity -1 = autodetect, and deint 1 = only deinterlace frames<br>
marked as interlaced). "sws_flags spline" is removed (only applies when<br>
scaling content?). "-r 60000/1001" is removed (this actually caused every<br>
frame to be duplicated for interlaced content). "threads 0" is removed<br>
(the<br>
h264 encoder uses all available threads by default). "-c:a copy" replaced<br>
with "-strict -2" to use the internal AAC encoder.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This works and produces good quality output for all my content, 1080i,<br>
</blockquote></blockquote>
720p, and 480i all OTA to HDHomerun tuners.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
I took a look at the script on the wiki and had a question.  Does this<br>
</blockquote>
break commercial skipping?  The script does not appear to reschedule a<br>
commflag job after the transcoding.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
The script was designed to prepare a recording for export to the Video<br>
Library where it can be played by different players/devices (vlc,<br>
mplayer,<br>
android, ios, etc.). As such commercial skipping wasn't a consideration.<br>
The script will remove a cutlist if it exists (so<br>
leaders/trailers/commercials should all be automatically removed<br>
before the<br>
transcoding takes place).<br>
<br>
If it is helpful, please take the script and modify it to do what you<br>
want<br>
it to and create a new wiki page for your script so we all can benefit<br>
from<br>
it!<br>
<br>
</blockquote>
A tricky one. Normally you'd edit the file - or commflag it - before<br>
processing so you only processed the parts you wanted.<br>
<br>
However, with the likely changes in the stream when commercial /<br>
trailers / etc interrupt the program commflagging is not as perfect as<br>
it was in the analog days.<br>
<br>
Preprocessing first into a uniform stream does at least give the<br>
commflag process a fighting chance, though whether you need to<br>
post-process to rebuild seek references (I didn't say seek tables, I<br>
know they're not used with h264) is an interesting question.<br>
<br>
</blockquote>
<br></div></div>
But assuming that Mike S's updated script does what his comment says (and if it doesn't apply the cutlist), surely<span class=""><br>
" "yadif=0:-1:1" (mode 0 = one frame out for one frame in,"<br></span>
implies that a surviving cutlist would retain its original validity?<br>
<br>
I'm afraid I haven't tested this :-)<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I do not use commercial flagging for all of the reasons discussed many times here. I manually edit my recordings marking everything that I do not want to keep leaders/trailers/commercials/etc.</div><div><br></div><div>The script does two separate things with the recordings that I run it against, first it checks for a cutlist and removes it if it exists using "mythtranscode", second if uses "ffmpeg" to transcode from mpeg2 to h264. So by the time ffmpeg gets the file it no longer contains a cutlist, yadif mode 0 means one frame into the deinterlacer and one frame out of the deinterlacer as opposed to yadif mode 1 which outputs one frame for each field input into the deinterlacer. Interlaced content has 2 fields interlaced together to make one frame, this has, IMHO, the negative effect of creating two virtually identical frames of output for each frame input.</div><div><br></div><div>Mike</div></div></div></div>