Commit 3f9137c
<https://github.com/FFmpeg/FFmpeg/commit/3f9137c57d2344d7613f134128235c18edcede95>changed
how avfilter behaved in my application and I was wondering if it is a
FFmpeg bug, my bug, or intended behavior?
My application reads in media with avfilter/avcodec, resizes it with
swscale, applies an overlay with avfilter, swscales it again, then
encodes it with libjpeg-turbo. If I don't set AVFrame::pts to
AV_NOPTS_VALUE before giving it to avfilter, I get a blank frame with
some garbage at the bottom
<https://abex.sauville.org/ffmpeg_garbage/garbage%20at%20bottom.jpg>.
Additionally this only happens with some PNG inputs
<https://abex.sauville.org/ffmpeg_garbage/rawpng.png>(afaik, haven't
tried many formats). This does not happen with h264 in a mp4, or with a
PNG in a mp3 <https://abex.sauville.org/ffmpeg_garbage/png_in_mp3.mp3>.
In this configuration only one frame goes through the filter before it
is destroyed.
Relevant code in my application is here:
base.go
<https://bitbucket.org/Abex/yumeko/src/3960c8e03f2e69a329b1074ba6bda7fb2b08c112/thumblink/mutators/thumbnailer/base.go?fileviewer=file-view-default#base.go-393>
format.h
<https://bitbucket.org/Abex/yumeko/src/3960c8e03f2e69a329b1074ba6bda7fb2b08c112/ffmpeg/format.h?fileviewer=file-view-default>
format.go
<https://bitbucket.org/Abex/yumeko/src/3960c8e03f2e69a329b1074ba6bda7fb2b08c112/ffmpeg/format.go?at=master&fileviewer=file-view-default>
Unfortunately this code does not lend itself to debugging very well, due
to tight integration, lack of testing, and FFI borders, so if this does
look like a bug, I can try to get a smaller repro if that would help.
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
