[mythtv] Difficulties with FFmpeg and mediacodec

[Mark Spieth]

On 13/06/18 11:57, Peter Bennett wrote:
> I have mediacodec decoding working after a fashion but with lots of 
> problems.
>
> 1. Playback is jumpy especially with 1080p mpeg2 (Plays a few seconds 
> in slow motion, then jumps forward a few seconds. Repeat...)
> 2. Playback has pixellation and video corruption, especially bad with 
> 4K video.
> 3. MythTV prematurely thinks it reached EOF after a skip forward.
> 4. MythTV thinks my monitor is 1920x1080 when it is 3840x2160. The 
> Monitor display, android settings and Kodi all agree that resolution 
> is 3840x2160.
Im pretty sure mythtv restricts video size currently to 1920x1080 max. 
This should be an easy fix.
>
> A major issue was the fact that the encoder now releases multiple 
> frames before it will accept a packet. The code until now was based on 
> the false assumption that after sending one packet you would get back 
> no frame or one frame. With mediacodec I have seen up to 15 frames 
> come back after a single packet release. This messes up the whole 
> timing calculation, which works out the frame timings based on the 
> /packet/ PTS and DTS values, so now 15 frames get the same time. There 
> is some incomprehensible logic in MythTV to "correct bad timing 
> values". I may have to rewrite the timing code because the simple 
> changes I have made to try to fix this did not help and the existing 
> logic is convoluted.
I think this is also the case with VP9 and certain other high 
compression standards (some boradcast H265 modes - SBS HD (one of our 
channel) has this problem) with lots of B frames. B frames can generate 
multiple frames since they have past and future reference needs. e.g. I 
think PBBBBBBBP wont generate the B packet frames until it sees the next 
P. I have had to reencode with ffmpeg to standard H264/H265 to fix this 
in standard myth playback.
It may also be that its choosing between PTS and DTS incorrectly for 
display purposes, or DTS is not provided and is synthesized incorrectly.
>
> The frames are being converted to the correct format and size in 
> software with sws_scale. Due to item 4 on the list above, the 4K 
> frames are being scaled down to 1920x1080, but that should not cause  
> video corruption to the extent that I see it.
No this should not be a problem, but gl should be doing the resizing for 
us anyway. Bus bandwidth to RAM has an influence on the larger frame 
sizes too her I think.

All the above is a guess though.

Well done so far anyway.

Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180613/c3ba2257/attachment.html>