[mythtv-users] mythffmpeg stream analysis defeated, works with ffmpeg

[John Pilkington]

On 29/10/13 19:26, Karl Newman wrote:
> On Sun, Oct 27, 2013 at 2:32 AM, Jean-Yves Avenard <jyavenard at gmail.com
> <mailto:jyavenard at gmail.com>> wrote:
>
>     On 27 October 2013 19:54, John Pilkington <J.Pilk at tesco.net
>     <mailto:J.Pilk at tesco.net>> wrote:
>
>      > OK, thanks for that.  This looks as if it's a special situation,
>     although
>      > probably easy to reproduce, or encounter by chance.  I doubt that
>     it's worth
>      > making a full-time switch back to ffmpeg but the workaround could
>     be useful.
>
>     my plan for 0.28 is to update the FFmpeg original mpegts demuxer to
>     support the features (mostly subtitles) mythtv's own demuxer supports.
>
>     When that happen; there will be no need for using special switch
>
>
> Does that switch work with mythbackend as well? Could it make the
> commercial flagger work as well as it did in 0.24? I know ffmpeg has
> active development, but it seems that all they do is break stuff (APIs,
> command line arguments, formerly working features, etc.)
>
> Karl

Not responding to Karl's post, but for info:

I made another similar recording today, deliberately overrunning the 
end-of-service when the cbbc slot is taken over, AIUI, by either BBC 
THREE or BBC FOUR. This one also failed to play with the normal frontend 
but, as JYA suggested, it does play with the mythfrontend -O FFMPEGTS=1 
switch.

I don't know if this /is/ related to #11882.  The frontend becomes 
unresponsive  with repeated blocks of  'Player(n): Waited 100ms for 
decoder to pause', but it does eventually respond to Escape and puts up 
a 'Need to switch video renderer' box.

This is with an unpatched build from Richard Shaw's 'rpmfusion' SRPM of 
8 October.

Perhaps it's just spooky goings-on; the programme, I'm sorry to say, is 
Scooby-Doo :-)

John