[Rejected] Skip to end on live recording sometimes stops playback (1 Viewer)

Seidelin

Retired Team Member
  • Premium Supporter
  • August 14, 2006
    1,754
    652
    Farum
    Home Country
    Denmark Denmark
    Another look on the logs gives these clues:
    The last audio sample is only 0.3 s after the first video frame. I guess this means that we only have 0.3 seconds to find an I-frame, meaning that we are actually too close to the end.

    Is there a possibility to notice this "closeness" and issue a new seek to e.g. 2 seconds before last seek?
    Sorry if I am talking nonsense.

    03-02-2010 19:16:12.493 [1614]CTsReaderFilter:: Seek-> 227.199997/230.199997
    03-02-2010 19:16:12.493 [1614]seek to 227.199997 filepos:16f45d90 pid:30
    03-02-2010 19:16:12.496 [1614] stop seek: 227.209122 at 16f090d1 - target: 227.199997, diff: 0.009125
    03-02-2010 19:16:12.497 [1278]aud:OnThreadStartPlay(227.200000) 1.00
    03-02-2010 19:16:12.547 [1278] H.264 I-FRAME found 229.489000
    03-02-2010 19:16:12.600 [1cac]vid:OnThreadStartPlay(227.200000) 1.00 0
    03-02-2010 19:16:12.602 [1278]Audio Samples : 14, First : 227.407, Last : 229.783
    03-02-2010 19:16:12.603 [1278]Video Samples : 73, First : 229.489, Last : 230.989 GOP start : 229.489
    03-02-2010 19:16:12.605 [1614]CTsReaderFilter::--SeekStart()-- No new seek 227.199997 ( Abs 227.199997 / 230.200317 ) - Stream compensated: 0, OnZap: 0, Force 0, Media changing: 0
    03-02-2010 19:16:12.605 [1278]Compensation : ( Rnd : 0 mS ) Audio pts ahead Video Pts ( Recover skipping Audio ) ....
    03-02-2010 19:16:12.606 [1614]CTsReaderFilter::--SeekStart()-- No new seek 227.199997 ( Abs 227.199997 / 230.200317 ) - Stream compensated: 0, OnZap: 0, Force 0, Media changing: 0
    03-02-2010 19:16:12.607 [1278]aud:Compensation:2.289, Clock on start 0.000 m_rtStart:227200
    03-02-2010 19:16:12.609 [1278]aud:pDVBSubtitleFilter->SetTimeCompensation
    03-02-2010 19:16:12.609 [1614]CTsReaderFilter::Run(1209.80) state 1 seeking 0
    03-02-2010 19:16:12.609 [1614]CTsReaderFilter::Run(1209.80) state 2 -->done
    03-02-2010 19:16:12.615 [1278]aud:set discontinuity
    03-02-2010 19:16:12.615 [1278]Aud/Ref : 229.615, Late Compensated = 0.126 ( 0.126 A/V buffers=02/73), Clk : 0.000000, State 2
    03-02-2010 19:16:12.621 [1278]Aud/Ref : 229.783, Late Compensated = 0.294 ( 0.278 A/V buffers=01/73), Clk : 0.016000, State 2
    03-02-2010 19:16:12.627 [1cac]vid:set discontinuity
    03-02-2010 19:16:12.627 [1cac]Vid/Ref : 229.489, Late I-frame(00), Compensated = 0.000 ( -0.016 A/V buffers=00/81), Clk : 0.016000, State 2
    03-02-2010 19:16:12.632 [1cac]Vid/Ref : 229.509, Late ?-frame(00), Compensated = 0.020 ( -0.012 A/V buffers=00/82), Clk : 0.032000, State 2
    03-02-2010 19:16:12.633 [1cac]Vid/Ref : 229.649, Late ?-frame(00), Compensated = 0.160 ( 0.128 A/V buffers=00/82), Clk : 0.032000, State 2
    03-02-2010 19:16:12.634 [1cac]Vid/Ref : 229.669, Late ?-frame(00), Compensated = 0.180 ( 0.148 A/V buffers=01/82), Clk : 0.032000, State 2
    03-02-2010 19:16:12.635 [1cac]Vid/Ref : 229.569, Late ?-frame(00), Compensated = 0.080 ( 0.063 A/V buffers=00/81), Clk : 0.016998, State 2
    03-02-2010 19:16:12.636 [1cac]Vid/Ref : 229.589, Late ?-frame(00), Compensated = 0.100 ( 0.083 A/V buffers=00/80), Clk : 0.016998, State 2
    03-02-2010 19:16:12.637 [1cac]Vid/Ref : 229.529, Late ?-frame(00), Compensated = 0.040 ( 0.023 A/V buffers=00/79), Clk : 0.016998, State 2
    03-02-2010 19:16:12.638 [1cac]Vid/Ref : 229.549, Late ?-frame(00), Compensated = 0.060 ( 0.043 A/V buffers=00/78), Clk : 0.016998, State 2
    03-02-2010 19:16:12.639 [1278]Aud/Ref : 229.975, Late Compensated = 0.486 ( 0.469 A/V buffers=01/81), Clk : 0.016998, State 2
    03-02-2010 19:16:12.648 [1cac]Vid/Ref : 229.609, Late ?-frame(00), Compensated = 0.120 ( 0.088 A/V buffers=00/85), Clk : 0.031998, State 2
    03-02-2010 19:16:12.651 [1278]Aud/Ref : 230.167, Late Compensated = 0.678 ( 0.646 A/V buffers=01/85), Clk : 0.031998, State 2
    03-02-2010 19:16:12.680 [1cac]Vid/Ref : 229.629, Late ?-frame(00), Compensated = 0.140 ( 0.069 A/V buffers=00/84), Clk : 0.070987, State 2
    03-02-2010 19:16:12.697 [1cac]Vid/Ref : 229.809, Late ?-frame(00), Compensated = 0.320 ( 0.229 A/V buffers=00/92), Clk : 0.090982, State 2
    03-02-2010 19:16:12.699 [1278]Aud/Ref : 230.335, Late Compensated = 0.846 ( 0.755 A/V buffers=01/92), Clk : 0.090982, State 2
    03-02-2010 19:16:12.701 [1278]FileReader::Read() read to less bytes
    03-02-2010 19:16:12.708 [1cac]Vid/Ref : 229.829, Late ?-frame(00), Compensated = 0.340 ( 0.249 A/V buffers=00/94), Clk : 0.090982, State 2
    03-02-2010 19:16:12.710 [1cac]Vid/Ref : 229.729, Late ?-frame(00), Compensated = 0.240 ( 0.133 A/V buffers=00/93), Clk : 0.106982, State 2
    03-02-2010 19:16:12.712 [1278]FileReader::Read() read to less bytes
    03-02-2010 19:16:12.712 [1278]demux:endoffile
     

    riksmith

    Portal Pro
    April 18, 2009
    1,856
    322
    Home Country
    Netherlands Netherlands
    Another look on the logs gives these clues:
    The last audio sample is only 0.3 s after the first video frame. I guess this means that we only have 0.3 seconds to find an I-frame, meaning that we are actually too close to the end.

    Is there a possibility to notice this "closeness" and issue a new seek to e.g. 2 seconds before last seek?
    Sorry if I am talking nonsense.

    It is the other way around. We do not seek to 229 but to 227. The i-frame is too close to the edge. BTW: This is exactly what you found earlier.

    03-02-2010 19:16:12.493 [1614]CTsReaderFilter:: Seek-> 227.199997/230.199997
    03-02-2010 19:16:12.493 [1614]seek to 227.199997 filepos:16f45d90 pid:30
    03-02-2010 19:16:12.496 [1614] stop seek: 227.209122 at 16f090d1 - target: 227.199997, diff: 0.009125
    03-02-2010 19:16:12.497 [1278]aud:OnThreadStartPlay(227.200000) 1.00
    03-02-2010 19:16:12.547 [1278] H.264 I-FRAME found 229.489000
    03-02-2010 19:16:12.600 [1cac]vid:OnThreadStartPlay(227.200000) 1.00 0
    03-02-2010 19:16:12.602 [1278]Audio Samples : 14, First : 227.407, Last : 229.783
    03-02-2010 19:16:12.603 [1278]Video Samples : 73, First : 229.489, Last : 230.989 GOP start : 229.489

    My patch is not a solution to the problem but only a mere workaround.

    Perhaps the best thing to do would be: When seeking do not look for an i-frame AFTER the seek point, but first look if there is an i-frame BEFORE the seekpoint (and if not, seek to AFTER).

    I don't know if this is even possible (perhaps not because it sounds very complicated).
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    I don't know if this is even possible (perhaps not because it sounds very complicated).

    I would be possible, but pretty complex indeed since TsReader is currently seeking only based on the timestamps and then "ignoring" the samples that arrive before I-Frame.
     

    Users who are viewing this thread

    Top Bottom