Choosing pyffmpeg.PixelFormats.YUV420P causes crash

[Daniel]

Whenever you pass pyffmpeg.PixelFormats.YUV420P as the preferred
format in

TS_VIDEO = { 'video1':(0, -1,
{'pixel_format':pyffmpeg.PixelFormats.YUV420P}), 'audio1':(1,-1,{})}
mp = pyffmpeg.FFMpegReader(0,False)
mp.open(<the_file>,TS_VIDEO)

and then call mp.run() or mp.step()

Python crashes completely. Has anyone else encountered this problem?
When I choose RGB32 als format it works as it should, but I hope to
use the hardware accelerated overlay for video presentation, and then
data in YUV is required.

[Daniel]

Maybe I can formulate my question that brought me to this matter more
generally. Is it possible to get the frame output, as it is given to
the callback method of VideoTrack, in YUV planar data? The reason I'm
asking is that I hope to pass this data to pygame.Overlay.display()
which takes a tuple of 3 containing the list of y u and v values.
(http://www.pygame.org/docs/ref/overlay.html). When the frame can be
passed to this overlay function in this fashion, it can be drawn to
the pygame surface with hardware acceleration. Thanks for any help!

[Bertrand Nouvel]

Dear Daniel,

First of all be sure to have the pyffmpeg 2.1. Since some pixel-formats ids where invalid in the previous release.

Also regarding YUV420p as the size of Y plane and the of UV planes are different, if we want to separate the planes
they must be returned as a list of arrays in python, also this requires some specific code that has not be written right now.
Another option is to give a one dimensional array that contains the data of the image buffer but not formated
(i.e. as one dimensional array), it less convenient if you need to do some processing,
but in your case it would be the fastest, and it would provide a convenient way for all the formats with plane of different
size. This should be quite easy to patch the source that for, and I believed I used to have this already working in a previous release.
I'll try to give it a look soon. Feel free to have a look at the instantiation of the videobuffers in the initialization of the videotrack,
and at the decoding procedure of the videoframes if you want it more rapidly.


Best regards,

Bertrand

2011/3/13 Daniel <dsch...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "pyffmpeg" group.
To post to this group, send email to pyff...@googlegroups.com.
To unsubscribe from this group, send email to pyffmpeg+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyffmpeg?hl=en.

[Daniel]

Hi Bertrand,

Thanks for your reply! I have version 2.1 Beta running here from Jan
12th. I couldn't find a newer one than this, but if there is one,
could you tell me where I can get it? I checked the value of the
YUV420P constant in the pixel format class and it is 0. It might be
the problem that this corresponds to False in some statement somewhere
later in the program, causing the crash when you choose it?
I think your suggestion of return the Y and UV planes as a list of
arrays is the one that works with the Overlay.display() function of
pygame. The non-formatted image buffer could also work, as I could
transform it to the specified (y,u,v) tuple that the display()
function requires, but then you'd still have to figure out how to
construct these separate y, u and v arrays, if they have different
lengths. I will try to look into it when I can. You've done a great
job with this project!

Best regards,

Daniel

On 13 mrt, 04:21, Bertrand Nouvel <bertrand.nou...@gmail.com> wrote:
> Dear Daniel,
>
> First of all be sure to have the pyffmpeg 2.1. Since some pixel-formats ids
> where invalid in the previous release.
>
> Also regarding YUV420p as the size of Y plane and the of UV planes are
> different, if we want to separate the planes
> they must be returned as a list of arrays in python, also this requires some
> specific code that has not be written right now.
> Another option is to give a one dimensional array that contains the data of
> the image buffer but not formated
> (i.e. as one dimensional array), it less convenient if you need to do some
> processing,
> but in your case it would be the fastest, and it would provide a convenient
> way for all the formats with plane of different
> size. This should be quite easy to patch the source that for, and I believed
> I used to have this already working in a previous release.
> I'll try to give it a look soon. Feel free to have a look at the
> instantiation of the videobuffers in the initialization of the videotrack,
> and at the decoding procedure of the videoframes if you want it more
> rapidly.
>
> Best regards,
>
> Bertrand
>

> 2011/3/13 Daniel <dschr...@gmail.com>

[Daniel]

Checked it thoroughly now with settings as:

TS_VIDEO_RGB24={ 'video1':(0, -1,
{'pixel_format':pyffmpeg.PixelFormats.YUV420P,'videoframebanksz':1}),
'audio1':(1,-1,{})}

python crashes completely. Any other value than
pyffmpeg.PixelFormats.YUV420P works fine, so I think it's something
internal in pyffmpeg or ffmpeg?