[FFmpeg-devel] [PATCH] amfenc: Add support for pict_type field

Michael Fabian Dirks michael.dirks at xaymar.com
Fri Apr 12 04:37:58 EEST 2019

On 10.02.2019 19:32, Mark Thompson wrote:
> On 04/02/2019 14:41, Michael Dirks wrote:
> You can see this with the trace_headers bitstream filter.  (Try "-c:v h264_amf -options... -bsf:v trace_headers -f null -", or it can be used with streamcopy to examine an existing file.)
> Well yes, but that's not actually going to work - try it with a set of JPEGs as input and you'll observe the problem.  (Note that no other encoder uses this field on input, though some do use it internally.)
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hi Mark,

I should have a newer AMD card to test with in the near future, so I 
should be able to confirm the behavior across multiple generations of 
cards (GCN2, GCN3, GCN4, GCN4.1? (Vega)). As I currently only have the 
ability to test GCN2, GCN3 and Polaris (GCN4) I'm not fully sure how it 
behaves yet.

As for the key_frame change, you are correct. How do you actually insert 
a normal I frame without the extra overhead of a IDR frame in ffmpeg? 
The AMD AMF Encoder is not exactly efficient in speed, quality or power 
usage, and inserting an IDR frame does more "damage" to the AMF encoded 
stream than just inserting an I frame.


Mit freundlichen Grüßen / Sincerely

Michael Fabian 'Xaymar' Dirks//

More information about the ffmpeg-devel mailing list