Deinterlacing "Bottom Frame First" footage in Double Framerate yields incorrect output
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- audio-video-rtc
Research direction
Start by reproducing the issue in OBS Studio 27.2.1 on Windows 10 with Bottom Field First footage, using Blend 2x, Linear 2x, or Yadif 2x deinterlacing in Bottom Fields First mode. Compare the output sequence with the expected ordered fields and the linked OBS log and videos; done means the output is no longer reordered as 1, 6, 3, 8, 5, 10.
Written by the indexing model from the issue text.
Description
Operating System Info
Windows 10
Other OS
No response
OBS Studio Version
27.2.1
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/XatW6D21UZ_tunCz
OBS Studio Crash Log URL
No response
Expected Behavior
Sets of fields should be reconstructed in their appropriate frames, constructing the first set of fields in every odd frame, and the second set of fields in every even frame. This results in smooth video output with every frame in order, represented by the pattern of 1, 2, 3, 4, 5, 6, [...].
This would match the existing working OBS behavior when "Top Fields First" footage is deinterlaced in "Top Fields First" mode.
Current Behavior
In the video output, top fields are delayed by 6 frames while bottom frames are constructed properly, resulting in a jerky video
constructed out of order in the pattern of 1, 6, 3, 8, 5, 10, [...]
Steps to Reproduce
- Add an input source that contains video content that is interlaced using the "Bottom Field First" method
- Enable the Deinterlacing using Blend 2x, Linear 2x or Yadif 2x
- Set the Deinterlacing mode to "Bottom Field First"
- Watch the video output
Anything else we should know?
If a "Top Fields First" video were to be properly deinterlaced with "Bottom Fields First", and vice versa, then the second set of fields should be constructed one frame behind, leading to a mildly jerky video output. This is expected behavior, and not the behavior currently achieved with this bug.
- Dominant language
- C
- Stars
- 76.4k
- Forks
- 10.2k
- Avg merge
- 4d 23h
- Merged PRs (30d)
- 12
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from obsproject/obs-studio
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
obsproject/obs-studio#13918 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
obsproject/obs-studio#13905 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
obsproject/obs-studio#13896 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
obsproject/obs-studio#13823 · 4 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
obsproject/obs-studio#13809 · 1 comment ·
All issues in obsproject/obs-studio
Similar issues
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·
-
bug Self Built Image SNAPSHOT Supported Device target/ramips
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100