[mythtv-users] Jerky playback on BBC HD Chennels

[Paul Gardiner]

On 28/01/2013 03:04, HP-mini wrote:
> On Mon, 2013-01-28 at 09:15 +1300, HP-mini wrote:
>> On Sun, 2013-01-27 at 17:25 +0000, Fred Watt wrote:
>>> On 27/01/13 16:51, Tim Draper wrote:
>>>
>>>>
>>>>
>>>> On 25 January 2013 06:52, Fred Watt <fredwattmythtv at gmail.com>
>>>> wrote:
>>>>          On 24/01/13 21:03, Tim Draper wrote:
>>>>
>>>>          > Are there any plans to revert this in 0.26-fixes? i too am
>>>>          > suffering with BBC HD recordings since a recent update.
>>>>          Me too - awful.  Massive regression.
>>
>>>> I've just been looking at this to see if theres been any updates -
>>>> none yet.
>>>> for reference of the bug - http://code.mythtv.org/trac/ticket/11356
>>>>
>>>> re-reading through thread and the bug tracker info, it's down to
>>>> ffmpeg.... since i tend to update my entire system rather than just
>>>> mythtv, is this something mythtv can help out with, or are we
>>>> waiting on a fix from the ffmpeg devs to fix this annoyance??
>>>> atleast the 'work around' is to ammend the recording rules for BBC
>>>> One HD shows, and rely on BBC One (SD) for the recordings.
>>>> Interestingly people are reporting it on just one channel; BBC HD,
>>>> i'm having issues on BBC One HD and ITV HD aswell! (C4 HD doesn't
>>>> exhibit the issue)
>>>>
>>
>>> Yes we're stumped as well.... nearly all of our viewing is now BBC HD,
>>> and over the last two weeks we're unable to watching anything easily.
>>> What does seem to work is 'livetv', I watched the tennis today in HD
>>> and it started out stuttery but after 30 seconds was completely
>>> watchable.  The recordings on the other hand are frame jerky.  I
>>> wonder why that is?
>>>
>>> Correct me if I am wrong, but my understanding is that ffmpeg is
>>> statically linked.  So it does not matter which version is installed
>>> on our ubuntu boxes.  Like you, these days I use the repositories, so
>>> we need for a fixed version.
>>>
>>> Very frustrating.  I can watch using another player but it's all a
>>> faf... as I prefer using mythfrontend.
>>> _______________________________________________
>>
>> If livetv works then the seektable generation must be different between
>> recording & watching live. Or is it the recording start?
>>
>> Can you watch these recordings from "videos" ?
>> Seektables are optional for "videos", none of mine seek correctly
>> without generating them. But your recordings might play smooth(er)
>> without.
>>
>> FWIW MythTV does make a mess of the beginning of recordings..(There is a
>> ticket/patch/commit that improves this). This causes problems with
>> transcoding & cut frame accuracy.
>>
>> You could try:
>> - find (with ffprobe) first "coded picture number" byte offset & cut off
>> file beginning with "dd".
>> - rebuild seektable with mythtranscode or mythcommflag (or mythutils).
>> - write a script with "ffprobe" & generate the right seektable offsets.
>>
>> Can you easily upload (somewhere) a 1 minute recording ?
>> (could cut end off with "dd" but I do need the start untouched)
>>
>> For me, Ticket #11159 caused jerky/judder on recording discontinuities
>> (cut files) on SD channels.
>>
>> I find it is possible to induce this judder/jerky playback on any H264
>> recording by messing around in the cutlist editor at the start.
>>
>> Brett.
>
> Further to locked ticket 11159:
> There is a sample HDPVR recording file mentioned in the ffmpeg trac..
>
> If you cut 6023 packets (1132324 bytes) off the start of the sample
> hdpvr file JYA "11159 HD-PVR sample.mpg"..the file plays correctly in
> myth 0.26+fixes without requiring this revert patch.
>
> Like I said before..you can induce this playback effect, in any of my
> h264 files, by tooling around with cutlist editor in frame & keyframe
> index at start..

Oh hang on. I wonder if this is connected. I get jerky playback if I
jump back during live tv to the start of the program. It then wont
recover witout exiting and reentering.

In any case, it sounds like we just want the commit of 11159 reverted.

P.