Am Di., 19. Mai 2020 um 14:49 Uhr schrieb :
>
>
> >> The 3.2.14 libraries are clearly twice as fast as the 4.2.2 libraries,
> >> as least with the h.265 media files I'm testing with.
>
> > Then please run git bisect, but allow me to repeat that it may make
> > sense to reproduce with ffmpeg (which
>> The 3.2.14 libraries are clearly twice as fast as the 4.2.2 libraries,
>> as least with the h.265 media files I'm testing with.
>Then please run git bisect, but allow me to repeat that it may make sense to
>reproduce with ffmpeg (which would make your bug report much, much simpler).
>
>Carl
Sorry, the information that the picture has acquired blue shades is false!
вт, 19 мая 2020 г. в 11:53, Виктор Мулин <17se...@gmail.com>:
> I tried the following before opening the encoder:
> codec_context-> intra_matrix = (uint16_t *) std_luminance_quant_tbl;
> codec_context-> croma_intra_matrix
Hello,
I am trying to decode H265 frames in hardware (QSV) via ffmpeg (3.4.7) on
Intel CPU. Following command works perfectly on terminal ( OS : CentOS):
* build/lin_x64/bin/ffmpeg **-c:v hevc_qsv -load_plugin hevc_hw **-hwaccel
qsv -i -f null -*
I am trying to re-produce similar behaviour
I tried the following before opening the encoder:
codec_context-> intra_matrix = (uint16_t *) std_luminance_quant_tbl;
codec_context-> croma_intra_matrix = (uint16_t *) std_crominance_quant_tbl;
The picture has acquired a blue tint. When packet was written to a file,
DQT tables were not added to
