mythcommflag gets mpeg2video errors not seen in playback

[anonymous]

mythcommflag gives a large number of

2007-09-02 20:02:50.353 AFD Error: Unknown decoding error [mpeg2video @ 0xb7431b68]current_picture not initalized

on firewire streams captured on a comcast cable box. The commerical marking on these streams are very unreliable. These particular streams are from extended basic sd digital channels (fx,usa, comedy central, ..) which are encrypted. However, the captured mpeg transport streams play perfectly well in myth. OTA streams captured in the same way don't have this problem.

My thought is that mythcommflag is not using the same codec as the myth native player. I can't really tell what mythcommglag is using. I can say that the mythfrontend uses

AFD: Opened codec 0x8da0310, id(MPEG2VIDEO) type(Video)

for these.

I can provide sample stream segments if requested.

[km@…]

My initial thought about wrong codec was wrong. The same mpeg2 decode is done in all cases.

The problem boils down to this. The errors don't show when playing the streams because they are played sequentially. mythcommflag seeks forward skipping frames incorrectly for these streams and then tries to decode garbage. Eventually it recovers but the indexing is off.

I need someone more expert than me to help look at a sample stream and help pin down the error. I have a 1MB stream that illustrates the problem. mythcommflag tries to skip from frame 30 to frame 58 and thats where the problem occurs. mpeg_decode_frame is called 5 times successfully, the 6th time follows a AvFormatDecoder::SeekReset? which attempts to skip 28 frames, and this one is given garbage.

1MB exceeds the largest file I can attach, so please contact me if you would like to have a look.

This is not an isolated problem.

[bschott@…]

This is not an isolated problem.

KM,

Agreed, this is not an isolated problem. It is pretty consistent with my setup Comcast 62xx box on Comcast on certain digital channels. What you have discovered also fits my impression that the offset error is cumulative. I'm checking out the source tree now. I haven't been a Myth developer in the past, but am motivated to poke around and see if there might be an easy patch. Will post further if I make any progress.

[Dibblah]

Is this still occurring in trunk?

[michael bishop <clever@…>]

i'm seeing very similar error spam from pvr-150 recordings on 19715M of trunk

im also guessing that its related to the logo detect method(but havent checked the code for that at all)

[beirdo]

Can you provide a small sample recording for this? I am pretty sure that this is mainly caused by bad seek tables. If the seek table doesn't point directly at key frames, then ffmpeg sometimes objects on starting playback, but will find the next valid frame. If that is all it is, then there's no real bad problem here.

This ticket has been open for so long with no real feedback. If There's no appreciable feedback by Apr 22, I will summarily close this, and it can get reported again if it is still an issue.

[beirdo]

No information provided. Closing this.