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@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//
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
