Bug Report OBS Studio produces corrupted video files

Vort

Vort

New Member
Hi.
Do anyone want to fix bug #0001506 ?
Log file is here.

Video file upload fails with "The uploaded file does not have an allowed extension" message.
It is better to say which one is allowed.
That is bug report inside bug report.
 
R

R1CH

Forum Admin
Developer
You may want to upgrade to Windows 10 then, the Intel drivers for Windows 7 are quite dated and may have QSV related bugs.
 
Vort

Vort

New Member
I have found this topic, which suggests to set "Consecutive B Frame Count" option to 0.
However OBS Studio 23.2.1 have no such option.
Then I decided to find older version.
Downloaded 19.0.2. Still no option. Checked if glitch reproduces.
At first look, there was no bug! After closer look, I have found that if I change video position in VLC, "square" glitches appear.
Next stop is version 0.13.4. It have B Frame option. But that option was not needed in my case. I can't reproduce glitches even with default options.
Which means that it is possible to use OBS Studio + QSV + Intel HD Graphics 4600 (15.36.36.5067) + Windows 7 SP1 x64.
After some bugfixing / tuning.
 
Vort

Vort

New Member
Version 0.14.1 adds slight glitch variant.
And here is what located in changelog: "Added full Intel QuickSync encoder and deprecated the Microsoft Media Foundation QuickSync encoder"
Maybe new encoder is worse, maybe it is now used with parameters, which are not supported on my hardware.
 
Vort

Vort

New Member
It is possible to move from "big glitch" to "slight glitch" with 23.2.1 version by changing async_depth from 4 to 1.
 
Vort

Vort

New Member
I have tried to reproduce bug with FFmpeg:
ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -v verbose -i akiyo_cif.y4m -c:v h264_qsv -async_depth 4 -global_quality 16 -g 90 -bf 7 -flags -cgop -profile:v high output.mp4
(akiyo_cif.y4m is here)
And result is: good video file.
So it really can be a problem with obs-qsv11.
 
R

R1CH

Forum Admin
Developer
OBS uses its own QSV implementation which interfaces with the Intel Media SDK directly which is likely why it's differing from ffmpeg. QSV is quite driver dependent, so if you're able to upgrade to Windows 10 and newer drivers and confirm if it still reproduces we can look into it.
 
Vort

Vort

New Member
R1CH said:
OBS uses its own QSV implementation which interfaces with the Intel Media SDK directly which is likely why it's differing from ffmpeg
Click to expand...
FFmpeg use the same "mfx" library.
FFmpeg:
q->param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
OBS:
m_mfxEncParams.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
So if FFmpeg can produce valid files, then OBS also can do this.
Theoretically problem can be catched by merging of "good" and "bad" implementations.
At some point, either "good" version will become "bad", or "bad" become "good".
Are there any possibility of feeding raw source stream directly to obs-qsv11 without making source code modifications?
Comparing of FFmpeg and OBS output data can also help. If sources are exactly the same.
 
Last edited:
Vort

Vort

New Member
R1CH said:
QSV is quite driver dependent, so if you're able to upgrade to Windows 10 and newer drivers and confirm if it still reproduces we can look into it.
Click to expand...

Glitch is also reproducing with Windows 10.
Here is the log file.

Since nobody told me how to upload video file here, I sent it to dropmefiles: 2019-07-17 17-08-26.mp4.
And here is screenshot of VLC playing this file:
obs_qsv_win10.png

Driver version: win64_15.40.42.5063.zip.
 
Vort

Vort

New Member
Looks like pixel data inside file is correct and problem is in metadata.
I was able to correct problematic file with FFmpeg.
Will investigate further.

upd. Most likely, h264 stream is fine. The differences between bad and good (reconstructed) files starts showing at offsets after stream data.
 
Last edited:
R

R1CH

Forum Admin
Developer
I'm getting various different results based on what I use to playback, definitely something not quite right. I'm not very familiar with our QSV implementation unfortunately so I'm not sure where to look to fix this.
 
Vort

Vort

New Member
I guess that problem is related to ctts table generation.
If I convert video this way:
ffmpeg -i "2019-07-17 17-08-26.mp4" -vcodec copy 1.264 ffmpeg -r 30 -i 1.264 -c copy 2.mp4
it plays (and seeks/scrolls) perfectly both with latest MPC-HC and VLC.
When I load it into onlinemp4parser, expand tree as moov -> trak -> mdia -> minf -> stbl, I see no ctts section there.
While "original" file contains it.
Maybe these lines from obs-qsv11 source code are related to calculation of values for ctts?
packet->dts = pBS->DecodeTimeStamp * fps_num / 90000;
 
Vort

Vort

New Member
The problem was with line
packet->keyframe = (pBS->FrameType & (MFX_FRAMETYPE_I | MFX_FRAMETYPE_REF));
But after I found the fix today, I discovered, that it is already fixed in master with commit b675bed9.
And nobody told me about it :/
 
R

R1CH

Forum Admin
Developer
Thanks for following up on this, it's good to know that the commit does actually fix this bug.
 
You must log in or register to reply here.
Top