* [FFmpeg-devel] NVENC shows significantly worse compression efficiency than libx264 for MPEG-2 (MPG) + YADIF
@ 2025-12-28 19:20 Sheikh Afnan via ffmpeg-devel
2025-12-28 21:00 ` [FFmpeg-devel] " Timo Rothenpieler via ffmpeg-devel
0 siblings, 1 reply; 2+ messages in thread
From: Sheikh Afnan via ffmpeg-devel @ 2025-12-28 19:20 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Sheikh Afnan
Hello FFmpeg developers,
I would like to report and understand a compression behavior I am
consistently observing with FFmpeg, specifically when using NVENC on MPEG-2
(MPG) sources.
Test case summary
Input
Container: MPG
Codec: MPEG-2 (interlaced)
Duration: ~19 minutes
Size: ~2 GB
FPS: 25
Source has no visible combing in original playback
1. CPU (libx264) – Interlaced encode (no yadif)
Command:
ffmpeg -y ^
-i "02 SHUKRANA CEREMONY.mpg" ^
-map 0:v:0 -map 0:a:0 ^
-c:v libx264 ^
-flags +ilme+ildct ^
-x264-params tff=1 ^
-crf 25 ^
-preset slow ^
-pix_fmt yuv420p ^
-c:a aac -b:a 192k ^
-movflags +faststart ^
"CPU_interlaced.mp4"
Compression worked
File size reduced significantly
However, horizontal combing lines appeared on only mobile device but it
worked nice on PCs
2. CPU (libx264) – Deinterlaced using YADIF
Command:
ffmpeg -y ^
-i "02 SHUKRANA_1m30s_to_3m30s.mpg" ^
-map 0:v:0 -map 0:a:0 ^
-vf "yadif=1:-1:0" ^
-c:v libx264 ^
-crf 25 ^
-preset slow ^
-profile:v high ^
-level 4.2 ^
-pix_fmt yuv420p ^
-c:a aac -b:a 192k ^
-movflags +faststart ^
"CPU_YADIF.mp4"
Result
Visual quality: excellent
No combing or lines on any device
File size: ~900 MB (from ~2 GB) → ~55–60% reduction
Encoding time: ~30 minutes for 19 minutes of video
3. GPU (NVENC) – Deinterlaced using YADIF (bob)
Command:
ffmpeg -y ^
-i "02 SHUKRANA CEREMONY.mpg" ^
-map 0:v:0 -map 0:a? ^
-vf "yadif=mode=1:parity=auto:deint=all" ^
-c:v h264_nvenc ^
-preset p6 ^
-rc vbr ^
-cq 25 ^
-b:v 0 ^
-g 50 ^
-profile:v high ^
-pix_fmt yuv420p ^
-spatial-aq 1 ^
-temporal-aq 1 ^
-aq-strength 7 ^
-c:a aac -ac 2 -b:a 192k ^
-movflags +faststart ^
"NVENC_YADIF.mp4"
Result
Visual quality: excellent
No combing or lines on any device
Encoding time: ~6 minutes
But output size: ~1.95 GB (only ~500 MB reduction)
Key Observation
This size inefficiency only happens with MPG / MPEG-2 inputs
Other formats (MP4, MTS, MOV, H.264 sources) compress normally with NVENC
CPU libx264 consistently achieves much higher compression efficiency on the
same MPG sources
NVENC appears to allocate significantly more bitrate when:
Input codec is MPEG-2
Source is interlaced
YADIF bob is applied (FPS doubling)
Questions
Is this expected behavior due to NVENC hardware limitations with MPEG-2
sources?
Does NVENC treat MPEG-2 noise / interlacing conservatively compared to
libx264?
Are there any recommended NVENC parameters or preprocessing steps to
improve compression efficiency for MPEG-2 inputs?
Is this a known limitation rather than a bug?
Why this matters
In production workflows:
NVENC is excellent for speed and modern codecs
However, for legacy MPG archives, CPU encoding gives far better size
efficiency
Understanding whether this is expected or tunable would help software
decisions
Thank you for your work on FFmpeg and for any clarification on this
behavior.
Best regards,
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
^ permalink raw reply [flat|nested] 2+ messages in thread
* [FFmpeg-devel] Re: NVENC shows significantly worse compression efficiency than libx264 for MPEG-2 (MPG) + YADIF
2025-12-28 19:20 [FFmpeg-devel] NVENC shows significantly worse compression efficiency than libx264 for MPEG-2 (MPG) + YADIF Sheikh Afnan via ffmpeg-devel
@ 2025-12-28 21:00 ` Timo Rothenpieler via ffmpeg-devel
0 siblings, 0 replies; 2+ messages in thread
From: Timo Rothenpieler via ffmpeg-devel @ 2025-12-28 21:00 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Timo Rothenpieler
[-- Attachment #1.1.1.1: Type: text/plain, Size: 407 bytes --]
I'm not exactly sure I follow.
For one, nvenc CQ values do not in any way relate to x264 crf values.
You need to figure out each individual numbers that works for you.
Also, the input codec and used filters have little to not impact on the
output.
Hardware encoders are worse than software ones at the same bitrate,
quality wise. That's not a bug, but just how things work and are.
Timo
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
[-- Attachment #2: Type: text/plain, Size: 163 bytes --]
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-12-28 21:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-28 19:20 [FFmpeg-devel] NVENC shows significantly worse compression efficiency than libx264 for MPEG-2 (MPG) + YADIF Sheikh Afnan via ffmpeg-devel
2025-12-28 21:00 ` [FFmpeg-devel] " Timo Rothenpieler via ffmpeg-devel
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git