Is 'rawvideoparse' element reading the wrong amount of bytes?

[Antonio Ospite]

On Mon, 30 Dec 2019 11:19:47 -0500
Nicolas Dufresne <nicolas at ndufresne.ca> wrote:

> Le lun. 30 déc. 2019 04 h 30, Aschwin Brandt <aschwin.brandt at gmail.com> a
> écrit :
> 
> > Hello all,
> >
> > This is my first post, so please inform me if I break any rules.
> >
> > I'm reading a byte-stream YUV420 at 972x720 pixels from a file with
> > Gstreamer using the following command:
> >
> > gst-launch-1.0 filesrc location=testfile blocksize=1049760 ! rawvideoparse
> > width=972 height=720  framerate=1/1 ! xvimagesink
> >
> > This works in so far that I get an image but this image isn't displayed
> > correctly. It looks like it contains part of the next YUV frame. When
> > exporting the frames seperately using command:
> >
> > gst-launch-1.0 filesrc location=testfile blocksize=1049760 ! rawvideoparse
> > width=972 height=720  framerate=1/1 ! multifilesink location="rvp_%d.raw"
> >
> > And play it using ffmpeg command:
> >
> > ffplay -f rawvideo -video_size 972x720 -pixel_format yuv420p -i rvp_0.raw
> >
> > The video (one frame) is displayed correctly.
> >
> > I see that when using the element 'rawvideoparse' it will create a file of
> > 1051200 bytes per frame instead of the expected 1049760. When I remove
> >
> 
> I'm not sure why this odd value. It sounds like a bug to me, or some half
> thought feature. Best is to investigate were the buffer size get augmented.
> I've checked in the video info code, and it should chose 1049760.
>

The issue is probably in
gst-plugins-base/gst-libs/gst/video/video-info.c

When fill_planes() calculates components sizes for GST_VIDEO_FORMAT_I420
is assumes that U and V strides should be multiple of 4, is this really
a requirement?

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?