The VideoLAN Forums

Now that I have imem + h264 + rtsp up and running its time to start fine tuning the results. I could use some help with the following:

1) What is the best way (if this is possible) to resize a stream? I tried shutting down the pipeline and then recreating it however if I do this in quick succession it appears to crash the libx264_plugin in the function vlc_entry_license__1_2_0j.

2) I'm capturing my scene using glReadPixels which gives me two problems, the first is that the image is upside down adn the second is the RGB ordering, GL gives me BGR and vlc wants RGB. I could do the conversion in software myself but am wondering if there is a some way to tell vlc to handle this which I suspect would be more efficient.

To flip the image I tried adding the arg: --transform-type=vflip, but this had no effect.

Thanks.

vlc_entry_license is not a function, it is data. So it cannot "crash". Your trace is evidently corrupt or lacking symbols.

And VLC, or rather the H.264 encoder, wants YUV, not RGB.

vlc_entry_license is not a function, it is data. So it cannot "crash". Your trace is evidently corrupt or lacking symbols.

Fair enough; do you have anything helpful to add about what to look for, if its possible or how to resize a stream? Also are there any restrictions on stream size, it seems 640x479 causes the h264 encoder to crash whereas 640x480 works fine. Maybe even numbers or multiples of 8 are required?

And VLC, or rather the H.264 encoder, wants YUV, not RGB.

Understood, however the imem module lets you set the input format of your buffer ie., "--imem-codec=RV24" and this part is working just fine. In fact I have the color space being pulled from OpenGL properly now ( I keep forgetting that I am not limited to OpenGL ES2 on the desktop; been knee deep in mobile development ). Anyway I'm also doing the invert myself now; working fine so I am mainly concerned with the resize issue. If you have anything useful to add I'd love to hear it.

multiple of 8, I would not be surprised.