Insane cropping

[seaweed]

Hi Im am trying to decode a 1080 P H264 video stream from a camera with VDPAU (driver version 260.19.04) . I am seeing the message below while decoding. The camera sends out slightly larger height frames than 1080 (1084). And I repeatedly get these messages about every second:

Last message repeated 1 times
[h264_vdpau @ 0x7f210c46df30]insane cropping not completely supported, this could look slightly wrong ...
[h264_vdpau @ 0x7f210c46df30]no frame!


Could this be related to the 4 extra pixels that the camera sends out ? When rednering - I cropped the top 4 pixels from src rect of the video surface. But I till get these messages. More elaborate VDPAU traces are in the attached file insane_cropping.txt.gz

If anybody have any clue, please shout thanks

[cehoyos]

Originally Posted by seaweed

The camera sends out slightly larger height frames than 1080 (1084). And I repeatedly get these messages about every second:

[h264_vdpau @ 0x7f210c46df30]insane cropping not completely supported, this could look slightly wrong ...

The problem is that the camera requests that the 4 (?) pixel are cropped on top (not on bottom, as usual). Consider attaching a very short sample to a bug-report on http://bugzilla.mplayerhq.hu or http://avcodec.org/trac/ffmpeg (am I correct that the problem you see is not specific to VDPAU, but also happens with the software decoder?) or uploading to http://www.datafilehost.com/

Carl Eugen

[seaweed]

Originally Posted by cehoyos

The problem is that the camera requests that the 4 (?) pixel are cropped on top (not on bottom, as usual). Consider attaching a very short sample to a bug-report on http://bugzilla.mplayerhq.hu or http://avcodec.org/trac/ffmpeg (am I correct that the problem you see is not specific to VDPAU, but also happens with the software decoder?) or uploading to http://www.datafilehost.com/

Carl Eugen

Hi Carl, Thanks for your response. I captured some raw H.264 bitstream in a file and uploaded at http://www.datafilehost.com/download-f537c855.html. Its interesting that when this video stream is wrapped within RTMP packets and submitted to flash, flash player plays it fine - with no extra 4 bytes at the top and no signs of hiccups.

[seaweed]

Originally Posted by cehoyos

The problem is that the camera requests that the 4 (?) pixel are cropped on top (not on bottom, as usual). Consider attaching a very short sample to a bug-report on http://bugzilla.mplayerhq.hu or http://avcodec.org/trac/ffmpeg (am I correct that the problem you see is not specific to VDPAU, but also happens with the software decoder?) or uploading to http://www.datafilehost.com/

Carl Eugen

Hi Carl, Thanks for your response. I captured some raw H.264 bitstream in a file and uploaded at http://www.datafilehost.com/download-f537c855.html. Its interesting that when this video stream is wrapped within RTMP packets and submitted to flash, flash player plays it fine - with no extra 4 bytes at the top and no signs of hiccups. haven't tried software decode but it will probably act the same - perhaps it happens during h264 NALU parsing. The parser seems to cause latency issues when this happens (stuck for couple of seconds).

[seaweed]

Originally Posted by seaweed

Hi Carl, Thanks for your response. I captured some raw H.264 bitstream in a file and uploaded at http://www.datafilehost.com/download-f537c855.html. Its interesting that when this video stream is wrapped within RTMP packets and submitted to flash, flash player plays it fine - with no extra 4 bytes at the top and no signs of hiccups. haven't tried software decode but it will probably act the same - perhaps it happens during h264 NALU parsing. The parser seems to cause latency issues when this happens (stuck for couple of seconds).

FYI - It was actually 2 pixels from top and 2 pixels from bottom. I found later on that the bitstreams from the camera itself was sparse, nothing to do with header parsing. I saw the feature request posted to FFMpeg about this from you.