MP1.2.1: Cannot start graph (2 Viewers)

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,228
    Home Country
    New Zealand New Zealand
    Hi Tony

    To be honest I don't know! :p
    I was "randomly" fiddling with DeMultiplexer.cpp as well to try and find out why the TPG and AON samples refused to play smoothly (aside: what was the trick in the end?), so it could have been some of that I guess. The problem seems to be that TsReader is picking the wrong video PID. The PMT says there are two, but in practice I think there is only one. This could reflect an upstream problem in TsWriter.

    If you change line 1354 in DeMultiplexer.cpp to "if (header.Pid!=m_pids.videoPids[1].Pid) {" then it will play...

    Aside: I thought Seb had added support for selecting between video streams in MP? Obviously that doesn't seem to have made its way into TsReader. Would be good if it could so that we could support ISDB streams which have a "mobile" low quality stream and a full quality stream...

    mm
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,228
    Home Country
    New Zealand New Zealand
    Hmmm, problem seems to be that the stream with PID 0x30 (with stream type 0x80) is incorrectly detected as video.

    PmtParser.cpp:
    Code:
          if (stream_type==SERVICE_TYPE_DCII_OR_LPCM && !lpcm_audio_found)
          {
            VideoPid pid;
            pid.Pid=elementary_PID;
            pid.VideoServiceType=SERVICE_TYPE_VIDEO_MPEG2;
            m_pidInfo.videoPids.push_back(pid);
          }

    Obviously this is not a DC II stream, but in that context I don't know if we are able to distinguish properly. Anybody know anything about distinguishing between DC II and DVB MPEG transport streams? :D

    I can think of two possible "solutions":
    1. Only allow one video PID to be recognised at the PMT parsing stage. Since the rest of the TsReader doesn't seem to support multiple video streams, this would likely be appropriate... although there is still the problem of selecting the correct PID.
    2. TsReader is likely to be encountering DC II streams on a considerably (and increasingly) rarer basis than it would DVB streams... and DC II streams are also unlikely to have 2 video streams. We could prioritise the stream that we *know* is video over the stream that is possibly DC II video by doing the following:

    Code:
          if(stream_type==SERVICE_TYPE_VIDEO_MPEG1
            || stream_type==SERVICE_TYPE_VIDEO_MPEG2
            || stream_type==SERVICE_TYPE_VIDEO_MPEG4
            || stream_type==SERVICE_TYPE_VIDEO_H264 )
          {
            VideoPid pid;
            pid.Pid=elementary_PID;
            pid.VideoServiceType=stream_type;
            [B]m_pidInfo.videoPids.insert(m_pidInfo.videoPids.begin(), pid);[/B]
          }

    Not a particularly "nice" solution, but it works! ;)
    And in fact, now that I think about it this is exactly the modification that I had in my TsReader to deal with the problem from -->this<-- thread (similar issue). :D

    Tony: the internal discussion about that thread that Rik refers to is -->here<--. Interestingly, the sample provided now plays with audio and video (when the above tweak is applied). I think that is a testament to some great work that you've done in TsReader. You're a star mate! (y)
    I've now only got one other TS sample to hand that doesn't play correctly in MP...

    mm
     
    Last edited:

    Sebastiii

    Development Group
  • Team MediaPortal
  • November 12, 2007
    16,583
    10,403
    France
    Home Country
    France France
    Hi,

    About multiple video stream, we use pdwgroup to detect it.
    But the source splitter must parse it correctly (for sure it works with lav and haali).
    I didn't test above sample to see if with lav splitter all is handled correctly.

    So for now it seems that mm solution is nice :)
    Seb.
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    New TsReader.ax binary attached, with (hopefully) improved patch so that all of the 'real' video stream pids are collected and none of the incorrect 'DC II' pids (from streams with both). That way the mod should be compatible with multi-video streams (when/if we implement video stream selection in TsReader.ax).

    Needs testing with a real DC II stream as well (I don't have any) to check that it still works.....

    Modified 'PmtParser.cpp' attached for reference/comments.

    Tony
     

    Attachments

    • TsReader_noStopMod59e.zip
      166.7 KB
    • PmtParser_v59e.zip
      3.4 KB

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,228
    Home Country
    New Zealand New Zealand
    Hiya Tony

    Looks great to me. I'd be happy for that fix to go into 1.3b even without testing. Reasons being:
    1. Code looks okay. Isolated changes; not too much can go wrong.
    2. I think you're *very* unlikely to find a tester. TV Server's transponder files don't include DC II transponders, so it would have to be a very clued up person from North America with a very specific type of tuner (of which Genpix tuners are the most well known) and access to specific satellites to get DC II streams working in MP. Might be like finding a needle in a haystack. ;)

    I guess if we are doing due diligence we should also think about fixing the detection upstream in TsWriter too. I note the comment in PmtParser.cpp:
    //FIXME: this older code version is only for backward compatibility with dependent classes.
    // proper fix is to change code of all classes that depend on PidInfo2 in favour of CPidTable!
    So ideally the PMT parsing code from TsReader should get into TsWriter rather than fixing DiskRecorder.cpp and PatParser.cpp. I think that is out of scope for MP 1.3b - too risky. Do you think we should still attempt a fix? Technically this could cause radio services to be detected as TV services...

    mm
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    I think we should leave TsWriter alone for now (although you are probably a better judge of this than me - I've not looked inside it very much).

    (and re the AON/TPG problems - I think it was mostly fixing a bug in the NALU start code handling, but there have been some SPS/PPS parser mods as well).

    Tony
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,228
    Home Country
    New Zealand New Zealand
    I think we should leave TsWriter alone for now (although you are probably a better judge of this than me - I've not looked inside it very much).
    Yes, I concur.

    (and re the AON/TPG problems - I think it was mostly fixing a bug in the NALU start code handling, but there have been some SPS/PPS parser mods as well).
    A question that I've always wondered about: I could be wrong but I think the TPG streams are variable frame rate. Do you know if TsReader and the renderer code is able to cope with VFR properly?
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    A question that I've always wondered about: I could be wrong but I think the TPG streams are variable frame rate. Do you know if TsReader and the renderer code is able to cope with VFR properly?

    Basically, TsReader doesn't really care much about frame rate, and dshowhelper will do the best it can. Some video decoders seem to do timestamp smoothing (e.g. Cyberlink) so they get confused for a while if the frame rate changes on-the-fly, but LAV is OK.

    Tony
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,578
    8,228
    Home Country
    New Zealand New Zealand
    Tony, I see that you committed that fix to your branch - thanks.
    Just trying to get an idea of what everyone is working on and what people might expect to want to put into the beta and MP 1.4...
    Do you have a strategy for the TsReader going forward - particular fixes or features that you want to add?
    Looking at the commit log for your branch suggests that this is the only change/fix since 59c was merged to master?
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    I was planning to wait until after 1.3.0 is released before thinking about 'what next' (other than bug fixes).

    Is the issue in this thread in Mantis ?

    If not, I'll Mantis it so I've got an issue number for the Git bug branch.

    I've now only got one other TS sample to hand that doesn't play correctly in MP...

    Can I download the sample from somewhere ?

    Tony
     

    Users who are viewing this thread


    Write your reply...
    Top Bottom