<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 13/06/18 11:57, Peter Bennett wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3648af01-f016-2b62-4ca4-326d26becb70@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
I have mediacodec decoding working after a fashion but with lots
of problems.<br>
<br>
1. Playback is jumpy especially with 1080p mpeg2 (Plays a few
seconds in slow motion, then jumps forward a few seconds.
Repeat...)<br>
2. Playback has pixellation and video corruption, especially bad
with 4K video.<br>
3. MythTV prematurely thinks it reached EOF after a skip forward.<br>
4. MythTV thinks my monitor is 1920x1080 when it is 3840x2160. The
Monitor display, android settings and Kodi all agree that
resolution is 3840x2160.<br>
</blockquote>
Im pretty sure mythtv restricts video size currently to 1920x1080
max. This should be an easy fix.<br>
<blockquote type="cite"
cite="mid:3648af01-f016-2b62-4ca4-326d26becb70@gmail.com"> </blockquote>
<blockquote type="cite"
cite="mid:3648af01-f016-2b62-4ca4-326d26becb70@gmail.com"> <br>
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 <i>packet</i> 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.<br>
</blockquote>
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.<br>
It may also be that its choosing between PTS and DTS incorrectly for
display purposes, or DTS is not provided and is synthesized
incorrectly.<br>
<blockquote type="cite"
cite="mid:3648af01-f016-2b62-4ca4-326d26becb70@gmail.com"> <br>
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.<br>
</blockquote>
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.<br>
<br>
All the above is a guess though.<br>
<br>
Well done so far anyway.<br>
<br>
Mark<br>
<br>
<br>
</body>
</html>