[mythtv] Difficulties with FFmpeg and mediacodec

Peter Bennett pb.mythtv at gmail.com
Wed Jun 13 14:46:38 UTC 2018



On 06/12/2018 11:03 PM, Mark Spieth wrote:
>
> 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.
I think it is more complicated.
- On Linux it handles the 3840x2160 mode perfectly. Log messages from -v 
playback show that MythTV is using 3840x2160.
- On android, MythTV thinks the resolution is 1920x1080 in the log 
messages, yet the picture fills the 3840x2160 screen.
- On android, if I use the setup appearance settings to change MythTV to 
1280x720, on my 3840x2160 screen it is taking up about two thirds the 
screen width, where at that size it should take up one third.
- I suspect the scale-factor or support-screens settings in the Android 
manifest are wrong, but I cannot find any documentation for them.
- In any case I have it on my list to go through MythTV and fix 
references to 1920 or 1080 to allow double that amount where appropriate.
>>
>> 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.
>>
After my fixes maybe you will not need to reencode.
>> 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.
>
I wish I knew more about OpenGL.
> 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/243b6dc0/attachment.html>


More information about the mythtv-dev mailing list