No subject

Sun Mar 1 18:40:12 UTC 2009 this first point might change in the future.
They will try time based releases. Possibly that will solve the second point
too eventually.
Can the changes needed to the ffmpeg code be incorporated upstream?



> _______________________________________________
> mythtv-users mailing list
> mythtv-users at

There is always a but, but not this time.

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

<br><br><div class=3D"gmail_quote">2009/3/11 Nick Rout <span dir=3D"ltr">&l=
t;<a href=3D"mailto:nick.rout at">nick.rout at</a>&gt;</span>=
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class=3D"im">On Wed, Mar 11, 2009 at 12:04 PM, Robert McNamara<br>
&lt;<a href=3D"mailto:robert.mcnamara at">robert.mcnamara at<=
/a>&gt; wrote:<br>
&gt; On Tue, Mar 10, 2009 at 2:57 PM, gonzalo diethelm &lt;<a href=3D"mailt=
o:gdiethelm at">gdiethelm at</a>&gt; wrote:<br>
&gt;&gt; Straight, honest to God question: why is it necessary to import th=
&gt;&gt; code? Would it be possible to use FFmpeg as an external library?<b=
&gt; Not that thorny-- a couple of reasons as I understand them. =A0Firstly=
&gt; Myth has a fair number of local modifications for the libav* source,<b=
&gt; particularly the Transport Stream and Program Stream demuxers, which<b=
&gt; makes the upstream versions unsuitable without some hand massaging.<br=
&gt; Secondly, importing the source at compile time is very very tricky--<b=
&gt; ask mplayer devs, who are *constantly* fixing compilation of their<br>
&gt; player because of their decision to do so. =A0The ffmpeg code changes =
&gt; *lot*, including the API, and it would be a lot more work than the<br>
&gt; relatively small group of core devs could easily manage.<br>
&gt; Myth as a project is maybe 10ish core devs and 20-30 regular<br>
&gt; contributors-- just keeping a dynamically imported version of libav*<b=
&gt; working adds up fast in manpower and developer frustration.<br>
</div>Note: avidemux does much the same.<br>
In short, linking to the movable feast that is ffmpeg would be a<br>
nightmare. You basically would need to ensure that every myth system<br>
had a compatible version of ffmpeg, compiled with the same options.<br>
And with distros being what they are, that wouldn&#39;t be easy at all.<br>
Its compounded by lack of releases from ffmpeg, most distros use an<br>
svn version, and they change like the wind. I&#39;ve even seen command<br>
line options change, breaking scripts that rely on an earlier version<br>
(like the need to put k at the end of a bitrate so a parameter that<br>
was previously 384 becomes suddenly 384k).<br>
So by importing the code en masse, you lose the speed with which the<br>
ffmpeg devs incorporate fixes or new features, but gain stability and<br>
control, as well as your own myth-tweaks.</blockquote><div><br>So basically=
 the lack of regular releases and API changes on the ffmpeg side prohibit t=
his.<br>From what I&#39;ve read in the interview with an ffmpeg developer o=
n <a href=3D""></a> this first point might c=
hange in the future.<br>
They will try time based releases. Possibly that will solve the second poin=
t too eventually.<br>Can the changes needed to the ffmpeg code be incorpora=
ted upstream?<br><br>Regards,<br><br>Bert<br></div><blockquote class=3D"gma=
il_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0=
pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class=3D"h5">_________________________________________=
mythtv-users mailing list<br>
<a href=3D"mailto:mythtv-users at">mythtv-users at</a><br>
<a href=3D"" target=
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>-----------=
------------------------------------------<br>There is always a but, but no=
t this time.<br><br>


More information about the mythtv-users mailing list