<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> Also, seek table building for H.264 is still very fragile--and would<br>
> likely only work properly with H.264 that's been encoded using the exact<br>
> same options as seen-in-the-wild broadcast H.264.<br>
<br>
</div>Not exactly sure what handbrake is passing through to libavformat,<br>
what exact RTP hinting or metadata interleave it's choosing. The<br>
intent of this is as you mentioned, to render on low-resource ARM<br>
device with h264 silicon assist, while retaining all the features of<br>
frontend/web - delete, etc. The container does a good job on the<br>
apple devices, seeking and all, no audio drift. Mencoder + MP4Box<br>
re-mux made a mess of audio sync.<br>
<br>
Do you have any advice on what "seen-in-the-wild broadcast" h264<br>
encoding parameters look like?<br>
<div><div></div><div class="h5">_______________________________________________<br>
<br>
</div></div></blockquote></div><br>I am also doing something similar here, using handbrake to create smaller files to play on a non VDPAU computer over a slower network (not main frontend). For HD content the machine fails, so for these I have a user job to convert to a MKV/H.264 file which works well on the old device. However, I too get the error about missing seek table and the first frame is displayed of the file.<br>
<br>I'd like to keep in the Watch Recordings view as these files are ones that haven't been watched (and easier to navigate to than MythVideo). I did just accept this issue as it's not a major issue and I'm doing things slightly differently from how we are suppose to use "Watch Recordings", but if there is a workaround/suggested parameters I'd be interested to know. <br>