<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 30 déc. 2019 12 h 44, Antonio Ospite <<a href="mailto:ao2@ao2.it">ao2@ao2.it</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 30 Dec 2019 11:19:47 -0500<br>
Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank" rel="noreferrer">nicolas@ndufresne.ca</a>> wrote:<br>
<br>
> Le lun. 30 déc. 2019 04 h 30, Aschwin Brandt <<a href="mailto:aschwin.brandt@gmail.com" target="_blank" rel="noreferrer">aschwin.brandt@gmail.com</a>> a<br>
> écrit :<br>
> <br>
> > Hello all,<br>
> ><br>
> > This is my first post, so please inform me if I break any rules.<br>
> ><br>
> > I'm reading a byte-stream YUV420 at 972x720 pixels from a file with<br>
> > Gstreamer using the following command:<br>
> ><br>
> > gst-launch-1.0 filesrc location=testfile blocksize=1049760 ! rawvideoparse<br>
> > width=972 height=720  framerate=1/1 ! xvimagesink<br>
> ><br>
> > This works in so far that I get an image but this image isn't displayed<br>
> > correctly. It looks like it contains part of the next YUV frame. When<br>
> > exporting the frames seperately using command:<br>
> ><br>
> > gst-launch-1.0 filesrc location=testfile blocksize=1049760 ! rawvideoparse<br>
> > width=972 height=720  framerate=1/1 ! multifilesink location="rvp_%d.raw"<br>
> ><br>
> > And play it using ffmpeg command:<br>
> ><br>
> > ffplay -f rawvideo -video_size 972x720 -pixel_format yuv420p -i rvp_0.raw<br>
> ><br>
> > The video (one frame) is displayed correctly.<br>
> ><br>
> > I see that when using the element 'rawvideoparse' it will create a file of<br>
> > 1051200 bytes per frame instead of the expected 1049760. When I remove<br>
> ><br>
> <br>
> I'm not sure why this odd value. It sounds like a bug to me, or some half<br>
> thought feature. Best is to investigate were the buffer size get augmented.<br>
> I've checked in the video info code, and it should chose 1049760.<br>
><br>
<br>
The issue is probably in<br>
gst-plugins-base/gst-libs/gst/video/video-info.c<br>
<br>
When fill_planes() calculates components sizes for GST_VIDEO_FORMAT_I420<br>
is assumes that U and V strides should be multiple of 4, is this really<br>
a requirement?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Indeed I missed it. I don't think it's a requirement, but we are likely stuck with this legacy, as some code will assume that if there is no video meta support.</div><div dir="auto"><br></div><div dir="auto">rawvideoparse let you specify the strides and offset, can we get this file to be parsed with that set ? (Syntax is <stride,ustride,vstride>)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ciao,<br>
   Antonio<br>
<br>
-- <br>
Antonio Ospite<br>
<a href="https://ao2.it" rel="noreferrer noreferrer" target="_blank">https://ao2.it</a><br>
<a href="https://twitter.com/ao2it" rel="noreferrer noreferrer" target="_blank">https://twitter.com/ao2it</a><br>
<br>
A: Because it messes up the order in which people normally read text.<br>
   See <a href="http://en.wikipedia.org/wiki/Posting_style" rel="noreferrer noreferrer" target="_blank">http://en.wikipedia.org/wiki/Posting_style</a><br>
Q: Why is top-posting such a bad thing?<br>
</blockquote></div></div></div>