[FFmpeg-devel] Fwd: Re: [Libav-user] Motion estimation : replacement for deprecated AVFrame::motion_val ?
michaelni at gmx.at
Wed Mar 26 15:29:47 CET 2014
On Wed, Mar 26, 2014 at 12:03:49AM +0530, Anshul wrote:
> -------- Original Message --------
> From: wm4 <nfxjfg at googlemail.com>
> Sent: Tue Mar 25 19:10:24 IST 2014
> To: libav-user at ffmpeg.org
> Subject: Re: [Libav-user] Motion estimation : replacement for deprecated AVFrame::motion_val ?
> On Tue, 25 Mar 2014 13:50:48 +0100
> Vojtěch Král <vojtech at kral.hk> wrote:
> > On 2014-03-25 13:29, Tomas Härdin wrote:
> > > Please avoid top posting on these lists - it's considered bad form.
> > >
> > > On 2014-03-25 12:10, cyril poulet wrote:
> > >
> > > 2014-03-25 12:06 GMT+01:00 Tomas Härdin <tomas.hardin at codemill.se>:
> > >
> > > On 2014-03-25 11:29, cyril poulet wrote:
> > > Hi all
> > > As others who already posted on this matter but got no answers, I'm trying to get motion vectors from h264 codec (P-frames).
> > > Before v2, they seemed to be available in AVFrame::motion_val, (along with motion_subsample_log2 and mb_type), which are now deprecated.
> > >
> > > Is there any way to get these values since v2 ?
> > >
> > > (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
> > >
> > > /Tomas
> > > 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 ?
> > 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)
> > /Tomas
> > 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...
> As far as I know, the API was deprecated by Libav. Libav also removed
> the implementation of these. FFmpeg merged the deprecation, but not the
> removal of the implementation (or at least not all of it). So there's
> hope for you to convince the developers to un-deprecate it.
> Libav-user mailing list
> Libav-user at ffmpeg.org
> I have missed the disscussion when it was removed, I will search old archive why this feature was deprecated, I just wanted to disscuss if it is really possible to know mv vector present in stream using avoption.
the motion vectors should be available in AVFrame motion_val
if they arent, thats a bug and a regression test for this is welcome
Ive no plan to remove this feature, though the exact ABI may change
for compatibility reasons
That is if libav removes the field from the middle of the structure
we wouldnt be able to leave the field in that position and be
compatible with libav at the same time
also the code probably needs a update to use ref-counting so the field
stays valid as long as the AVFrame is
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel