nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Insane cropping (http://www.nvnews.net/vbulletin/showthread.php?t=165470)

seaweed 08-19-11 06:29 PM

Insane cropping
 
1 Attachment(s)
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 08-20-11 03:34 AM

Re: Insane cropping
 
Quote:

Originally Posted by seaweed (Post 2470036)
The camera sends out slightly larger height frames than 1080 (1084). And I repeatedly get these messages about every second:
Code:

[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 08-21-11 04:07 AM

Re: Insane cropping
 
Quote:

Originally Posted by cehoyos (Post 2470261)
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 08-21-11 04:11 AM

Re: Insane cropping
 
Quote:

Originally Posted by cehoyos (Post 2470261)
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 09-10-11 02:15 PM

Re: Insane cropping
 
Quote:

Originally Posted by seaweed (Post 2470650)
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.


All times are GMT -5. The time now is 09:46 AM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.