[mythtv-users] Problem with 1080i h264 video - video appears to be twice as long as it should.
John P Poet
jppoet at gmail.com
Tue Jun 2 23:53:03 UTC 2009
On Tue, Jun 2, 2009 at 2:56 PM, Nick Rout<nick.rout at gmail.com> wrote:
> On Wed, Jun 3, 2009 at 5:29 AM, John P Poet <jppoet at gmail.com> wrote:
>> On Tue, Jun 2, 2009 at 10:02 AM, Manuel McLure<manuel at mclure.org> wrote:
>>> On Tue, Jun 2, 2009 at 12:06 AM, belcampo <belcampo at zonnet.nl> wrote:
>>>> Manuel McLure wrote:
>>>>> My TV provider (which uses IPTV) recently switched from MPEG2 to h264
>>>>> streams, and since then I'm seeing a problem with new recordings. When
>>>>> they're playing, Mythtv shows the length as being twice what it really
>>>>> is - i.e. a recording from 5:00 to 6:00 shows as 1:59 in length. Also,
>>>>> fast forwarding and rewinding as well as commercial skip don't work
>>>>> correctly - sometimes a "skip forward" command will actually skip back
>>>>> in the show.
>>>> That's because it's interlaced material and ffmpeg libs until recently
>>>> wasn't able to distinguish between field and frames. So that's why it
>>>> doubles and seeking is a problem.
>>> I'm building against ffmpeg 0.5 - what version do I need for this to
>>> work correctly? Also, interlaced 1080i MPEG2 streams work fine - is
>>> the ffmpeg limitation only applicable to h264 streams?
>> Recording with Myth, right? The problem as actually with Myth's basic
>> parsing of the H.264 stream during recording. This has been fixed in
>> trunk, but is unlikely to be backported to the fixes branch.
> May I ask why not? Surely this is truly a 'fix' ?
I could probably download -fixes and generate a patch against it, but
I have no convenient way of testing it. If there are enough people
that need this, I am willing to generate the patch, but someone else
would have to test it.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
More information about the mythtv-users