[FFmpeg-trac] #11155(avcodec:new): Clarification on x264 "deblock" of lossless
FFmpeg
trac at avcodec.org
Mon Aug 26 04:12:03 EEST 2024
#11155: Clarification on x264 "deblock" of lossless
-------------------------------------+-------------------------------------
Reporter: | Owner: (none)
MasterQuestionable |
Type: task | Status: new
Priority: normal | Component: avcodec
Version: unspecified | Resolution:
Keywords: libx264 | Blocked By:
documentation |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by MasterQuestionable):
͏
https://www.google.com/search?hl=en&gl=ca&num=10&q=x264+lossless|%22qp+0%22
+%22no-deblock%22
͏ https://forum.doom9.net/showthread.php?p=1871282
͏ https://stackoverflow.com/questions/69755864#77176160
͏ Why should "deblock" even matter for lossless..?
͏ Not even to mention various H.265 bizarreries...
͏ Experimented with below sample:
͏ `ffmpeg -y -v trace -hide_banner -nostdin -nostats -ignore_editlist 1
-i "trembling_text_input.mp4" -pix_fmt yuv444p -sws_flags
spline+accurate_rnd+full_chroma_int -c:v libx264 -preset placebo -qp 0
-x264-params "keyint=infinite:no-deblock=1" -flags +bitexact -fflags
+bitexact -map_metadata -1 -map_chapters -1 -cues_to_front 1 -write_crc32
0 -default_mode 0 "yuv444p.mkv"`
͏ Mostly no output difference.
͏ The only difference would be the written in-file encoding settings:
"deblock=0:0:0"...
͏ Which is just sort of metadata, much unused.
͏ See also:
https://github.com/richtr/NoSleep.js/issues/157#issuecomment-1529156077
͏ Maybe then x264 had bugs with it? Considering x265's...
\\
\\
͏ "trembling_text_input.mp4":
͏ https://trac.ffmpeg.org/raw-
attachment/ticket/11149/trembling_text_input.mp4
͏ (~ 525.49 KiB)
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11155#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list