вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
> > > > Den 11.11.2024 22:34, skrev Andrew Randrianasulu: > > > > вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>: > >> >> >> >> Den 11.11.2024 22:20, skrev Andrew Randrianasulu: >> >> >> >> пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>: >> >> {snip} >> >> >> >>> . >>>>> >>>>> >>>>> >>>>> hevc_qsv.mp4 revised: >>>>> pixel formats p010le and y210le render again to yuv420p10le and >>>>> .yuv422p10le respectively >>>>> Woops; only when these window lines are commented out as written in my >>>>> previous post ! >>>>> >>>>> # profile=main >>>>> # cin_pix_fmt=nv12 >>>>> >>>>> Works both with and without >>>>> export CIN_10BIT_ENC=1 >>>>> before cin/bin >>>>> >>>> >>>> >>>> we most likely will need new profiles for 10bit everything anyway ... >>>> >>>> thanks for continued (and very exhaustive!) testing >>>> >>>> >>>> Also the preset's combination of pixel formats and the right (ffmpeg) >>>> codec profiles would need an overhaul. >>>> >>>> As mentioned already above: >>>> >>>> hevc_qsv.mp4 revised: >>>> pixel formats p010le and y210le render again to yuv420p10le and >>>> .yuv422p10le respectively >>>> Woops; only when these window lines are commented out as written in my >>>> previous post ! >>>> >>>> # profile=main >>>> # cin_pix_fmt=nv12 >>>> >>>> >>>> I experimented additional and got >>>> >>>> y210/profile=1 ==> yuv422p10le >>>> >>>> y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le >>>> >>>> I got similar results with my own dynamic Cingg built with ffmpeg 7.1. >>>> >>>> -------------------------- >>>> >>>> So a question beside: >>>> >>>> Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which >>>> replaced Packman package libs and ffmpeg 7.1 >>>> >>>> After that, the static Cingg with onevpl and 10bit patch would not >>>> render hevc_qsv. >>>> >>>> Today's upgrade with new Packman packages up-to-date with the new >>>> Slowroll version, and now Cingg worked as before: >>>> >>>> ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel >>>> ffmpeg-7-libavfilter-devel >>>> ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel >>>> ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel >>>> ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 >>>> libavformat61 libavutil59 libpostproc58 >>>> libswresample5 libswscale8 >>>> >>>> So even Cingg with onevpl is static built, it looks like it is >>>> dependent of one or more system packages/libs beside? >>>> Any idea what packages it can be ? >>>> >>> >>> >>> onevpl/vaapi/vdpau - they all linked dynamically (not sure if static >>> version of them even possible) >>> >>> >>> Ah, I see. >>> >>> I tried to compare the two configure lines for my full dynamic >>> Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively: >>> >>> ./configure --with-single-user --disable-static-build >>> --without-thirdparty --without-libdpx >>> ./configure --with-single-user --with-onevpl >>> >>> As the first line didn't mention "vpl" I searched backwards and got the >>> understanding that the source code was patched to use the system libvpl. >>> >> >> not exactly, in first case it just uses libav* from system ffmpeg >> package... and this in your case uses libvpl. >> >> >> In the second case the build-system itself was patched with onevpl >>> (default off) to use the same system libvpl, I assume? >>> >>> Is/will possibly the current or upcoming Cingg appimage/rpm available >>> with the onevpl patch, so it can be switched on and tested on other >>> available hardware? >>> >> >> >> I was about to ask if onevpl patch can be added to git ... >> >> Dear Phyllis, can you add onevpl.patch so future QSV testing will be >> easier (it defaults to off so should not break anything ... by default). >> >> while there, Terje, can you pack your latest profile work and send it >> separately? >> >> > Do you mean to attach them with filenames to a separate post here or? > yes. > I think we use codec_encoder_additional_params.container as format >> >> so 10bit 420 hevc qsv for mp4 will look like >> >> hevc_qsv_10bit.mp4 >> >> with content you experimentally determinated. >> >> and y210 probably will be named >> >> hevc_qsv_y210.mp4 >> >> >> What about >> >> hevc_qsv_10bit-420.mp4 >> >> and >> >> hevc_qsv_10bit-422.mp4 >> >> respectively? >> > > > > if those relative long names fit their box - then ok ... > > > An alternative short(er) form and still a relative unambiguous description > > hevc_qsv_10b420.mp4 > hevc_qsv_10b422.mp4 > then make them so! > > > >>> >>> >> >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
