Closed julianscheel closed 7 years ago
Are you sure you've identified the correct firmware? The preceding one https://github.com/raspberrypi/firmware/commit/d760a4ffd378c648ff5d9854e26dc868a5e1fd09 looks much more likely to have affected deinterlace.
Can you provide a means to reproduce the issue? A binary zip file that when run produces a good image with older firmware and bad image with newer firmware should be sufficient.
Yes, I suspected d760a4f initially as well, so that one was my starting point when going back. But it works just fine, so I bisected from there to HEAD.
Let me try to generate a vlc build for raspbian, to test with.
Sorry, it took me a little longer to get back to this. I rechecked carefully and it seems up I f*cked up the bisect. The breaking commit is in fact d760a4f as initially suspected. I generated a pre-compiled VLC build you can use for testing on recent raspbian, following these instructions:
# Load and unpack prebuilt vlc
wget http://jusst.de/files/vlc-raspbian.tar.bz2
tar -xvf vlc-raspbian.tar.bz2
# Load demo sample (MPEG2, required decoder license)
wget http://jusst.de/files/pts-wrap.ts
# Install dependencies
sudo apt-get install libdvbpsi9
# Make sure to have enough GPU mem set, otherwise you might run into
# ENOSPC errors!
# Start playback
export LD_LIBRARY_PATH=/home/pi/local/usr/local/lib
/home/pi/local/usr/local/bin/vlc pts-wrap.ts
The first frames look fine, until VLC enables the deinterlace filter. Then stuff is garbled. Once you revert the Raspberry firmware to 6ce98b98 it will work as expected. Maybe you could give some more insights on what changed in the image_fx module in that commit?
Thanks - can reproduce.
Okay, I see the problem. We added an flag to use qpu based deinterlace which has significantly better performance. We switched to use this by default in kodi and omxplayer some time ago. E.g. https://github.com/popcornmix/omxplayer/commit/d99bd86c9fd80ea01f98761e130d7ac9a2bb7588#diff-0499cc94e7babb87b7fbdbc0d621a4e8L283
Setting the "use_qpus" flag should avoid the problem.
However the breakage of non-qpu deinterlace for opaque was unintended. Can you test this firmware to confirm problem is fixed? (Although I'd recommend using the use_qpus flag anyway). https://drive.google.com/uc?id=0B-6zmEDJwxZEczh2b2g2bzRIZTA&export=download
Thanks, I can confirm this firmware fixes the issue. We did not change to qpu as default in VLC as for 1080i on Raspi 1 we run into framedrops with it enabled. Probably because the overall system load is a bit higher when running with VLC then it is with omxplayer. It can be enabled using --mmal-deinterlace-adv-qpu though.
For the non-qpu code, we will fall back to fast (bob) deinterlace when resolution > 576 * 720. As qpu code can handle 1920x1080 (assuming things are not too busy) that fallback doesn't occur but you could always make the switch from client.
Can you test latest rpi-udpate firmware? Should include this fix.
Thanks, it's fixed with recent firmware
While updating the Raspberry kernel and firmware in our build I discovered a regression in the mmal image_fx module when fed with opaque images (does it support non-opaque input in the meantime?) as we do in VLC. Instead of deinterlaced pictures we just get completely garbled greenish output out of image_fx. This regression was introduced with commit 6d45dcf869688163fa1c745cb059b14baf61b8fd. The commit message does not revela anything spurious, maybe something changed which was not mentioned in the commit msg?