Is 'rawvideoparse' element reading the wrong amount of bytes?
Locked
Is 'rawvideoparse' element reading the wrong amount of bytes?
 
|
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 'rawvideoparse' the right amount of bytes are written but this doesn't work in a video pipeline and my objective is to read them directly from the file into an 'xvimagesink' Am I messing up or is there a bug in the rawvideoparse element? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
On Mon, 30 Dec 2019 09:24:55 +0100
Aschwin Brandt <[hidden email]> wrote: > 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 > When using rawvideoparse you can pass the format explicitly and let the element figure out frame boundaries by itself, and if you pass the format then specifying blocksize upstream becomes unnecessary. The element documentation can be read with: gst-inspect-1.0 rawvideoparse 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? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
In reply to this post by Aschwin23452345
Le lun. 30 déc. 2019 04 h 30, Aschwin Brandt <[hidden email]> a écrit :
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
On Mon, 30 Dec 2019 11:19:47 -0500
Nicolas Dufresne <[hidden email]> wrote: > Le lun. 30 déc. 2019 04 h 30, Aschwin Brandt <[hidden email]> 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? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
Le lun. 30 déc. 2019 12 h 44, Antonio Ospite <[hidden email]> a écrit : On Mon, 30 Dec 2019 11:19:47 -0500 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. rawvideoparse let you specify the strides and offset, can we get this file to be parsed with that set ? (Syntax is <stride,ustride,vstride>)
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
Thanks for the help guys! I also tested it with different resolutions as
follows: ffmpeg -f lavfi -i testsrc=duration=30:size=972x720:rate=30 -vf drawtext="fontfile=/path/to/font.ttf: \ text='Stream A': fontcolor=white: fontsize=24: box=1: boxcolor=black@0.5: \ boxborderw=5: x=(w-text_w)/2: y=(h-text_h)/2" -pix_fmt yuv420p stream_a.yuv -y gst-launch-1.0 filesrc location=stream_a.yuv ! rawvideoparse width=972 height=720 framerate=1/1 ! xvimagesink ffmpeg -f lavfi -i testsrc=duration=30:size=1080x720:rate=30 -vf drawtext="fontfile=/path/to/font.ttf: \ text='Stream A': fontcolor=white: fontsize=24: box=1: boxcolor=black@0.5: \ boxborderw=5: x=(w-text_w)/2: y=(h-text_h)/2" -pix_fmt yuv420p stream_a.yuv -y gst-launch-1.0 filesrc location=stream_a.yuv ! rawvideoparse width=1080 height=720 framerate=1/1 ! xvimagesink And the latter one displays the correct image. I guess the quickest solution for me is to use another resolution. One last question: do I need to create a bug report for this? And if yes, where? Thanks again! -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Is 'rawvideoparse' element reading the wrong amount of bytes?
|
|
On Tue, 31 Dec 2019 06:13:14 -0600 (CST)
Aschwin23452345 <[hidden email]> wrote: > Thanks for the help guys! I also tested it with different resolutions as > follows: > > ffmpeg -f lavfi -i testsrc=duration=30:size=972x720:rate=30 -vf > drawtext="fontfile=/path/to/font.ttf: \ > text='Stream A': fontcolor=white: fontsize=24: box=1: boxcolor=black@0.5: \ > boxborderw=5: x=(w-text_w)/2: y=(h-text_h)/2" -pix_fmt yuv420p stream_a.yuv > -y > > gst-launch-1.0 filesrc location=stream_a.yuv ! rawvideoparse width=972 > height=720 framerate=1/1 ! xvimagesink > > ffmpeg -f lavfi -i testsrc=duration=30:size=1080x720:rate=30 -vf > drawtext="fontfile=/path/to/font.ttf: \ > text='Stream A': fontcolor=white: fontsize=24: box=1: boxcolor=black@0.5: \ > boxborderw=5: x=(w-text_w)/2: y=(h-text_h)/2" -pix_fmt yuv420p stream_a.yuv > -y > > gst-launch-1.0 filesrc location=stream_a.yuv ! rawvideoparse width=1080 > height=720 framerate=1/1 ! xvimagesink > > And the latter one displays the correct image. I guess the quickest solution > for me is to use another resolution. > If you can change resolution to have dimensions which are multiple of 8 I guess that would be the most robust and backward compatible solution, yes For the current resolution, manually adjusting strides and offsets as Nicolas suggested also works: gst-launch-1.0 -v filesrc location=testfile ! rawvideoparse format=i420 width=972 height=720 framerate=1/1 plane-strides="<972,486,486>" plane-offsets="<0,699840,874800>" ! identity silent=0 ! videoconvert ! xvimagesink The identity is just to have some debug output, and videoconvert is added for generality. > One last question: do I need to create a bug report for this? And if yes, > where? > The issue is in gst-plugins-base/gst-libs/gst/video/video-info.c so if you want to open a discussion you can file a report on https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues after checking for similar reports. 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? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |