Hello.

I am trying to encode an mpeg2 http stream (captured from DVB-T) into h264 to reduce required bandwidth. When using software x264enc, everything works as expected. Once I switch to vaapiencode_h264, SAR information is lost and the picture gets deformed.

This is the very basic gstreamer pipeline I am using with VA-API:
gst-launch-1.0 -v souphttpsrc location=http://10.0.180.147:3000/T-8395-273-260 \
! tsdemux \
! queue \
! mpegvideoparse \
! mpeg2dec \
! videoconvert \
! avdeinterlace \
! vaapiencode_h264 \
! vaapiparse_h264 config-interval=1 \
! mpegtsmux \
! tcpserversink host=10.0.0.26 port=5000

VLC (that I am using to capture the output) debug shows this:
main debug: original format sz 720x576, of (0,0), vsz 720x576, 4cc I420, sar 1:1, msk r0x0 g0x0 b0x


When I use exactly the same pipeline but the 264 encoder (I even keep the vaapiparse_h264):
gst-launch-1.0 -v souphttpsrc location=http://10.0.180.147:3000/T-8395-273-260 \
! tsdemux \
! queue \
! mpegvideoparse \
! mpeg2dec \
! videoconvert \
! avdeinterlace \
! x264enc \
! vaapiparse_h264 config-interval=1 \
! mpegtsmux \
! tcpserversink host=10.0.0.26 port=5001

VLC debug shows this:
main debug: original format sz 720x576, of (0,0), vsz 720x576, 4cc I420, sar 64:45, msk r0x0 g0x0 b0x0


The latter is correct, DVB-T is actually broadcasted as 720x576 stretched to 64:45. vaapiencode_h264 does not seem to retain this information.

This behavior is the same for gstreamer1-vaapi package from debian/jessie repositories, gstreamer-vaapi-0.5.9.tar.bz2 compiled from sources and also the latest git master branch of vaapi / gstreamer-vaapi.