Sreerenj Balachandran 6eba201f32 vaapidecode: Rework the re-negotiation code to handle multi resoultion videos ... Delaying the pool re-negotiation untill we push all decoded (and queued) frames downstream. Otherwise for the multi-resolution videos, the GstVideoVideoMemory will be having wrong resolution and which leads to nasty behaviours, especially when using software renderers. sample media file: RAP_B_Bossen_1.bin case explained: The first SPS Nal will report resoultion of 448x256 and having crop rectangles to get the final resoultion 416x240. Starting from 25 th frame, the resolution will change to 416x240. But parser elements won't report this since the effective croped resolution is same in both cases. Here the core libgstvaapi will detect this through it's internal parsing and do all context/pool destory/reset stuffs. Also it will notify this change to plugins in advance. But if the plugin try to do re-negotiaion of pool immediately, this will not sync with the resolution of already decoded and queued frames and which will lead to failure in gst_video_frame_map() in downstream(if we use the software renderer). So we have to delay the pool renegotiation in vaapidecode, untill we push all decoded frames downstream. https://bugzilla.gnome.org/show_bug.cgi?id=753914		2015-08-29 00:18:57 +03:00
..
vaapi	vaapidecode: Rework the re-negotiation code to handle multi resoultion videos	2015-08-29 00:18:57 +03:00
Makefile.am	build: use git.mk	2015-05-18 16:14:46 +02:00