<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p> </p>
<p>On 2014-03-25 13:29, Tomas Härdin wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->Please avoid top posting on these lists - it's considered bad form.<br /><br />
<div class="moz-cite-prefix">On 2014-03-25 12:10, cyril poulet wrote:</div>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<div class="gmail_extra">
<div class="gmail_quote">2014-03-25 12:06 GMT+01:00 Tomas Härdin <span><<a href="mailto:tomas.hardin@codemill.se">tomas.hardin@codemill.se</a>></span>:<br />
<blockquote class="gmail_quote" style="border-left: 1px #ccc solid; padding-left: 1ex;">
<div class="HOEnZb">
<div class="h5"><br /> On 2014-03-25 11:29, cyril poulet wrote:<br />
<blockquote class="gmail_quote" style="border-left: 1px #ccc solid; padding-left: 1ex;">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)</blockquote>
</div>
</div>
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</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<div dir="ltr">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 ?</div>
</blockquote>
<br /> Because they're internal, and having them exposed hampers refactoring efforts. If you want stuff to remain "like before" then just use some specific old version of ffmpeg in your application (or even a specific commit)<br /><br /> /Tomas</blockquote>
<p>That's a rather evasive answer... I myself would too welcome if the API for access to internals such as DCTs and MVs was preserved (mostly for academical / experimental purposes, as I'm working on a bc thesis concerning video right now). Refactoring is a great thing, but it doesn't have to entail removing funcionality...</p>
<p>For example, let's have a look at libjpeg: It has had a well-defined API for accessing DCT coefficients since always and as far as I'm aware nobody's having problem with it. (Refer to the chapter "<span style="font-size: 12px; white-space: pre-wrap;">Really raw data: DCT coefficients" in libjpeg.txt)</span></p>
<p>It would be very nice if ffmpeg had something similar. While I unserstand that it's not at all a mainstream usecase, I still think it's worthwhile.</p>
<p>Thanks,</p>
<p>BR, Vojtěch Král</p>
<p> </p>
</body></html>