Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

h264 video file crash video playback capabilities until next reboot. #549

Closed
nagualcode opened this issue Feb 27, 2016 · 7 comments
Closed

Comments

@nagualcode
Copy link

Hello, this raw h264 video file makes hello_video.bin crash.

https://www.dropbox.com/s/uwiml8iddp625a2/crashvideo.h264?dl=0

After any attempt to play this video, no other video can be played. Including any good .mp4 video with omxplayer, or good raw .h264 with hello_video.bin
The system is not crashed after the attempt.. The command prompt is working and other process can be started including the loading of images with FBI. But video playback capabilities are gone, system wide, until the next reboot.
The video plays fine in on desktop computer with MPV player.
What could it be?

@6by9
Copy link

6by9 commented Feb 28, 2016

Admittedly I'm running a debug firmware build, but it's not crashing my build. There are a few asserts firing though, and the output isn't useful (mainly green).
What will be happening in your case is that you have managed to crash the GPU such that it will not accept further jobs via OpenMaxIL. In theory a debug build shouldn't make any difference, but you may get slightly different results if you enable asserts (add start_debug=1 to /boot/config.txt)

Looking at the file, avprobe describes it as:
Stream #0.0: Video: h264 (High 4:2:2), yuv422p, 1920x1080 [PAR 1:1 DAR 16:9]
I suspect the codec hardware doesn't support YUV4:2:2 - most files are YUV 4:2:0. Normally it outputs in a weird layout of YUV420 and there isn't a YUV422 equivalent, hence my suspicion.

@deborah-c
Copy link

The codec only supports 4:2:0 video (or monochrome); theoretically we could support (and may or may not have written the code for -- I forget) 4:4:4 with separate planes, but I don't think the rest of the system would understand it... This is a hardware limitation.

Having said this, the codec certainly shouldn't crash if presented with this; it just won't produce any output.

@nagualcode
Copy link
Author

Thank for all the info.
On my MODEL B+ with raspbian wheezy, and gpu_men=128, playing this video with hello_video.bin I get blank output... After this attempt no video playing works anymore. Exmaple, if I try to use omxplayer with a proper .mp4 movie, I get a bunch of error msgs. If I Try hello_video.bin to play a good .h264, I get a blank output (but the process quits after video play lenght).

@6by9
Copy link

6by9 commented Feb 29, 2016

As deborah-c has confirmed, the hardware does not support High 4:2:2 Profile. I can take a look as to why it crashes, but you will never be able to play that file on a Pi.
What version of kernel and firmware are you using? The output from vcgencmd version and uname -a please.

@deborah-c Where would that profile be signaled? Just from header bytes with profile_idc==122 by the looks of it. dec_requirements the right place to throw the error?
I certainly saw it producing garbage frames when I tried this file yesterday, so it's not currently throwing it out.

@nagualcode
Copy link
Author

Jun 10 2015 20:42:58
Copyright (c) 2012 Broadcom
version a0f9db571a2bb980469502bd4de2c9793b3223c4 (clean) (release)
Linux pi 3.18.0-trunk-rpi #1 PREEMPT Debian 3.18.5-1~exp1+rpi19 (2015-08-08) armv6l GNU/Linux

@6by9
Copy link

6by9 commented Feb 29, 2016

That image is 9 months out of date, so things may well have been improved to not crash, even if we don't just throw the clip out as unsupported.
Please test against a fresh download from https://www.raspberrypi.org/downloads

popcornmix added a commit that referenced this issue Jun 27, 2016
… a size error

firmware: image_fx: Avoid setting the vpitch for YUVUV buffers
firmware: image_fx: Add YUVUV as supported type
firmware: image_fx: relax check on inout/output formats to support standalone deinterlace

firmware: h264_parse: Silently discard macroblocks with unsupported profile
See: #549

userland: MMAL_VC_SHM: Explicitly lock buffer when requested
See: raspberrypi/userland@dd9636d

userland: khronos: Use vchiq_get_client_id to determine global PID
See: raspberrypi/userland#315

userland: various warning fixes
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Jun 27, 2016
… a size error

firmware: image_fx: Avoid setting the vpitch for YUVUV buffers
firmware: image_fx: Add YUVUV as supported type
firmware: image_fx: relax check on inout/output formats to support standalone deinterlace

firmware: h264_parse: Silently discard macroblocks with unsupported profile
See: raspberrypi/firmware#549

userland: MMAL_VC_SHM: Explicitly lock buffer when requested
See: raspberrypi/userland@dd9636d

userland: khronos: Use vchiq_get_client_id to determine global PID
See: raspberrypi/userland#315

userland: various warning fixes
@popcornmix
Copy link
Contributor

@fredericofs latest rpi-update firmware will now avoid decoding formats it knows aren't supported.
Your sample file should no longer crash (but you won't see any video).
Please test and close if okay.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
… a size error

firmware: image_fx: Avoid setting the vpitch for YUVUV buffers
firmware: image_fx: Add YUVUV as supported type
firmware: image_fx: relax check on inout/output formats to support standalone deinterlace

firmware: h264_parse: Silently discard macroblocks with unsupported profile
See: raspberrypi#549

userland: MMAL_VC_SHM: Explicitly lock buffer when requested
See: raspberrypi/userland@dd9636d

userland: khronos: Use vchiq_get_client_id to determine global PID
See: raspberrypi/userland#315

userland: various warning fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants