imkira / go-libav

Go language bindings for ffmpeg libraries
MIT License
522 stars 93 forks source link

Build issue of avfilter, ffmpeg 3.3.2, macOS #38

Closed martinlindhe closed 7 years ago

martinlindhe commented 7 years ago

Got the following errors

$ go get -u github.com/imkira/go-libav/avfilter
# github.com/imkira/go-libav/avfilter
../../imkira/go-libav/avfilter/avfilter.go:234: l.CAVFilterLink.status undefined (type *C.struct_AVFilterLink has no field or method status)
../../imkira/go-libav/avfilter/avfilter.go:242: l.CAVFilterLink.frame_count undefined (type *C.struct_AVFilterLink has no field or method frame_count)

It seems in ffmpeg 3.3, status got repurposed as "ready" in https://github.com/FFmpeg/FFmpeg/commit/02aa0701ae0dc2def8db640c9e3c06dc1b5de70c#diff-922654fd0bdecbcd8ccee2c39549c46f

and frame_count turned into frame_count_in and frame_count_out in commit https://github.com/FFmpeg/FFmpeg/commit/183ce55b0de0a597b838d08bbac67f54c27ed42f#diff-922654fd0bdecbcd8ccee2c39549c46f

One way to resolve would be to remove these functions:


func (l *Link) Status() int {
    return int(l.CAVFilterLink.status)
}

func (l *Link) FrameCount() int64 {
    return int64(l.CAVFilterLink.frame_count)
}

any idea?

imkira commented 7 years ago

Yep sorry, not yet supported due to breaking changes in ffmpeg API. Currently, only 3.0.x is supported but I'm planning on upgrading. This is being used internally in my company and I'm not sure if we can have 3.3 support that also works with 3.2 and 3.1 without having to develop 3 different branches. I cannot give you a specific timeline for this, but if you feel like it I welcome you to work on it if you really need it asap. I will leave this open for now until I have more updates.

martinlindhe commented 7 years ago

There is additional warnings about deprecated functions, but I managed to use some parts of this lib with ffmpeg 3.3 to extract media info (#40). I will continue to push some changes for ffmpeg 3.3 to my branch for now. I hope we can avoid having multiple branches of this too.

martinlindhe commented 7 years ago

I've been looking into this more.

I am currently trying to resolve api change issues using build tags.

This way we can use a avcodec_30.go naming and // +build ffmpeg30 tag in the source, to build certain parts for ffmpeg 3.0, and others for ffmpeg 3.3. API's that has been removed in ffmpeg 3.3 will simply not be accessible using build tag "ffmpeg33".

How does this sound?

NikkyAI commented 7 years ago

how do you go get this ? and how would importing from a non master branch work if i want to try this out ?

martinlindhe commented 7 years ago

@NikkyAI how you go get go-libav? as you normally would.

go get github.com/imkira/go-libav

to try out the PR, just add my repo as a remote and check it out, something like this: (you would find my branch name in the PR)

cd go/src/github.com/imkira/go-libav
git remote add martins https://github.com/martinlindhe/go-libav
git fetch martins
git checkout martins/ffmpeg33
imkira commented 7 years ago

@NikkyAI You would do it as you would normally do, the problem is when go getting, go will also try to build it. Try like this

go get -u -tags=ffmpeg33 github.com/imkira/go-libav