<div dir="ltr"><div dir="ltr">On Mon, 17 Feb 2020 at 22:30, Mark Kendall <<a href="mailto:mark.kendall@gmail.com">mark.kendall@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div><div>I *think* the root problem is something like;</div><div> - the above profile is chosen</div><div> - your SD channels then do not meet the criteria for this profile and it is filtered out</div><div> - there is no other profile - and everything defaults to 'off' (i.e. no hardware accel, no deint etc)</div></div></div></blockquote><div><br></div><div>OK  I've reproduced that profile and it does indeed drop back to no deinterlacing. There are a couple of issues here:-</div><div><br></div><div>- when I updated the database video profiles (as part of the render merge), I missed the vdpau and openglvaapi render options when using ffmpeg decoding - which is why your (I'm assuming) fallback profile of software decode is rejected. Not quite sure how to deal with that at this stage - slightly reluctant to push another database update  though I could just handle it in the code for now. Profiles using software decode and vdpau/vaapi rendering should have been switched to software decode and opengl rendering (the deinterlacers should  have been updated correctly).</div><div><br></div><div>- we really should have a suitable 'default' profile when everything else is rejected. It will default to ffmpeg decoding and opengl output but it would be better if it also defaulted to the number of CPUs present for decoding and some basic software deinterlacing.</div><div><br></div><div>- I pretty much forgot about the previous option of using software decoding but vdpau/vaapi for rendering. Is this something that people need? The only benefit now would be to make the most of VDPAU/VAAPI/NVDEC etc deinterlacers. I'm just not sure how useful it is for the extra code it would require. Most VDPAU, VAAPI and NVDEC hardware will decode anything that is interlaced. VideoToolbox has no deinterlacing support (at least not via FFmpeg), drmprime, mmal and v4l2 are similar - and mediacodec is a law unto itself.</div><div><br></div><div>With respect to your current issue, I will put something in place to fix the vdpau rendering case. Otherwise you could just remove the resolution check for using VDPAU decoding or add a new profile entry that explicitly sets the fallback to software decoding and the deinterlacing options you want.</div><div><br></div><div>Regards</div><div>Mark<br></div></div></div>