[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