<div dir="ltr"><div><div>As a matter of fact, I wanted to use them for computer vision, where calculating edge densities and motion estimation are important.<br></div>Now that these are deprecated, the only way is to first decode each frame then re-calculate MVs and DCTs, which is computationnally costly...<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-25 14:40 GMT+01:00 wm4 <span dir="ltr"><<a href="mailto:nfxjfg@googlemail.com" target="_blank">nfxjfg@googlemail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, 25 Mar 2014 13:50:48 +0100<br>
Vojtěch Král <<a href="mailto:vojtech@kral.hk">vojtech@kral.hk</a>> wrote:<br>
<br>
><br>
><br>
> On 2014-03-25 13:29, Tomas Härdin wrote:<br>
><br>
> > Please avoid top posting on these lists - it's considered bad form.<br>
> ><br>
> > On 2014-03-25 12:10, cyril poulet wrote:<br>
> ><br>
> > 2014-03-25 12:06 GMT+01:00 Tomas Härdin <<a href="mailto:tomas.hardin@codemill.se">tomas.hardin@codemill.se</a>>:<br>
> ><br>
> > On 2014-03-25 11:29, cyril poulet wrote:<br>
> > Hi all<br>
> > As others who already posted on this matter but got no answers, I'm trying to get motion vectors from h264 codec (P-frames).<br>
> > Before v2, they seemed to be available in AVFrame::motion_val, (along with motion_subsample_log2 and mb_type), which are now deprecated.<br>
> ><br>
> > Is there any way to get these values since v2 ?<br>
> ><br>
> > (I'm also interested in getting back the dct_coeff for I-frames, but something tells me that all these questions are linked) I think the general direction nowadays is to hide such internals. If you want access to this stuff in the future you'll have to fork and hack the functionality in<br>

> ><br>
> > /Tomas<br>
><br>
> > So i've understood, but I don't really see why these values are not available anymore. I realize that messing with the internals of various codecs is not why libav is made for, but these fields are calculated anyway, so why not propagate it to the AVFrame ?<br>

><br>
>  Because they're internal, and having them exposed hampers refactoring<br>
> efforts. If you want stuff to remain "like before" then just use some<br>
> specific old version of ffmpeg in your application (or even a specific<br>
> commit)<br>
><br>
>  /Tomas<br>
><br>
> That's a rather evasive answer... I myself would too welcome if the API<br>
> for access to internals such as DCTs and MVs was preserved (mostly for<br>
> academical / experimental purposes, as I'm working on a bc thesis<br>
> concerning video right now). Refactoring is a great thing, but it<br>
> doesn't have to entail removing funcionality...<br>
<br>
</div>As far as I know, the API was deprecated by Libav. Libav also removed<br>
the implementation of these. FFmpeg merged the deprecation, but not the<br>
removal of the implementation (or at least not all of it). So there's<br>
hope for you to convince the developers to un-deprecate it.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
</div></div></blockquote></div><br></div>