Giters

IENT / YUView

The Free and Open Source Cross Platform YUV Viewer with an advanced analytics toolset

Home Page:http://ient.github.io/YUView

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

crash after playing RGB planar format sequence

JIANKV opened this issue · comments

commented

Describe the bug
I have some video sequences, and the format is RAW RGB planar, that means RRRR....RRRRRGGGG...GGGGGBBBB...BBBBB. The bit depth is byte, the resolution is 2560x1440 and total frame # is 100.

After loading the sequence, the player can play several frames(3~4 frame) and then player crash.

To Reproduce
Steps to reproduce the behavior:

  1. drag the video sequence to playlist;
  2. choose "Raw RGB File" in the "Select file type" of dialog box;
  3. input the resolution: 2440(W) and 1440(H);
  4. chose "custom" in "RGB Format" --> "RGB" in "RGB Order", "8" in Bit Depth and check the "Planar".
  5. Play.

Version (please complete the following information):

  • OS: WINDOWS 10
  • Version v2.13
commented

Hi. Thanks for the report. I will try to reproduce it. Did you create the RGB file with ffmpeg? Which pixel format did you use? So 8 bit and no alpha channel, right?

commented

So I was able to reproduce this. I just created a test RGB video and opened it. When I select to specify a custom RGB format and select planar and press OK, it crashes. Sometimes it still works. But then, if I hit play, the crash happens.

commented

Hi. Thanks for the report. I will try to reproduce it. Did you create the RGB file with ffmpeg? Which pixel format did you use? So 8 bit and no alpha channel, right?

Sorry for the late reply.
The RGB file has no header information except data, 8-bit per pixel and no alpha channel. It is a by-product of my project, not FFMPEG output. I could play it sucessfully with another tool(like vooya...).

commented

I have found the bug and I am fixing it. I was just struggling a bit with a proper test. So this bug only seems to occur on windows actually. On other platforms the invalid memory read access does not cause a crash. Or my suspicion is that the compilers on the other platforms optimize out this access.

commented

Ok I don't get that. So ffmpeg had a bug in their testing so testing is not worth it? I am sorry but as a professional software developer I have to strongly disagree. I think this tells us that we must be even more rigorous and focused on testing.

Anyway the bug is fixed and merged alongside a bunch of tests.