No subject

Sat Dec 15 06:33:16 UTC 2012

behaviour, is because we didn't use ffmpeg properly, not the other way

So I suggest you raise a bug report with ffmpeg directly.

Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, 16 December 2012, David Osguthorpe  wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">On Sat, Dec 15, 2012 at 06:39:20PM +1100, Jean-Yves Av=
enard wrote:<br>

&gt; On 15 December 2012 10:00, David Osguthorpe &lt;<a href=3D"javascript:=
;" onclick=3D"_e(event, &#39;cvml&#39;, &#39;david.osguthorpe at
;)">david.osguthorpe at</a>&gt; wrote:<br>
&gt; &gt; the error came from the ffmpeg function ffio_limit in libavformat=
&gt; &gt; &quot;Truncating packet of size...&quot;<br>
&gt; &gt;<br>
&gt; &gt; further exploration showed that the libav version of ffmpeg does =
&gt; &gt; include this ffio_limit change (This is ubuntu 12.04)<br>
&gt; do you have a ffmpeg changeset I can refer to ?<br>
from the mythtv error messages Im suspicious that the seeking around<br>
in commerical flagging is somehow messing with the end of file detection<br=
this ffmpeg code seems to be using - the errors suggest the commercial<br>
detector is reading data that ffmpeg with the ffio_limit function<br>
claims is past EOF<br>
</blockquote><div><br></div><div>If you want changes to go into ffmpeg, the=
 best long term solution is to get them incorporated into ffmpeg upstream, =
or submit code that works around the behaviour they have introduced on our =
side of the code.</div>
<div><br></div><div>From most of the cases I&#39;ve seen whenever we have h=
ad an incorrect behaviour, is because we didn&#39;t use ffmpeg properly, no=
t the other way round.=A0</div><div><br></div><div>So I suggest you raise a=
 bug report with ffmpeg directly.<span></span></div>


More information about the mythtv-dev mailing list