2014-12-10, 17:24
You're correct noggin, been doing some channel hopping and the use of this adaptive encoder is in use across all Freeview HD channels and content type so the screen flashes are frequent.
When AndyFurniss first explained its use with the signer for the deaf, I thought its use would be restricted to changes of content type within a broadcast e.g showing archive footage/prerecorded vt/commercials but as you explain above and my test samples have shown, the encoder is adapting constantly to whatever its being fed so the i/p transitions are happening frequently even within the same type of content.
So that being said, now that its been show to be a standard in UK DVB-T2 broadcasts a question for the devs:
Is there scope to improve how vaapi hw decoding handles deinterlacing this type of adaptive content without the i/p transitions being visible on screen as the renderer adapts, or is it a limitation of decoding in hw? As I mentioned, decoding in sw handles the transitions without any screen flash.
If there is scope, should I submit a bug report on trac?
When AndyFurniss first explained its use with the signer for the deaf, I thought its use would be restricted to changes of content type within a broadcast e.g showing archive footage/prerecorded vt/commercials but as you explain above and my test samples have shown, the encoder is adapting constantly to whatever its being fed so the i/p transitions are happening frequently even within the same type of content.
So that being said, now that its been show to be a standard in UK DVB-T2 broadcasts a question for the devs:
Is there scope to improve how vaapi hw decoding handles deinterlacing this type of adaptive content without the i/p transitions being visible on screen as the renderer adapts, or is it a limitation of decoding in hw? As I mentioned, decoding in sw handles the transitions without any screen flash.
If there is scope, should I submit a bug report on trac?
