[mythtv-users] 0.24 mythpreviewgen issues - first frame always

[Kevin Blackham]

> What container are you using?  If you're putting H.264 in Matroska,
> having a seek table will actually cause problems.  If you do that, you
> need to clear the seek table.

It's an mp4 container:

#(a different sample)
$ mp4info 3072_20100405080000.mp4
mp4info version 1.6
3072_20100405080000.mp4:
Track   Type    Info
1       video   H264 High at 3, 3595.805 secs, 1059 kbps, 704x480 @ 29.800281 fps
2       audio   MPEG-4 AAC LC, 3595.050 secs, 128 kbps, 48000 Hz
 Tool: HandBrake svn3857 2011032101

[15:57:19]    + /space/mythtv/tmp/3071_20100401020000.mp4
[15:57:19]    + container: MPEG-4 (.mp4 and .m4v)
[15:57:19]      + 64-bit formatting
[15:57:19]      + optimized for progressive web downloads
...
[15:57:19]    + encoder: x264
[15:57:19]      + options: cabac=1:me=umh:8x8dct=1
[15:57:19]      + quality: 22.00 (RF)
[15:57:19]  * audio track 0
[15:57:19]    + decoder: English (AC3) (5.1 ch) (track 1, id 34)
[15:57:19]      + bitrate: 384 kbps, samplerate: 48000 Hz
[15:57:19]    + mixdown: Dolby Pro Logic II
[15:57:19]    + encoder: faac
[15:57:19]      + bitrate: 128 kbps, samplerate: 48000 Hz

> Also, seek table building for H.264 is still very fragile--and would
> likely only work properly with H.264 that's been encoded using the exact
> same options as seen-in-the-wild broadcast H.264.

Not exactly sure what handbrake is passing through to libavformat,
what exact RTP hinting or metadata interleave it's choosing.  The
intent of this is as you mentioned, to render on low-resource ARM
device with h264 silicon assist, while retaining all the features of
frontend/web - delete, etc.  The container does a good job on the
apple devices, seeking and all, no audio drift.  Mencoder + MP4Box
re-mux made a mess of audio sync.

Do you have any advice on what "seen-in-the-wild broadcast" h264
encoding parameters look like?