notes

== linux ==

appears to have no children windows ever...hrm...A
  possibly manually...line it up just right LOL [hulu linux]

== current over arching plan==

 this as a stop gap for "something/anything free" till 2020 ...

== warn clearplay/vidangel ==

left clearplay links to github on google plus, sent them a message to check it from facebook.
+vidangel left some google plus, same links

== how to not have to show users the timestamps too...==

no real way to do virtual desktop with vista+

maybe try the gime...see if it works LOL.

Maybe just *move* it down?

Resize?
  fauximize for them: expand the current window to be larger than the current screen, but not maximized...

trick maximize somehow?
  [move the maximized window down...]

black bar around all the annoying stuff? or with window...

screen capture it over to some "real" full screen...?
  [or broadcast it...LOL]
more?


== mac mplayer wrappers ==
  looks like mplayerx might still be my best (read: most often updated) bet...at least he updates his blog...LOL.
  umplayer no update since 2011, http://www.mplayerosx.ch returns a "dead" message...
  VLC maybe?

== Amazon prime ==

: with diego the on screen timestamp 'did conflict' by default, though it is possible to do the popup
  in such a way that it doesn't conflict.  full screen conflicts, too, I believe.  something else we watched there
  didn't conflict.

== comparing times again ==

S&SAC youtube rentable, no netflix instant
S&S amazon prime viewable, no netflix instant, hulu free
forever s.: netflix instant, amazon prime, plus I have the DVD TODO check DVD timings here...has blu-ray though gah! but I accept!

== forever strong seeking==

==amazon prime:
  the popup doesn't actually seem to overlay any video :)
        pail hits the desk
		  15:00
          right before it turns 15:00
		  14:59.5
  transition around 30:00 to guy who then after says "you did good"
    29:59
	29:59.5'ish
	29:59.75
  he sees cop, transition back to him:
    1:15:00
	1:14:59.5 * 3
	1:15:00 barely after it turned that, * 4
	  interspersed
	  weird
  "that philosophy has won them x" fade out 
    1:44:49
	1:44:49.5
	1:44:48.9
	1:44:48.5 * 2
	1:44:48.75
	
	=> hmm...
	
basically, you could keep notes "in this media, it's like this, in this media, like this" ... then map great back and forth [?]
  maybe I don't even care/worry about this yet, though, over engineering!!!gah!!!

== gnosygnu patch ==

snow white, jumping 10M past the end puts you at 7M in?

== length of DVD compared ==

basically, 2 different rips get 1s off.  Possibly legitimately. 

Each different type is going to want/need different double start metrics

Hopefully resynchronizing helps :)

Currently DVDNAV conversion...works ok for some DVD's, not ok for others, but might match some file times precisely.
  just not snow white LOL
  OSOH ok (had no breaks tho...)
    that's important, though...yeah.
  
= snow white =

compare times dvdnav:// rip1, rip2
== mplayer dvdout.mencoder.mpg


A:5312.3 V:5312.3 A-V: -0.012 ct:  0.048 371/371  6%  0%  1.0% 0 0
[ac3 @ 01395220]incomplete frame
A:5312.7 V:5313.2 A-V: -0.458 ct: -0.042 397/397  6%  3%  0.9% 0 0

mplayer real end (before guy):
A:5166.3 V:5166.2 == 1:26:6.2

== title0.mkv

V:5012.5 == 1:23:32.5, OSD 1:23:32,

== hbrk:
mplayer:
 V:5013.4 1:23:33

ffmpeg hbrk:  Duration: 01:23:34.03,

mplayer dvdout.mencoder.ffmpeg.copyies.mpg
V:5167.0 == 1:26:07 which matches dvdnav....

this is a huge discrepancy.. 150s?  we have 5s leeway...
  this feels broken...

time how long mplayer takes to play each...

also including the dvdnav itself...that's the real litmus test :P


took 5017.688s (ran \downloads\MPlayer-rtm-svn-34401\MPlayer-rtm-svn-34401\mplayer dvdout.mencoder.ffmpeg.copyies.t5167.mpg -vo direct3d)
from V:5167.0

took 5014.936s (ran \downloads\MPlayer-rtm-svn-34401\MPlayer-rtm-svn-34401\mplayer snow_white.hbrk.m4v -vo direct3d)
from A:5013.4

mplayer dvdnav://1 (with cache, without framedrop oops): wall time 5069.266876 ~= 

1:24:29.27


TODO time with vlc, mplayer dvdnav, powerdvd ...


TODO check when it seems to start gaining...is it just at breaks? what are the mpeg 

frames like at breaks? like it's using them for black sections...?


wedding bells will...

A: 131.4 V: 131.4 A-V: -0.006 ct: -0.273 194/194  5%  2% 37.5% 0 0
A: 132.4 V:   0.0 A-V:132.414 ct: -0.269   0/  0 ??% ??% ??,?% 0 0
A:  -0.6 V:   0.0 A-V: -0.678 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:  -0.5 V:   0.0 A-V: -0.558 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:  -0.4 V:   0.0 A-V: -0.438 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:  -0.3 V:   0.0 A-V: -0.298 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:   0.0 A-V: -0.168 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:   0.0 A-V:  0.012 ct: -0.269   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:   0.0 A-V:  0.132 ct: -0.265   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:   0.1 A-V:  0.160 ct: -0.260   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:   0.1 A-V:  0.159 ct: -0.256   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:   0.2 A-V:  0.147 ct: -0.252   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:   0.2 A-V:  0.125 ct: -0.248   5/  5 ??% ??% ??,?% 0 0
A:   0.4 V:   0.3 A-V:  0.103 ct: -0.244   6/  6 ??% ??% ??,?% 0 0
A:   0.4 V:   0.3 A-V:  0.082 ct: -0.240   7/  7 ??% ??% ??,?% 0 0
A:   0.4 V:   0.3 A-V:  0.068 ct: -0.235   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:   0.4 A-V:  0.108 ct: -0.231   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:   0.4 A-V:  0.097 ct: -0.227  10/ 10 ??% ??% ??,?% 0 0
A:   0.5 V:   0.5 A-V:  0.075 ct: -0.223  11/ 11 94% 44% 704.3% 0 0
A:   0.6 V:   0.5 A-V:  0.063 ct: -0.219  12/ 12 87% 41% 651.0% 0 0
A:   0.6 V: 132.0 A-V:-131.376 ct: -0.223  13/ 13 82% 38% 606.3% 0 0
A:   0.7 V: 132.0 A-V:-131.378 ct: -0.227  14/ 14 77% 36% 568.1% 0 0
A:   0.7 V: 132.1 A-V:-131.402 ct: -0.231  15/ 15 72% 34% 534.7% 0 0
A:   0.8 V: 132.1 A-V:-131.362 ct: -0.235  16/ 16 69% 32% 505.3% 0 0
A:   0.8 V: 132.2 A-V:-131.343 ct: -0.240  17/ 17 65% 31% 482.7% 0 0

My guess is it's preloading some audio "negative 0.6?" or maybe it's negative...umm...
and then...umm....
obviously mplayer doesn't handle this well...


vlc handles the breaks better, lists 1:23:28 as the sum?
  seems about accurate...



with VLC  dvd:///D:/#1 vlc://quit 8 seconds of bootstrap'ish?

ffmpeg -i mkv
  Chapter #0.26: start 4844.072567, end 5012.524000

1:23:28 "vlc dvd sum time" compared to "01:23:34.03" hbrk time, 5012.524000==1:23:32.4 

mkv

ffmpeg -i  dvdout.mencoder.ffmpeg.copyies.t5167.mpg
    Duration: 01:26:07.06, start: 1.000000, bitrate: 5692 kb/s

ffmpeg -i  dvdout.mencoder.ffmpeg.copyies.t5167.mencoder.forceidx.mpg
    Duration: 01:23:33.44, start: 0.000000, bitrate: 5385 kb/s

ffprobe on the baddy? :)


*30/29.97 is actually about equal...so...but...does it go in the "wrong" direction?

typically, it thinks it is 30 fps, but it is actually 29.97...

so typically dvd is ahead...but they are behind in this particular case?

I guess that is ok...so maybe "in this case, they just underestimated"

but if that's the case, then wall time should match mkv time...

  was 1:24:29.27

like a minute extra too long, but consistently?

possibly another fluke?
  possibly mplayer sucks at handling overlaps right, too...
  could tell by rerunning it, was already seeing it at OSD 52:35 ...
  so if it's not there by that point...

noooooooo
the output end time should be some fraction of 29.97/30 ...

assuming makemkv is actually on which...they...might probably be...


demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

with no other changes for quite awhile, assume progressive 24000/1001 fps...


so what I *want* is for wall time in (VLC, mplayer fixed, or powerdvd) to match something 

*sane* like the mkv time :)

coudl try out =c=, ratatouille



ID_DVD_VOLUME_ID=
ID_DVD_CURRENT_TITLE=1
ID_DVD_TITLE_1_LENGTH=5008.166 == 1:23:28.166 (same as other number at least...)
   scaled to 29.97 == 1:23:23.158 "which is the wrong way" apparently
   scaled to 30.03 == 1:23:33.179
                      01:23:32.52 mkv

ID_DVD_TITLE_1_CHAPTERS=28

VIDEO:  MPEG2  720x480  (aspect 2)  29.970 fps  5162.0 kbps (645.2 kbyte/s)
ID_FILENAME=dvdnav://1
ID_DEMUXER=mpegps
ID_VIDEO_FORMAT=0x10000002
ID_VIDEO_BITRATE=5162000
ID_VIDEO_WIDTH=720
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=8192
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_START_TIME=0.57         ??? NAV start? huh?
ID_LENGTH=5008.17
ID_SEEKABLE=1
ID_CHAPTERS=28


last NAV packet was 0.500000, mpeg at 0.364044 new NAV packet! 0.500000 at mpeg 0.364044 

adding 0.000000 to pts 0.500500
final: 0.500500
using mpeg ts appears larger, which if true is definitely better 0.364044 > 0.500500 - 

1.0
A:   0.4 a:   0.8 V:  0.36 A-V:  0.447 ct:  0.000   2/  2 ??% ??% ??,?% 1 0
last NAV packet was 0.500000, mpeg at 0.397411 adding MPEG difference since last NAV of 

0.033367 adding 0.000000 to pts 0.533900
final: 0.533900


does mplayer show "skips" when playing a raw mpeg rip?
  mplayer  dvdout.mencoder.mpg
    A:4245.2 V:4245.1
  so my guess is not...though...umm...uh...
@end:
A:5166.3 V:5166.2 A-V:  0.074 ct:  0.283 789/786  3%  0%  0.8% 0 0

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:5166.3 V:5166.2 A-V:  0.072 ct:  0.287 790/787  3%  0%  0.8% 0 0
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]

though the V: keeps going...hmm...

A:5313.2 V:5313.2

end ffprobe on dvdout.mencoder.mpg:
pts_time=5313.207700
pts_time=5313.341167
pts_time=5313.289367

no idea what ffmpeg is doing here/what is going on here...


end ov dvdnav://1

final: 5011.506348
A:5011.5 a:  13.2 V: 13.19 A-V:  0.013 ct: -0.264 180/180  4%  0% 31.7% 1 0
last NAV packet was 5006.500000, mpeg at 13.234327 adding MPEG difference since last NAV 

of 0.041708 adding 0.000000 to pts 5011.547852
final: 5011.547852
A:5011.5 a:  13.2 V: 13.23 A-V:  0.001 ct: -0.264 181/181  4%  0% 31.6% 1 0
last NAV packet was 5006.500000, mpeg at 13.276035 adding MPEG difference since last NAV 

of 0.083416 adding 0.000000 to pts 5011.589844
final: 5011.589844
A:5011.6 a:  13.3 V: 13.28 A-V:  0.010 ct: -0.263 182/182  4%  0% 31.5% 1 0
last NAV packet was 5006.500000, mpeg at 13.317743 adding MPEG difference since last NAV 

of 0.125124 adding 0.000000 to pts 5011.631836
final: 5011.631836
A:5011.6 a:  13.3 V: 13.32 A-V:  0.008 ct: -0.263 183/183  4%  0% 31.3% 1 0
last NAV packet was 5006.500000, mpeg at 13.359455 adding MPEG difference since last NAV 

of 0.166836 adding 0.000000 to pts 5011.673828
final: 5011.673828

pdvd wall time: 5008.669215 == 1:23:28.7 + 1.5 ==  1:23:30'ish


SW dvd advertises as 1:23:28.166 5013.18 so could go up to 1:23:32.16 I believe, if we went that route

handbrake yields a file with length  01:23:34.03
makemkv: 01:23:32.52

dvd advertises as 1:23:28.166 5013.18 so up to 32

actual wall time appeared to be around 1:23:31'ish [?] so makemkv may actually be closest

raw mpeg might be around 01:23:33.44

so my guess is that PowerDVD seeking to 1h would be off in the direction I anticipate

and my conclusion is that rippers all have their own opinion of timings, makemkv might be "most accurate"

PowerDVD 12 seemed to show the same as well clock working "right" for the prince
  and then ended 2 seconds too early? that might be expected...
  I hope this just means PowerDVD is fixed LOL
  
  mplayer OSD nav show 1:23:26, then briefly 1:23:27
    V: 6.4 at the end I believe, so no longer MPEG at the end...oh man this is sooo weird.

  wall time latest: wrist watch started a tidge behind, ended up even further behind (powerdvd [5??])
    1:23:32 sum powerDVD (last OSD I guess?)
    *except* when you scan to the end, then it's 1:23:28 again
    my guess is powerDVD isn't keeping track except internally...
    seeking 1HR "good night" [good] night (her last one)
    yep it's totally internally inconsistent (I assume I'm referring to the OSD matching wall time oddly). Fascinating.
    apple dvd player too, IIRC
    
    with powerdvd 12:
      PDVD's last OSD 1:23:30 "reasonably strong" at least 0.5s showing 30, with an end of 1:23:28 advertised
        got this again with a full run through, exact same, wall time was 
      and if you seek to it, it gets to the "end second shown" 1:23:26 or 1:23:27 then "bumps" to 1:23:28
      yep, this may be still messed up!
        sniff...maybe...EDL's might still work, though...somehow...sniff...
      remember: pdvd wall time: 5008.669215 == 1:23:28.7 + 1.5 ==  1:23:30'ish (or + 2).  It seems like PDVD 12 is tracking wall time still...but...but...played it more quickly than an older version?
      with 60 second build up, last second shown was a reasonably strong 1:23:27

      wall time right on at second 4
        first black after blue == 5010.79
        prolly 5011.69 or (5012.0'ish == 1:23:32)
        powerdvd is reporting a half and half MPEG to wall time with this new version? huh?
         or maybe it just loses a second at the beginning or something...I'm thinking that the wall time is actually 1:23:32, at least that would simplify things on my brain a bit :)
           though possibly I didn't quite start the timings on?
        it "becomes" 1s behind wall time, and is 1:23:31? that's still like 1s off makemkv grumble grumble.
           the take home is "everybody has their own timings" I suppose...
     LODO try it with the old PDVD again? or it may have been a fluke with a few extra seconds thrown in there :P
       we'll assume we understand what was happening and leave this awful DVD behind LOL
  VLC walltime:
    around 5005.62 [?] which...might seemingly be timing-wise off for whatever reason though (VLC bug? timing issue?)
  mplayer wall time: 5005.5+..."a few seconds" (should be 5010?) ok this is hurting my brain, there might be some legitimate discrepancy between DVD and rips now LOL
    same lesson--don't trust one source to match another...though it might be interesting to see about netflix instant...
  mplayer the console time was started a few seconds late
       
= mplayer current OSD timing =

== osoh end stuff

mplayer m4v 6532.09 (1:48:52.09)

dvdoutfull.mpeg ends at V:6773.92 what?

mplayer dvdnav://1  V:6532.26 ish

mplayer mkv  V:6532.03

smplayer 1:48:52.05

== osoh first frame walking down

mplayer m4v V:3607.74 'ish transition

mplayer dvdoutfull.mpg V:3968.38 huh?

mplayer dvdnav://1  V:3607.72

1:00:07.43 smplayer spot on suh-weet

mplayer mkv  V:3607.44

== osoh first white frame ==

osd-fractions 2 is bad

1.10 mplayer.exe out.mkv (which equals a NAV time equivalent for start? huh?)
1.10 mplayer.exe .m4v

1.1 handbrake whoa!
1.38 mplayer.exe dvdnav://1/d:   (same with mainline mplayer)
1.38 with smplayer OSD -osd-add 0.214 (its just using mpeg + 0.214 to try and equal the 1.38, anyway)
1.38 with playing the output from mplayer -dumpstream dvdout.mpg

VO: [directx] 720x480 => 854x480 Planar YV12 
A:   0.3 a:   0.5 V:  0.28 A-V:  0.212 ct:  0.000   2/  2 ??% ??% ??,?% 1 0    

it's because the video first frame was at 0.28 ... oh wow the plot thickens...

so to convert from DVD to normal time:
  current_dvd_timestamp+offset_mpeg_to_dvd-dvd_start_stamp
  or
  current_dvd_timestamp+(offset_mpeg_to_dvd-dvd_start_stamp)

NB that our current "match that original MPEG timestamp number!" is pretty close to spot on...
  [["0.000000", 0.0],
 ["0.033367", -3.299999999999831e-05],
 ["0.280633", -0.0002809999999999757],
 ["0.280633", -0.0002809999999999757],
 ["0.314000", -0.00031399999999998096],
 ["0.347367", -0.0003470000000000417],
 ["0.380733", -0.0003810000000000202],
 ["0.414100", -0.00041399999999996995],
 ["0.447467", -0.0004469999999999752],
 ["0.480833", -0.0004810000000000092],
 ["0.514200", -0.0005140000000000144],
 ["0.547567", -0.0005469999999999642],
 ["0.580933", -0.0005809999999999427],
 ["0.614300", 0.21389999999999998],
 ["0.647667", 0.21386699999999997],
 ["0.681033", 0.213833],
 ["0.714400", 0.2138],
 ["0.747767", 0.21376699999999993],
 ["10.082091", 0.21363500000000002],
 ["9.956966", 0.21375999999999884],
 ["9.998675", 0.2137190000000011],
 ["10.040383", 0.21367700000000056],
 ["10.082091", 0.21363500000000002],
 ["3.567245", -0.01113099999999978],
 ["2401.796387", -0.0024410000000898435],
 ["3496.649170", -0.0021969999997963896],
 ["2.574586", 0.013895000000000213], # -c- ? hmm... maybe it's impossible to get more than a frame worth of accurate
 ["2.983327", 0.013894000000000073],
 ["2012.032471", 0.18090800000004492],
 ["2012.074219", 0.18090800000004492]]
  
== osoh ==
last NAV packet was 0.000000, mpeg at 0.000000 not adding odd diff1? (probable skip) 0.000000adding 0.000000 to pts 0.000000
final: 0.000000
using mpeg ts appears larger, which if true is definitely better 0.000000 > 0.000000 - 1.0
Audio: no sound
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 720x480 => 854x480 Planar YV12
[mpeg2video @ 00d13780]ac-tex damaged at 0 7
[mpeg2video @ 00d13780]Warning MVs not available
[mpeg2video @ 00d13780]concealing 1035 DC, 1035 AC, 1035 MV errors in I frame

last NAV packet was 0.000000, mpeg at 0.033367 adding MPEG difference since last NAV of 0.033367 adding 0.000000 to pts 0.033400
final: 0.033400
using mpeg ts appears larger, which if true is definitely better 0.033367 > 0.033400 - 1.0

last NAV packet was 0.000000, mpeg at 0.280633 adding MPEG difference since last NAV of 0.280633 adding 0.000000 to pts 0.280914
final: 0.280914
using mpeg ts appears larger, which if true is definitely better 0.280633 > 0.280914 - 1.0
V:  0.28   2/  2 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.280633 adding MPEG difference since last NAV of 0.280633 adding 0.000000 to pts 0.280914
final: 0.280914
using mpeg ts appears larger, which if true is definitely better 0.280633 > 0.280914 - 1.0
V:  0.28   3/  3 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.314000 adding MPEG difference since last NAV of 0.314000 adding 0.000000 to pts 0.314314
final: 0.314314
using mpeg ts appears larger, which if true is definitely better 0.314000 > 0.314314 - 1.0
V:  0.31   4/  4 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.347367 adding MPEG difference since last NAV of 0.347367 adding 0.000000 to pts 0.347714
final: 0.347714
using mpeg ts appears larger, which if true is definitely better 0.347367 > 0.347714 - 1.0
V:  0.35   5/  5 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.380733 adding MPEG difference since last NAV of 0.380733 adding 0.000000 to pts 0.381114
final: 0.381114
using mpeg ts appears larger, which if true is definitely better 0.380733 > 0.381114 - 1.0
V:  0.38   6/  6 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.414100 adding MPEG difference since last NAV of 0.414100 adding 0.000000 to pts 0.414514
final: 0.414514

using mpeg ts appears larger, which if true is definitely better 0.414100 > 0.414514 - 1.0
V:  0.41   7/  7 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.447467 adding MPEG difference since last NAV of 0.447467 adding 0.000000 to pts 0.447914
final: 0.447914
using mpeg ts appears larger, which if true is definitely better 0.447467 > 0.447914 - 1.0
V:  0.45   8/  8 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.480833 adding MPEG difference since last NAV of 0.480833 adding 0.000000 to pts 0.481314
final: 0.481314
using mpeg ts appears larger, which if true is definitely better 0.480833 > 0.481314 - 1.0
V:  0.48   9/  9 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.514200 adding MPEG difference since last NAV of 0.514200 adding 0.000000 to pts 0.514714
final: 0.514714
using mpeg ts appears larger, which if true is definitely better 0.514200 > 0.514714 - 1.0
V:  0.51  10/ 10 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.547567 adding MPEG difference since last NAV of 0.547567 adding 0.000000 to pts 0.548114
final: 0.548114
using mpeg ts appears larger, which if true is definitely better 0.547567 > 0.548114 - 1.0
V:  0.55  11/ 11 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.580933 adding MPEG difference since last NAV of 0.580933 adding 0.000000 to pts 0.581514
final: 0.581514
using mpeg ts appears larger, which if true is definitely better 0.580933 > 0.581514 - 1.0
V:  0.58  12/ 12 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.614300 new NAV packet! 0.400000 at mpeg 0.614300 adding 0.000000 to pts 0.400400              => first NAV packet is *too low* to start (I guess a few are "too high") and over time it gets lower and lower?
     "dvd_nav_packet_offset" => [0.4, 0.6143]
	 
final: 0.400400
using mpeg ts appears larger, which if true is definitely better 0.614300 > 0.400400 - 1.0
V:  0.61  13/ 13 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.647667 adding MPEG difference since last NAV of 0.033367 adding 0.000000 to pts 0.433800
final: 0.433800
using mpeg ts appears larger, which if true is definitely better 0.647667 > 0.433800 - 1.0
V:  0.65  14/ 14 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.681033 adding MPEG difference since last NAV of 0.066733 adding 0.000000 to pts 0.467200
final: 0.467200
using mpeg ts appears larger, which if true is definitely better 0.681033 > 0.467200 - 1.0
V:  0.68  15/ 15 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.714400 adding MPEG difference since last NAV of 0.100100 adding 0.000000 to pts 0.500600
final: 0.500600
using mpeg ts appears larger, which if true is definitely better 0.714400 > 0.500600 - 1.0
V:  0.71  16/ 16  4%  0%  0.0% 0 0
last NAV packet was 0.400000, mpeg at 0.747767 adding MPEG difference since last NAV of 0.133467 adding 0.000000 to pts 0.534000
final: 0.534000
using mpeg ts appears larger, which if true is definitely better 0.747767 > 0.534000 - 1.0
V:  0.75  17/ 17  4%  0%  0.0% 0 0

...

last NAV packet was 3606.666667, mpeg at 3610.595755 adding MPEG difference since last NAV of 0.125125 adding 0.000000 to pts 3610.398583
final: 3610.398583

so typically NAV packets start less, then get less and less and less, relative to the MPEG timestamp.

so I can "hope" that I'm matching file times with this, can't I?

= ffmpeg seeking =


The "end" frame can be a non-iframe, so we can assume it seeks "10 seconds to the end" rather well.

start
[PACKET]
codec_type=video
stream_index=0
pts=114621
pts_time=1.273567
dts=105612
dts_time=1.173467
duration=3003
duration_time=0.033367
convergence_duration=N/A
convergence_duration_time=N/A
size=66353
pos=30
flags=K
[/PACKET]


ends:
[PACKET]
codec_type=audio
stream_index=1
pts=988380
pts_time=10.982000
dts=988380
dts_time=10.982000
duration=2880
duration_time=0.032000
convergence_duration=N/A
convergence_duration_time=N/A
size=1792
pos=3940364
flags=K
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=997503
pts_time=11.083367
dts=988494
dts_time=10.983267
duration=3003
duration_time=0.033367
convergence_duration=N/A
convergence_duration_time=N/A
size=8021
pos=3895296
flags=_
[/PACKET]

for a non iframe. huh?

possibly it's doing audio "from 1 to 11" then when it hits audio, its skipping some (valid) later video frames, for 1, and for 2
  shouldn't it synchronize on having both audio and video available? It doesn't get enough video? and why the warning message "no an i-frame"?

oops looks like it took audio "up to" 11 and video "past" 11?
  
possibly the only question is "are you comfortable having less video?" (if so, why does it have an 11.08 pts time frame?) and "why does it have that warning" at all?

=c=

last NAV packet was 3006.633301, mpeg at 3010.112549 adding difference 0.291748 adding 0.214000 to pts 3009.931641
final: 3010.145752

"within one frame worth" or whatever woot


Seeking 10-15

last NAV packet was 9.600000, mpeg at 10.082091 adding difference 0.258597 adding 0.000000 to pts 9.868456
final: 9.868456
using mpeg ts appears larger, which if true is definitely better 10.082091 > 9.868456 - 1.0


EDL rel seek secs +4.917909 from pts:10.082091 [10.000000,15.000000]

last NAV packet was 9.600000, mpeg at 10.082091 adding difference 0.258597
jumping to 1329885
[mpeg2video @ 00d2c8e0]ignoring SEQ_START_CODE after 100
[mpeg2video @ 00d2c8e0]ignoring seq ext after 100
[mpeg2video @ 00d2c8e0]ignoring GOP_START_CODE after 100
[mpeg2video @ 00d2c8e0]ignoring pic after 100
[mpeg2video @ 00d2c8e0]Missing picture start code, guessing missing values
A:  11.1 V: 15.16 A-V: -4.098 ct: -0.100   3/  3 ??% ??% ??,?% 0 0
last NAV packet was 14.833333, mpeg at 15.162167 new NAV packet! 14.833333 at mpeg 15.162167 adding 0.000000 to pts 14.848167
final: 14.848167


so basically MPEG went from 10.082091 -> 15.162167 which is really close.

Also NB it appears to handle skips one frame too late [?]

using mpeg ts appears larger, which if true is definitely better 9.956966 > 9.743206 - 1.0
A:  10.0 V: 10.00 A-V: -0.007 ct: -0.204 104/100  4%  0% 11.6% 0 0
last NAV packet was 9.600000, mpeg at 9.998675 adding difference 0.175181 adding 0.000000 to pts 9.784956
final: 9.784956
using mpeg ts appears larger, which if true is definitely better 9.998675 > 9.784956 - 1.0
A:  10.0 V: 10.04 A-V: -0.009 ct: -0.205 105/101  4%  0% 11.8% 0 0
last NAV packet was 9.600000, mpeg at 10.040383 adding difference 0.216889 adding 0.000000 to pts 9.826706
final: 9.826706
using mpeg ts appears larger, which if true is definitely better 10.040383 > 9.826706 - 1.0
A:  10.1 V: 10.08 A-V: -0.011 ct: -0.206 106/102  3%  0% 12.3% 0 0
last NAV packet was 9.600000, mpeg at 10.082091 adding difference 0.258597 adding 0.000000 to pts 9.868456
final: 9.868456
using mpeg ts appears larger, which if true is definitely better 10.082091 > 9.868456 - 1.0



= Sintel should match up =

"dvd_nav_packet_offset" => [0.5, 0.734067],
"dvd_start_offset" => 0.37,

I don't actually match up, 3.5 to 3.8, *because* my current goal is apparently to psycho-match the
internal MPEG timestamp. Yikes. And it does. Dang :P

= for ref =

big DVD list: http://www.hometheaterinfo.com/dvdlist.htm

= not jumping from right time DVD =

 == turtles ==

VLC seems to fail seeking on it, too. Hmm...

=c= to 15.1, from second 13:

  last NAV packet was 12.833333, mpeg at 13.201875 after -> 29.97 12.846167
  adding difference 0.166841

  EDL rel seek secs 2.086993 13.013007 [13.000000,15.100000]

  11.5 15.2 0 still fails, new mplayer

  the "old old way" did jump ok, but to second 30 (and they probably had other probs :P)
  
= seeking with new dvdnav =

works fine jonah [forward too far?]
  like a full second too far.  This is not very precise too...

sintel works ok
  
 big buck:
  jump 9.5 to 15 goes to 15.68 or so...
  about a second "ahead" at 9 minutes, as well.
  so works ok
  
  everything from 15.{0-9} all went forward just right.
  
 =c= eureka! fails at second 10
   at 1:10, seeking to 3615
     new NAV packet! 3615.345215
   at 30:00
     new NAV packet! 1805.270142 so within 0.4 ...
    to 15:
       14.833333
	to 14.5:
	   14.833333
	to 14.3:
	   14.400000 (there is 14.83)
	to 15.6:
	   15.600000
	   
	15.0: 14.83
	15.1: 14.833333
	15.2: 15.6
	15.3: 15.6
	15.4: 15.6
	15.5: 15.6
	15.6: 15.6
	15.7: 15.6
	15.8: 15.6 but worked
	16.3: 16.4
	
	  it has 13.6,14.4,14.83,15.6,16.4,16.83
	 
	 
	 to 15.7 has to jump twice:
	 
A:  13.2 V: 13.20 A-V: -0.002 ct: -0.212  33/ 33  2% 24% 18.7% 0 0
last NAV packet was 12.833333, mpeg at 13.201875 after -> 29.97 12.846167
adding difference 0.166841

EDL rel seek secs 2.686993 13.013007 [13.000000,15.700000]

jumping to 1396829
DVDNAV_TITLE_IS_MOVIE
[mpeg2video @ 00c3fa80]ignoring SEQ_START_CODE after 100
[mpeg2video @ 00c3fa80]ignoring seq ext after 100
[mpeg2video @ 00c3fa80]ignoring GOP_START_CODE after 100
[mpeg2video @ 00c3fa80]ignoring pic after 100
[mpeg2video @ 00c3fa80]Missing picture start code, guessing missing values
weird fella suddenly we're not a DVD? mpeg at 0.041708 adding 0.214000 to 0.041708
final: 0.255708

last NAV packet was 15.600000, mpeg at 0.083417 after -> 29.97 15.615601
new NAV packet! 15.615601 [adjusted] at 0.083417 adding 0.214000 to 15.615601
final: 15.829600

last NAV packet was 15.600000, mpeg at 0.125125 after -> 29.97 15.615601
adding difference 0.041708 adding 0.214000 to 15.657309
final: 15.871308

last NAV packet was 15.600000, mpeg at 15.962967 after -> 29.97 15.615601
not adding odd diff1? 15.879550adding 0.214000 to 15.615601
final: 15.829600
A:  14.0 V: 15.96 A-V: -1.986 ct: -0.100   3/  3 ??% ??% ??,?% 0 0
last NAV packet was 15.600000, mpeg at 15.962967 after -> 29.97 15.615601
not adding odd diff1? 0.000000

EDL rel seek secs 0.084399 15.615601 [13.000000,15.700000]
	 
	 
= =

= explorers subs =
  apperas that despite being "right on" for two, others within were 0.09 off and 0.18 off. Hmm.
  I think I got some closure on this though...
  
the christmas list: two deity prof's [TODO EDL]

= court jester =
#-> 1:41:11.465, ts 01:41:10.94, mkv 01:41:13.01

= hp 2 weird start =

last NAV packet was 0.000000, mpeg at 0.000000 after -> 29.97 0.000000
not adding odd diff1? 0.000000adding 0.000000 to 0.000000
final: 0.000000
Audio: no sound
Starting playback...
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [null] 720x480 => 720x540 Planar YV12
[mpeg2video @ 00c3fa80]ac-tex damaged at 0 7
[mpeg2video @ 00c3fa80]Warning MVs not available
[mpeg2video @ 00c3fa80]concealing 1035 DC, 1035 AC, 1035 MV errors

last NAV packet was 0.000000, mpeg at 0.050050 after -> 29.97 0.000000
adding difference 0.050050 adding 0.000000 to 0.050050
final: 0.050050

last NAV packet was 0.000000, mpeg at 0.128911 after -> 29.97 0.000000
adding difference 0.128911 adding 0.000000 to 0.128911
final: 0.128911
V:  0.13   3/  2 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.178961 after -> 29.97 0.000000
adding difference 0.178961 adding 0.000000 to 0.178961
final: 0.178961
V:  0.18   4/  3 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.212328 after -> 29.97 0.000000
adding difference 0.212328 adding 0.000000 to 0.212328
final: 0.212328
V:  0.21   5/  4 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.128911 after -> 29.97 0.000000 # huh? no what? wha?!
adding difference 0.128911 adding 0.000000 to 0.128911
final: 0.128911
V:  0.13   6/  5 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.162278 after -> 29.97 0.000000
adding difference 0.162278 adding 0.000000 to 0.162278
final: 0.162278
V:  0.16   7/  6 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.212328 after -> 29.97 0.000000
adding difference 0.212328 adding 0.000000 to 0.212328
final: 0.212328

= ratatouille weird start, timing=

"1:26:15.57" , "1:26:18.87", "profanity", "bloo..", "and no one else seems to have it in this [bloo..] town,",


# srt:

# 00:00:30,784 --> 00:00:32,884	
# <i>Although each of the world's countries</i>
# 1.5s too early

#1027
#01:13:35,641 --> 01:13:38,441
#- Sorry, chef.
#- The rat! It's stolen my documents!
# 1.2s too late

#1189
#01:26:17,441 --> 01:26:20,741
#and no one else
#seems to have it in this bloody town,

# adjusted 1:26:19.07 start of it.
# mplayer-edl which is still adjusted 1:26:18f20

# the adjustment seems correct...

# end in mplayer-edl 1:42:31.14

#if you use the end one right...

#1:13:37,32 --> 1:13:40,12
#- Sorry, chef.
#- The rat! It's stolen my documents!

# except now the right code is 1:13:37.30'ish for that LOL 37.29 with and without volume
# which aligns with the end perfectly LOL 1:42:31,10 !

with a second and 3rd srt, which almost exactly matches the first...and is wrong...LOL. Maybe...this DVD is too screwed up to have reliable time signatures after a point?
try with ending timestamps [fails even worse?]

try writing a synchronized fella, see where it failz


1:42:25.55

last NAV packet was 0.000000, mpeg at 0.000000 after -> 29.97 0.000000
not adding odd diff1? 0.000000adding 0.000000 to 0.000000
final: 0.000000
Audio: no sound
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 720x480 => 854x480 Planar YV12
[mpeg2video @ 00c3fa80]ac-tex damaged at 37 7
[mpeg2video @ 00c3fa80]Warning MVs not available
[mpeg2video @ 00c3fa80]concealing 1035 DC, 1035 AC, 1035 MV errors

last NAV packet was 0.000000, mpeg at 0.033367 after -> 29.97 0.000000
adding difference 0.033367 adding 0.000000 to 0.033367
final: 0.033367

last NAV packet was 0.000000, mpeg at 0.280633 after -> 29.97 0.000000
adding difference 0.280633 adding 0.000000 to 0.280633
final: 0.280633
V:  0.28   2/  2 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.280633 after -> 29.97 0.000000
adding difference 0.280633 adding 0.000000 to 0.280633
final: 0.280633
V:  0.28   3/  3 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.314000 after -> 29.97 0.000000
adding difference 0.314000 adding 0.000000 to 0.314000
final: 0.314000
V:  0.31   4/  4 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.347367 after -> 29.97 0.000000
adding difference 0.347367 adding 0.000000 to 0.347367
final: 0.347367
V:  0.35   5/  5 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.380733 after -> 29.97 0.000000
adding difference 0.380733 adding 0.000000 to 0.380733
final: 0.380733
V:  0.38   6/  6 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.414100 after -> 29.97 0.000000
adding difference 0.414100 adding 0.000000 to 0.414100
final: 0.414100
V:  0.41   7/  7 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.447467 after -> 29.97 0.000000
adding difference 0.447467 adding 0.000000 to 0.447467
final: 0.447467
V:  0.45   8/  8 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.480833 after -> 29.97 0.000000
adding difference 0.480833 adding 0.000000 to 0.480833
final: 0.480833
V:  0.48   9/  9 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.514200 after -> 29.97 0.000000
adding difference 0.514200 adding 0.000000 to 0.514200
final: 0.514200
V:  0.51  10/ 10 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.547567 after -> 29.97 0.000000
adding difference 0.547567 adding 0.000000 to 0.547567
final: 0.547567
V:  0.55  11/ 11 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.580933 after -> 29.97 0.000000
adding difference 0.580933 adding 0.000000 to 0.580933
final: 0.580933
V:  0.58  12/ 12 ??% ??% ??,?% 0 0
last NAV packet was 0.000000, mpeg at 0.614300 after -> 29.97 0.000000
adding difference 0.614300 adding 0.000000 to 0.614300
final: 0.614300
weird fella suddenly we're not a DVD? mpeg at 0.033367 adding 0.000000 to 0.033367
final: 0.033367
V:  0.03   0/  0 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.066733 after -> 29.97 0.400400 # this less a frame I guess...
new NAV packet! 0.400400 [adjusted] at 0.066733 adding 0.000000 to 0.400400
final: 0.400400
V:  0.07   1/  1 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.280633 after -> 29.97 0.400400
adding difference 0.213900 adding 0.000000 to 0.614300
final: 0.614300
V:  0.28   2/  2 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.314000 after -> 29.97 0.400400
adding difference 0.247267 adding 0.000000 to 0.647667
final: 0.647667
V:  0.31   3/  3 ??% ??% ??,?% 0 0
last NAV packet was 0.400000, mpeg at 0.347367 after -> 29.97 0.400400
adding difference 0.280633 adding 0.000000 to 0.681033
final: 0.681033


zoomplayer max
env ALLUSERSPROFILE apparently [?]

= am I accurate all the way through with dvd_nav_offset =

==osoh==

started quite well

 mpeg at 4.159503 after -> 29.97 3.670333
adding difference 0.291959 adding 0.213686 to 3.962293
final: 4.175979

0.016

 1808.166626, mpeg at 1810.214111 after -> 29.97 1809.974854
adding difference 0.041748 adding 0.213686 to 1810.016602
final: 1810.230347

0.016

mpeg at 5418.517090 after -> 29.97 5417.845703
adding difference 0.458984 adding 0.213686 to 5418.304688
final: 5418.518555

0.0014

 mpeg at 5532.005859 after -> 29.97 5531.458984
adding difference 0.334473 adding 0.213686 to 5531.793457
final: 5532.007324


0.002

suh-weet

 mpeg at 6728.743164 after -> 29.97 6728.188477
adding difference 0.376465 adding 0.213686 to 6728.564941
final: 6728.778809

0.035645

==prince of egypt==

mpeg at 0.681033 after -> 29.97 0.400400
new NAV packet! 0.400400 [adjusted] at 0.681033 adding 0.281033 to 0.400400
final: 0.681433

 mpeg at 1.081433 after -> 29.97 0.800800
new NAV packet! 0.800800 [adjusted] at 1.081433 adding 0.281033 to 0.800800
final: 1.081833

still 0.0004

2.233333, mpeg at 2.516194 after -> 29.97 2.235567
new NAV packet! 2.235567 [adjusted] at 2.516194 adding 0.281033 to 2.235567
final: 2.516600

0.0006

all monotonic
 3.000000, mpeg at 3.266944 after -> 29.97 3.003000
new NAV packet! 3.003000 [adjusted] at 3.266944 adding 0.281033 to 3.003000
final: 3.284033

0.017


 was 5.000000, mpeg at 5.268946 after -> 29.97 5.005000
new NAV packet! 5.005000 [adjusted] at 5.268946 adding 0.281033 to 5.005000
final: 5.286033

0.017 off [?]

mpeg at 6.937278 after -> 29.97 6.506500
adding difference 0.166832 adding 0.281033 to 6.673332
final: 6.954365

 mpeg at 13.777442 after -> 29.97 13.513500
new NAV packet! 13.513500 [adjusted] at 13.777442 adding 0.281033 to 13.513500
final: 13.794533

mpeg at 1819.873779 after -> 29.97 1819.484253
adding difference 0.125244 adding 0.281033 to 1819.609497
final: 1819.890503

still  0.017 off ...

50:
 mpeg at 3020.189209 after -> 29.97 3019.616699
adding difference 0.291504 adding 0.281033 to 3019.908203
final: 3020.189209
LOL

0.000

near end:

mpeg at 4244.576660 after -> 29.97 4244.172852
adding difference 0.124512 adding 0.281033 to 4244.297363
final: 4244.578613

0.002 ok now I am weirded out...

 packet was 5622.200195, mpeg at 5628.225586 after -> 29.97 5627.822266
adding difference 0.124512 adding 0.281033 to 5627.946777
final: 5628.228027

0.003

can't complain about this stuff uh guess...umm...uh...hmm...
  integer arithmetic is losing some precision perhaps?  seems all right tho...
  
  
  =c=
  mpeg at 0.681033 after -> 29.97 0.400400
  adding difference 0.066733 adding 0.214300 to 0.467133
  final: 0.681433
  [had some other that didn't seem as close...]
  
 mpeg at 47.494480 after -> 29.97 47.280567
new NAV packet! 47.280567 [adjusted] at 47.494480 adding 0.214300 to 47.280567
final: 47.494865

0.004

 mpeg at 610.882202 after -> 29.97 610.409790
 adding difference 0.292053 adding 0.214300 to 610.701843
 final: 610.916138

 mpeg at 1815.794556 after -> 29.97 1815.280151
adding difference 0.333618 adding 0.214300 to 1815.613770
final: 1815.828125

0.033

 mpeg at 3020.873535 after -> 29.97 3020.650879
adding difference 0.041748 adding 0.214300 to 3020.692627
final: 3020.906982

0.033

still kinder close...
= softskip,pullup =

somehow sintel is IIPPPII even though it's 29.97 fps "telecine"

Progressive video requires no special filtering to encode.

if I want to autodetect it...

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

last NAV packet was 1.666667, mpeg at 2.094940 after -> 29.97 1.668333
adding difference 0.212707 adding 0.213686 to 1.881040
final: 2.094726
A:   2.1 V:  2.09 A-V: -0.009 ct: -0.172  57/ 54 24% 55% 15.9% 20 0

=c= 24000/1001fps progressive NTSC content detected

= zoomplayer max scene cut editor =

existed since 01 May 2004 http://forum.inmatrix.com/index.php?showtopic=136&hl=%2Bcut+%2Bscene&fromsearch=1

With DVDs, scene-cut files are saved in the Zoom Player 
  DVD Bookmark directory (usually "C:\Program Files\Zoom Player\DVD-Bookmarks") as a "disc.cut" file. 

== VLC yuvp sox ==

red should always be under each word

Table 2.8. Packed YUV Image Formats
Identifier	Code	 	                 Byte 0 in memory	 	                 Byte 1	
 	 	Bit	7	6	5	4	3	2	1	0	 	7	6	5	4	3	2	1	0	 	7	6	5	4	3	2	1	0	 	7	6	5	4	3	2	1	0
V4L2_PIX_FMT_YUV444	'Y444'	 	Cb3	Cb2	Cb1	Cb0	Cr3	Cr2	Cr1	Cr0	 	a3	a2	a1	a0	Y'3	Y'2	Y'1	Y'0	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 
V4L2_PIX_FMT_YUV555	'YUVO'	 	Cb2	Cb1	Cb0	Cr4	Cr3	Cr2	Cr1	Cr0	 	a	Y'4	Y'3	Y'2	Y'1	Y'0	Cb4	Cb3	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 
V4L2_PIX_FMT_YUV565	'YUVP'	 	Cb2	Cb1	Cb0	Cr4	Cr3	Cr2	Cr1	Cr0	 	Y'4	Y'3	Y'2	Y'1	Y'0	Cb5	Cb4	Cb3	 	 	 	 	 	 	 	 	 	 	 # this totally seems unrelated somehow...huh?	 	 	 	 	 	 
V4L2_PIX_FMT_YUV32	'YUV4'	 	a7	a6	a5	a4	a3	a2	a1	a0	 	Y'7	Y'6	Y'5	Y'4	Y'3	Y'2	Y'1	Y'0	 	Cb7	Cb6	Cb5	Cb4	Cb3	Cb2	Cb1	Cb0	 	Cr7	Cr6	Cr5	Cr4	Cr3	Cr2	Cr1	Cr0



YUVP 	0x50565559 	24? 	YCbCr 4:2:2 extended precision 10-bits per component in Y0 U0 Y1 V0 order.

maybe the Y is the alpha?


AYUV This is a 4:4:4 YUV format with 8 bit samples for each component along with an 8 bit alpha blend value per pixel. Component ordering is A Y U V (as the name suggests).


special:

                if( p_trans[i_x+1] > 0xaa )


YUVA might be 1,2,2,1



"YUV" mostly means "Y′CbCr" typically Y is strongest.


looks like alpha is 3:
            i_trans = vlc_alpha( p_pal[p_trans[i_x]][3], i_alpha );

y is 0
u is 1
v is 2


a comes from A_PLANE


    BLEND_CFG( VLC_CODEC_YUVA, BlendYUVAI420, BlendYUVAYUVPacked /* I liked this one */, BlendYUVARV16, BlendYUVARV24 ),

    BLEND_CFG( VLC_CODEC_YUVP, BlendPalI420, BlendPalYUVPacked %* ++ %*, BlendPalRV, BlendPalRV ),


interesting, maybe I need to be "writing" to pitches too?


                if( p_trans_is_src[i_x+1] > 0xaa )
                {
                    i_u = (p_pal[p_src[i_x]][1] + p_pal[p_src[i_x+1]][1]) >> 1;
                    i_v = (p_pal[p_src[i_x]][2] + p_pal[p_src[i_x+1]][2]) >> 1;
                }

.so

swapped = 0 always

u,v struggle.
incoming as VLC_CODEC_YUVP (from that)

http://download.videolan.org/pub/videolan/vlc/0.8.6i/win32/
2008-Sep-09 19:23:18
is ok (blend plugin)

0.9.9 not there [no libyuvp either, but yes yuvgrey.dll]
1.0.0 broken, yes there

1.2.0, 1.3.0 nightlies: right color, wrong place


remove libyuvp_plugin.dll

1.1.11 is grey *always*

1.2.0 nightlie it's right color, wrong place

linux?

= upconv dvd =

2:34:12 seem the same (sky view houses)
2:35:34 seem same (alleyway)
2:36:89 crud over right shoulder igual
42:.40 door same
2:44.73 one line of difference 2x is taller LOL [really none I guess]
1x is looking really good...
2:48.37 igualzinho
47.27 slightly furry hair:
47:27 igualzinho

the reality is her hair looks "good but out of focus" with 2x as well.

I must concede LOL

does -sws 9 make a difference without any "real" upscaling...it seems to not do...

===emperor's new groove: ===
pauses in mplayer, seems...great in vlc...didn't check vlc logs though.
when he throws hat, without upconvert too phew
  8% 9% cpu...2000

 some jerks in mplayer [baby] not in VLC. cache?
  
  

Too many video packets in the buffer: (4096 in 8275996 bytes).
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.
[ac3 @ 00c3fa80]incomplete frame

may have been a reset...
this has a bajillion resets...
I think VLC is just skipping it LOL.

Too many video packets in the buffer: (4096 in 8275996 bytes).
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.
[ac3 @ 00c3fa80]incomplete frame

  
TODO book 2x
  
veggie tales where's g: fails css, fine vlc

vlc paused a tidge at the beginnning

= xbmc timings =

xbmc seems to use "straight" dvdnav time.

====
1.0rc4 seeks fine dvd://, fails dvdnav:// apparently
trunk seeks fine dvdnav://
MPlayerX 1.0.9's mplayer seeks fine dvdnav://
mplayer.here seeks fine dvdnav:// (with 1.0rc4 installed)

theirs loops with their vendored libdvdnav
  theirs works with real DVD paths LOL ignore that then
  
To increase the maximum volume to 400%, use softvol=yes and softvol-max=400
@smplayer: use the right time sig!

OS X Extended possibly lacks the lib, though it "has" dvdnav apparently, seems too useless

mplayer 1.0rc4 suddenly cannot seek
  dvd:// does tho

mplayer.here still can tho

mplayer-devel old can seek fine dvd://

= dvdnav arrow keys =

works fine doze Sherpya-SVN-r34118-4.2.5
  doze SVN-r34269-4.5.1

failz with mplayer_me port
unknown with mplayerX dvdnav

TODO try -v, and -nocache, and trunk, check for some phreaky config file
  maybe just rebuild mplayer-devel with dvdnav enabled, see if it still occurs
  
http://forums.gentoo.org/viewtopic-p-6148657.html?sid=316c0fef9f0570a479920be25599ec0e has explicit
 but still weird

known bug?
http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-June/080476.html

34118 linux works
SVN-r34269-4.5.2 linux works

= macports mpkg extraneous =

perl seems to be the only extra...
  #depends_fetch-append bin:git:git-core

gettext might come from subversion, as well fetch.type svn, pkgconfig

cannot have multiple mpkg's easily

= NAV to MPEG =

negative NAV offset: mpeg - "0.21" - nav_converted

NAV packets must be "messed up" for the 0.0s versus 0.4s, relative to 
 the start of the MPEG, but if they'are always about 0.2 (they're not though... but typically quite close...hmm...)
  I guess the problem is I don't have the 0.28 time for all EDL's?

  tangled:
  "dvd_start_offset" => "0.21", # for title 1
  last NAV packet was 0.400000, mpeg at 0.033367
  last NAV packet was 0.400000, mpeg at 0.207756
  ...
  last NAV packet was 0.900000, mpeg at 1.041922
    may have had extra resets in there...
  negative dvdnav offset: -0.069  looks good...
  
  time bandits is streamed
  
  finding neverland:
    "dvd_start_offset" => "0.28", # for title 1
    last NAV packet was 0.000000, mpeg at 0.033367
	last NAV packet was 0.000000, mpeg at 0.280633
	                    0.500000, mpeg at 0.735254
	negative dvdnav offset: -0.05 # hmm...
	
  night at the museum:
  
"dvd_start_offset" => "0.20", # for title 1
    last NAV packet was 0.000000, mpeg at 0.033367 a
	 0.000000, mpeg at 0.199800 # video packet I believe...
	 ...
	 last NAV packet was 0.433333, mpeg at 0.533467 # 0.1 ! but note it st
	 negative dvdnav offset: -0.09
	 
	 last NAV packet was 3603.433333, mpeg at 3607.136401
	 3607.1364 - 0.2-(3603.4333*1.001)
       => -0.10033329999987473
	   then has a split
  american mormon:
  
"dvd_start_offset" => "0.3", # for title 8
	last NAV packet was 0.000000, mpeg at 0.033367
	last NAV packet was 0.000000, mpeg at 0.300300
	last NAV packet was 0.433333, mpeg at 0.667333 # 0.23, seems to have no correlation?
	  negative dvd offset: -0.065
	
	last NAV packet was 1803.533333, mpeg at 1805.570402
	   1805.57 - 0.3-(1803.533*1.001)
       => -0.06653299999970841  might be an expected creep LOL
	     this explains why my numbers get slightly less accurate near the end...
	  that's about the end
	  
	seeker letters up:
	
"dvd_start_offset" => "0.2", # for title 1
	 0.000000, mpeg at 0.033367
	  0.000000, mpeg at 0.195633
	  last NAV packet was 0.433333, mpeg at 0.562667
	  negative dvdnav offset: -0.069
	  last NAV packet was 3603.833333, mpeg at 3607.549158
	     3607.55-0.195-(3603.833*1.001)
          => -0.08183299999973315
	  last NAV packet was 5403.600000, mpeg at 5409.099292
	  5409.099 -0.195-(5403.6*1.001)
      => -0.09959999999955471
	      creeping? but that's after like 2 hours...hmm...
		  
      prince o' egypt: 0.68-0.35-0.4
      => -0.07
= dying/crashing dvdnav =

linux VLC:
  libdvdnav: Invalid angle block
linux mplayer pristine, no libdvd:
  libdvdnav: Invalid angle block
linux 34118: 
  libdvdnav: Invalid angle block

tangled loops VLC blackey
tangled loops VLC work desktop

all disney say "no VTS" (only from within virtualbox?).
works fine VLC mac [with nav] doesn't loop at all [?]

mplayer blackey:
Assertion failed: (vm->state).pgc->cell_playback[(vm->state).cellN - 1].block_mode != 0, file libdvdnav/vm/vm.c, line 1134
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
MPlayer interrupted by signal 22 in module: decode_audio

dies new lappy same spot, same DVD, but clean :P

dies with mplayer  Sherpya-SVN-r30369-4.2.5m libdvdnav: Using dvdnav version MPlayer-custom same way

mac:
libdvdnav: Invalid angle block mplayer.here  UNKNOWN-4.2.1 libdvdnav: Using dvdnav version MPlayer-custom
same with MPlayer SVN-r34269-4.2.1 (C) 2000-2011 MPlayer Team
  didn't include the latest dvdnav patches though...though mplayer_edl does :P

report different DVD: http://lists.mplayerhq.hu/pipermail/mplayer-users/2008-December/075458.html
  https://trac.handbrake.fr/ticket/125
  https://forum.handbrake.fr/viewtopic.php?f=11&t=14189
  
= VLC patch =

dvdnav:// actually has "times" that match its "seek tos"
  they just don't match reality :P
  "don't you get it, Ben?"
  
dvdread:// has "times" that match its "seek tos"
  1:00:00 "don't you get it, Ben?"

  should be "I found The Charlotte?...[]The Charlotte?" if it follows sum NAV times...which it doesn't :P
  so they're both bworked, or what?
    dvdnav at least is returning some phreaky ratio: (double)pos / (double)len;
      I guess this lets it...seek ok [but it doesn't always?]
      sounds bworked to me...

http://git.videolan.org/?p=vlc.git;a=blobdiff;f=modules/access/dvdnav.c;h=99f2e111fb08b9aa00dffcd3feb081d0d2741902;hp=e7f5adf371db87972a5a0530338e898e8f864ae7;hb=99e7dfd49ccdbe8cbb06bd8047b7080e09fc675e;hpb=bc61326a1dc4e58d6de4d7ce0e0d74efd51b37ca
was dvdnav splitting into percents.

dvd://D:\ *is* dvdnav.

dvdnav_get_duration

dvdread seems to be 'seek this many blocks'

typedef int64_t mtime_t;
int64_t pgc_length;  /* the length of the current program chain in PTS ticks */
i_pgc_length =  event->pgc_length * 1000 / 90;

should be 4:02 => 242 seconds 

30 should be:
  2946600
  
  dvdnav_time_search versus dvdnav_sector_search huh?
     I think sector_search has an "offset" and also a "force me to go forward" aspect, so they don't immediately conflict [?]
    
    pass back needed:
    
    get time 3894009
get length 1718232704
    get time:
     *va_arg( args, int64_t * ) =(  event->pgc_length * 1000 / 90)*pos/len;
    get length:
    *va_arg( args, int64_t * ) = (int64_t)p_sys->i_pgc_length
    
    3M for 2seconds, end of sounds
    

VLC has the right timestamps now, appears.
  guess it's actually consistent (but with wrong times) currently.
  some of them are way off though, right? But at least it always goes forward...
    LODO find more that are off in VLC...
	seems mostly consistent, so hold off I suppose :P
  
= ffplay no white's =

241,241 with VLC displaying mostly-white.bmp
paint.net 255,255,255

= seeking Chris' = "Roger's Wedding" label

WMP fails miserably LOL

(VLC does better with menus than WMP does :P)

VLC seeking is actually right on... [?]
mplayer_me seems to jump forward by like 1s for 10 LOL
mplayer seems right on, too...
  *** libdvdread: CHECK_VALUE failed in libdvdread4/ifo_read.c:1664 ***
  *** for c_adt->cell_adr_table[i].start_sector < c_adt->cell_adr_table[i].last_sector ***
     then it plays fine :P
    
    same with mplayer_me
    
    handbrake refuses it :P
    
 == WEDDING == (temple picture)
  seeking seems great, fast, no weird messages, handbrake ok

== seeking -c-=

his seeks about 15s for a 10s seek
  normal mplayer: like 23s whoa!

last NAV packet was 3583.466553 after -> 29.97 3587.050049
mpeg at 88.030502 
adding difference 0.041710 adding 0.200000 to 3587.091797
final: 3587.291748
"mplayer_dvd_splits" => ["3499.07"],  # better than 3499.4 with audio only which is like 0.4 too far?
"dvd_start_offset" => "0.28",


  *with an already added 0.2*
  NAV 3583.466553 -> 29.97 3587.050049
    + difference 0.042
    + 0.214
    --------
     3587.304049 =?= 3587.270502 PRETTY CLOSE lolz
    
88.030502 + 3499.07 + *0.17*
=>  3587.270502

NAV to equal DVD MPEG should be
  NAV*29.97 + (0.214) + difference 
(3587.050049) + 0.214 + 0.042 = 3587.306049 [yup]

= other -c- =

last NAV packet was 2.833333, mpeg at 3.567245 after -> 29.97 2.836167
adding difference 0.542209 adding 0.200000 to 3.378376
final: 3.578376
using mpeg ts appears larger, which if true is definitely better 3.567245 > 3.578376 - 1.0

  2.836167 + 0.2+0.5422 = 3.578367 =~=  3.567245 yes
                          3.588367 hmm...I'm always ahead weird

 ==== again ====
  last NAV packet was 2399.033447, mpeg at 2401.796387 after -> 29.97 2401.432373
  adding difference 0.166504 adding 0.200000 to 2401.598877
  final: 2401.798828
  using mpeg ts appears larger, which if true is definitely better 2401.796387 > 2401.798828 - 1.0

 2401.432373 + 0.2 + 0.166 =  2401.798373 =?= 2401.796387 yes

==== again ====
  last NAV packet was 3492.833252, mpeg at 3496.649170 after -> 29.97 3496.326172
  adding difference 0.125244 adding 0.200000 to 3496.451416
  final: 3496.651367
  using mpeg ts appears larger, which if true is definitely better 3496.649170 > 3496.651367 - 1.0
  
  3496.326172 + 0.2 + 0.125 =  3496.651172 =?= 3496.649170 yes

==== @break ====
last NAV packet was 3495.333252, mpeg at 0.291958 after -> 29.97 3498.828613
not adding negative diff -3498.734375adding 0.200000 to 3498.828613
final: 3499.028564
last NAV packet was 3495.733398, mpeg at 0.333667 after -> 29.97 3499.229248
new NAV packet 3499.229248 at 0.333667 adding 0.200000 to 3499.229248
final: 3499.429199
 0.4 NAV again

at the split:

last NAV packet was 3495.733398, mpeg at 0.375375 after -> 29.97 3499.229248
adding difference 0.041708 adding 0.200000 to 3499.270996
final: 3499.470947
last NAV packet was 3495.733398, mpeg at 0.251133 after -> 29.97 3499.229248
not adding negative diff -0.082533adding 0.200000 to 3499.229248
final: 3499.429199

are there two splits in there?
maybe the early/late split audio is killing it somehow?

here's a split:

last NAV packet was 3495.733398, mpeg at 3499.485107 after -> 29.97 3499.229248
adding difference 0.041748 adding 0.000000 to 3499.270996
final: 3499.270996
A:   1.3 V:3499.49 A-V:-3498.211 ct: -0.306  26/ 26 72% 30% 179.4% 0 0
last NAV packet was 3495.733398, mpeg at 0.251133 after -> 29.97 3499.229248
not adding odd diff1? -3499.192139adding 0.000000 to 3499.229248
final: 3499.229248

implies a split at  3499.273974'ish sweet!

A:   0.6 V:3498.69 Maybe audio way ahead here?

audio *is* growing...
A:   0.9 V:3499.15 A-V:-3498.217 ct: -0.254  19/ 19 96% 65% 209.9% 0 0
  =====  PAUSE  =====
 telecine = 1.5  0.157
vd_ffmpeg data: 10000, fbff5701, 1000080, fb5f86b5
using IPB
OSD chg: 5  V: no  pb:-1
A:   1.0 V:3499.19

A:   1.3 V:3499.49 then
A:   1.4 V:  0.25

maybe doesn't flush buffers well/right? looks like their audio is way ahead at a split... A:   2.1 V:  0.94

of course, I don't have framedrop on...
...
A:   5.0 V:  4.19
...
A:   9.6 V:  9.41
...
A:  14.0 V: 13.99

does catch back up...somehow? so maybe the MPEG itself is offset...that's nuts but possible...


Would the true split please stand up?
34118:
A:3498.3 V:3498.32 A-V: -0.040 ct: -0.248  58/ 55 21%  5% 35.5% 0 0
A:3498.3 V:3498.36 A-V: -0.031 ct: -0.251  59/ 56 20%  5% 34.9% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.247   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:  0.04 A-V: -0.728 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:  -0.6 V:  0.04 A-V: -0.608 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:  -0.4 V:  0.04 A-V: -0.468 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:  -0.3 V:  0.04 A-V: -0.298 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:  0.04 A-V: -0.128 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.032 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.04 A-V:  0.132 ct: -0.243   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.151 ct: -0.239   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:  0.13 A-V:  0.139 ct: -0.235   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.107 ct: -0.231   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:  0.21 A-V:  0.106 ct: -0.226   5/  5 ??% ??% ??,?% 0 0
A:   0.4 V:  0.25 A-V:  0.114 ct: -0.222   6/  6 ??% ??% ??,?% 0 0
A:   0.4 V:3498.69 A-V:-3498.298 ct: -0.226   7/  7 ??% ??% ??,?% 0 0
A:   0.4 V:3498.73 A-V:-3498.310 ct: -0.231   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:3498.78 A-V:-3498.281 ct: -0.235   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:3498.82 A-V:-3498.273 ct: -0.239  10/ 10 ??% ??% ??,?% 0 0
A:   0.6 V:3498.86 A-V:-3498.275 ct: -0.243  11/ 11 103% 30% 253.1% 0 0
A:   0.6 V:3498.90 A-V:-3498.297 ct: -0.247  12/ 12 95% 28% 235.1% 0 0
A:   0.7 V:3498.94 A-V:-3498.289 ct: -0.251  13/ 13 89% 26% 218.5% 0 0
A:   0.7 V:3498.98 A-V:-3498.312 ct: -0.256  14/ 14 83% 25% 204.1% 0 0
A:   0.8 V:3499.03 A-V:-3498.272 ct: -0.260  15/ 15 78% 24% 193.2% 0 0
A:   0.8 V:3499.07 A-V:-3498.254 ct: -0.264  16/ 16 74% 23% 187.0% 0 0
A:   0.9 V:3499.11 A-V:-3498.256 ct: -0.268  17/ 17 70% 22% 180.1% 0 0
A:   0.9 V:3499.15 A-V:-3498.267 ct: -0.272  18/ 18 67% 21% 171.1% 0 0
A:   0.9 V:3499.19 A-V:-3498.259 ct: -0.276  19/ 19 64% 20% 163.4% 0 0
A:   1.0 V:3499.23 A-V:-3498.271 ct: -0.281  20/ 20 61% 19% 155.6% 0 0
A:   1.0 V:3499.28 A-V:-3498.242 ct: -0.285  21/ 21 58% 19% 151.3% 0 0
A:   1.1 V:3499.32 A-V:-3498.234 ct: -0.289  22/ 22 56% 18% 146.8% 0 0
A:   1.1 V:3499.36 A-V:-3498.236 ct: -0.293  23/ 23 54% 17% 140.9% 0 0
A:   1.2 V:3499.40 A-V:-3498.238 ct: -0.297  24/ 24 52% 17% 135.5% 0 0
A:   1.2 V:3499.44 A-V:-3498.239 ct: -0.301  25/ 25 51% 16% 130.5% 0 0
A:   1.3 V:3499.49 A-V:-3498.231 ct: -0.306  26/ 26 49% 16% 126.9% 0 0
A:   1.3 V:  0.25 A-V:  1.073 ct: -0.301  27/ 27 48% 15% 124.5% 0 0
A:   1.4 V:  0.29 A-V:  1.061 ct: -0.297  28/ 28 46% 15% 122.3% 0 0

straight svn:

A:3498.9 V:3498.9 A-V: -0.007 ct: -0.244  72/ 69 17%  5% 28.6% 0 0
A:3499.0 V:3498.9 A-V:  0.015 ct: -0.242  73/ 70 17%  5% 28.2% 0 0
A:3498.9 V:3499.0 A-V: -0.037 ct: -0.246  74/ 71 17%  5% 27.8% 0 0
A:3499.0 V:3499.0 A-V: -0.036 ct: -0.250  75/ 72 17%  5% 27.4% 0 0
A:3499.3 V:   0.0 A-V:3499.299 ct: -0.250   0/  0 ??% ??% ??,?% 0 0
A:   0.1 V:   0.0 A-V:  0.115 ct: -0.245   0/  0 ??% ??% ??,?% 0 0
A:   0.2 V:   0.0 A-V:  0.138 ct: -0.241   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:   0.1 A-V:  0.107 ct: -0.237   2/  2 ??% ??% ??,?% 0 0
A:   0.2 V:   0.1 A-V:  0.118 ct: -0.233   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:   0.2 A-V:  0.119 ct: -0.229   4/  4 ??% ??% ??,?% 0 0
  no resets, even with "his precise seeking patch" applied
  very precise A/V as well...hmm...

A:3498.3 V:3498.32 A-V: -0.050 ct: -0.250  58/ 55  8%  1% 36.5% 0 0
A:3498.3 V:3498.36 A-V: -0.041 ct: -0.254  59/ 56  8%  1% 35.9% 0 0
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2
libdvdnav: chapter NOT FOUND!
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2
libdvdnav: chapter NOT FOUND!
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.250   0/  0 ??% ??% ??,?% 0 0
A:  -0.6 V:  0.04 A-V: -0.628 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:  -0.5 V:  0.04 A-V: -0.498 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:  -0.3 V:  0.04 A-V: -0.378 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:  -0.2 V:  0.04 A-V: -0.248 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:  0.04 A-V: -0.150 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.062 ct: -0.250   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.100 ct: -0.246   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.141 ct: -0.242   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:  0.13 A-V:  0.129 ct: -0.237   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.097 ct: -0.233   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:  0.21 A-V:  0.096 ct: -0.229   5/  5 ??% ??% ??,?% 0 0
A:   0.4 V:  0.25 A-V:  0.114 ct: -0.225   6/  6 ??% ??% ??,?% 0 0
A:   0.4 V:3498.69 A-V:-3498.298 ct: -0.229   7/  7 ??% ??% ??,?% 0 0
A:   0.4 V:3498.73 A-V:-3498.320 ct: -0.233   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:3498.78 A-V:-3498.282 ct: -0.237   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:3498.82 A-V:-3498.283 ct: -0.242  10/ 10 ??% ??% ??,?% 0 0
A:   0.6 V:3498.86 A-V:-3498.295 ct: -0.246  11/ 11 46%  5% 260.9% 0 0
A:   0.6 V:3498.90 A-V:-3498.277 ct: -0.250  12/ 12 43%  5% 242.3% 0 0
A:   0.7 V:3498.94 A-V:-3498.289 ct: -0.254  13/ 13 41%  5% 225.2% 0 0
A:   0.7 V:3498.98 A-V:-3498.290 ct: -0.258  14/ 14 38%  4% 210.2% 0 0
A:   0.8 V:3499.03 A-V:-3498.272 ct: -0.263  15/ 15 36%  4% 199.0% 0 0
A:   0.8 V:3499.07 A-V:-3498.254 ct: -0.267  16/ 16 35%  4% 192.5% 0 0
A:   0.9 V:3499.11 A-V:-3498.255 ct: -0.271  17/ 17 33%  3% 185.0% 0 0
A:   0.9 V:3499.15 A-V:-3498.267 ct: -0.275  18/ 18 32%  3% 175.5% 0 0
A:   0.9 V:3499.19 A-V:-3498.259 ct: -0.279  19/ 19 31%  3% 167.7% 0 0
A:   0.9 V:3499.23 A-V:-3498.292 ct: -0.283  20/ 20 29%  3% 161.4% 0 0
A:   1.0 V:3499.28 A-V:-3498.252 ct: -0.288  21/ 21 28%  3% 155.4% 0 0
A:   1.1 V:3499.32 A-V:-3498.244 ct: -0.292  22/ 22 27%  3% 150.0% 0 0
A:   1.1 V:3499.36 A-V:-3498.256 ct: -0.296  23/ 23 26%  2% 144.0% 0 0
A:   1.2 V:3499.40 A-V:-3498.247 ct: -0.300  24/ 24 25%  2% 138.3% 0 0
A:   1.2 V:3499.44 A-V:-3498.249 ct: -0.304  25/ 25 25%  2% 133.2% 0 0
A:   1.3 V:3499.48 A-V:-3498.231 ct: -0.308  26/ 26 24%  2% 129.4% 0 0
A:   1.3 V:  0.25 A-V:  1.011 ct: -0.304  27/ 27 23%  2% 125.8% 0 0
A:   1.4 V:  0.29 A-V:  1.061 ct: -0.300  28/ 28 23%  2% 124.6% 0 0
A:   1.4 V:  0.33 A-V:  1.060 ct: -0.296  29/ 29 22%  2% 121.7% 0 0
  even with direct3d/directx
  behold, I tell you a mystery

old gcc, svn but with "just" his seeking patch applied/used:

A:3498.9 V:3499.0 A-V: -0.048 ct: -0.257 122/119 13%  5% 28.2% 0 0
A:3499.0 V:3499.0 A-V: -0.047 ct: -0.261 123/120 13%  5% 28.0% 0 0 # note lack of "using new"
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2
libdvdnav: chapter NOT FOUND!
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2
libdvdnav: chapter NOT FOUND!
A:3499.3 V:   0.0 A-V:3499.299 ct: -0.261   0/  0 ??% ??% ??,?% 0 0
A:   0.1 V:   0.0 A-V:  0.094 ct: -0.257   0/  0 ??% ??% ??,?% 0 0
A:   0.2 V:   0.0 A-V:  0.138 ct: -0.253   1/  1 ??% ??% ??,?% 0 0


ooh the various mplayer's have *different* looking splits.

Why is mine different than trunk, with the same gcc <sigh>.

Maybe mine is older svn version?
  mine:  SVN-r34269-4.5.1
  svn_upstreamer:  SVN-r34341-4.5.1
  
  that cannot matter though LOL
  
ooh once got the "freaky bad" with the new SVN

now I consistently get it:

A:3498.3 V:3498.28 A-V: -0.008 ct: -0.219  93/ 90 14%  6% 34.7% 0 0
A:3498.3 V:3498.32 A-V: -0.031 ct: -0.222  94/ 91 14%  6% 34.4% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.218   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:  0.04 A-V: -0.728 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:  -0.6 V:  0.04 A-V: -0.608 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:  -0.4 V:  0.04 A-V: -0.468 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:  -0.3 V:  0.04 A-V: -0.298 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:  0.04 A-V: -0.128 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.032 ct: -0.218   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.04 A-V:  0.132 ct: -0.214   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.141 ct: -0.210   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:  0.13 A-V:  0.129 ct: -0.206   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.097 ct: -0.202   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:  0.21 A-V:  0.106 ct: -0.197   5/  5 ??% ??% ??,?% 0 0
A:   0.4 V:  0.25 A-V:  0.114 ct: -0.193   6/  6 ??% ??% ??,?% 0 0
A:   0.4 V:  0.29 A-V:  0.102 ct: -0.189   7/  7 ??% ??% ??,?% 0 0
A:   0.4 V:3498.69 A-V:-3498.278 ct: -0.193   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:3498.73 A-V:-3498.260 ct: -0.197   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:3498.78 A-V:-3498.251 ct: -0.202  10/ 10 ??% ??% ??,?% 0 0
A:   0.6 V:3498.82 A-V:-3498.263 ct: -0.206  11/ 11 116% 52% 351.2% 0 0
A:   0.6 V:3498.86 A-V:-3498.245 ct: -0.210  12/ 12 107% 48% 328.1% 0 0
A:   0.6 V:3498.90 A-V:-3498.257 ct: -0.214  13/ 13 100% 45% 304.8% 0 0
A:   0.7 V:3498.94 A-V:-3498.249 ct: -0.218  14/ 14 94% 42% 284.5% 0 0
A:   0.7 V:3498.98 A-V:-3498.240 ct: -0.222  15/ 15 88% 40% 268.5% 0 0
A:   0.8 V:3499.03 A-V:-3498.232 ct: -0.227  16/ 16 83% 38% 256.1% 0 0
A:   0.8 V:3499.07 A-V:-3498.224 ct: -0.231  17/ 17 79% 36% 245.2% 0 0
A:   0.9 V:3499.11 A-V:-3498.226 ct: -0.235  18/ 18 75% 34% 234.0% 0 0
A:   0.9 V:3499.15 A-V:-3498.227 ct: -0.239  19/ 19 72% 32% 223.6% 0 0
A:   1.0 V:3499.19 A-V:-3498.239 ct: -0.243  20/ 20 69% 31% 212.9% 0 0
A:   1.0 V:3499.23 A-V:-3498.242 ct: -0.248  21/ 21 66% 30% 204.7% 0 0
A:   1.1 V:3499.28 A-V:-3498.192 ct: -0.252  22/ 22 63% 28% 198.5% 0 0
A:   1.1 V:3499.32 A-V:-3498.204 ct: -0.256  23/ 23 61% 27% 190.4% 0 0
A:   1.2 V:3499.36 A-V:-3498.206 ct: -0.260  24/ 24 59% 26% 183.0% 0 0
A:   1.2 V:3499.40 A-V:-3498.198 ct: -0.264  25/ 25 57% 26% 176.6% 0 0
A:   1.2 V:3499.44 A-V:-3498.199 ct: -0.268  26/ 26 55% 25% 171.1% 0 0
A:   1.3 V:3499.49 A-V:-3498.213 ct: -0.273  27/ 27 53% 24% 166.0% 0 0
A:   1.4 V:  0.25 A-V:  1.103 ct: -0.268  28/ 28 52% 23% 163.5% 0 0
A:   1.4 V:  0.29 A-V:  1.091 ct: -0.264  29/ 29 50% 23% 158.7% 0 0


use or non use of "enable precise seeking" patch doesn't seem to change it.
broken cat maybe?
  fixed cat doesn't fix "mplayer_me" from doing it though

svn:
A:   0.5 V:   0.5 A-V:  0.062 ct: -0.199  11/ 11 153% 68% 347.1% 0 0
A:   0.6 V:   0.3 A-V:  0.334 ct: -0.195  12/ 12 141% 63% 320.4% 0 0


A:   0.5 V:   0.4 A-V:  0.050 ct: -0.157  10/ 10 ??% ??% ??,?% 1 0
A:   0.5 V:   0.3 A-V:  0.291 ct: -0.153  11/ 11 220% 130% 348.9% 1 0 # 0.4 to 0.3 this time?
A:   0.6 V:   0.3 A-V:  0.292 ct: -0.149  12/ 12 204% 120% 326.8% 1 0
A:   0.6 V:   0.3 A-V:  0.293 ct: -0.145  13/ 13 190% 112% 306.6% 1 0
A:   0.7 V:   0.4 A-V:  0.294 ct: -0.141  14/ 14 178% 105% 290.3% 1 0 
A:   0.7 V:   0.4 A-V:  0.273 ct: -0.136  15/ 15 167% 99% 273.9% 1 0
A:   0.7 V:   0.5 A-V:  0.253 ct: -0.132  16/ 16 158% 93% 258.8% 1 0


A:   0.4 V:   0.3 A-V:  0.102 ct: -0.177   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:   0.4 A-V:  0.081 ct: -0.173   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:   0.4 A-V:  0.104 ct: -0.169  10/ 10 ??% ??% ??,?% 0 0 # end of 0.4
A:   0.6 V:   0.3 A-V:  0.312 ct: -0.165  11/ 11 118% 57% 143.9% 0 0

This one (phreaky) always goes up:

A:   1.4 V:3499.49 A-V:-3498.041 ct: -0.221  31/ 31 59% 94% 170.2% 0 0
A:   1.5 V:  0.25 A-V:  1.253 ct: -0.217  32/ 32 58% 91% 166.3% 0 0
A:   1.5 V:  0.29 A-V:  1.241 ct: -0.213  33/ 33 56% 88% 162.3% 0 0

and now we're back to phreaky with svn:

A:3498.89 V:3498.82 A-V:  0.076 ct: -0.185 106/103 17% 28% 34.0% 0 0
A:3498.96 V:3498.86 A-V:  0.099 ct: -0.183 107/104 17% 29% 33.7% 0 0
A:3498.95 V:3498.90 A-V:  0.046 ct: -0.187 108/105 17% 29% 33.5% 0 0
A:3498.97 V:3498.94 A-V:  0.026 ct: -0.189 109/106 17% 29% 33.1% 0 0
A:3499.30 V:  0.00 A-V:3499.299 ct: -0.189   0/  0 ??% ??% ??,?% 0 0
A:  0.09 V:  0.00 A-V:  0.094 ct: -0.185   0/  0 ??% ??% ??,?% 0 0
A:  0.18 V:  0.04 A-V:  0.138 ct: -0.181   1/  1 ??% ??% ??,?% 0 0
A:  0.19 V:  0.08 A-V:  0.107 ct: -0.177   2/  2 ??% ??% ??,?% 0 0
A:  0.24 V:  0.13 A-V:  0.118 ct: -0.173   3/  3 ??% ??% ??,?% 0 0
A:  0.31 V:  0.17 A-V:  0.141 ct: -0.169   4/  4 ??% ??% ??,?% 0 0
A:  0.35 V:3499.19 A-V:-3498.843 ct: -0.173   5/  5 ??% ??% ??,?% 0 0
A:  0.39 V:3499.23 A-V:-3498.842 ct: -0.177   6/  6 ??% ??% ??,?% 0 0
A:  0.48 V:3499.28 A-V:-3498.798 ct: -0.181   7/  7 ??% ??% ??,?% 0 0
A:  0.47 V:3499.32 A-V:-3498.851 ct: -0.185   8/  8 ??% ??% ??,?% 0 0
A:  0.52 V:3499.36 A-V:-3498.839 ct: -0.189   9/  9 ??% ??% ??,?% 0 0
A:  0.54 V:3499.40 A-V:-3498.860 ct: -0.194  10/ 10 ??% ??% ??,?% 0 0
A:  0.61 V:3499.44 A-V:-3498.837 ct: -0.198  11/ 11 162% 277% 359.8% 0 0
A:  0.67 V:3499.49 A-V:-3498.815 ct: -0.202  12/ 12 152% 257% 342.7% 0 0
A:  0.71 V:  0.25 A-V:  0.462 ct: -0.198  13/ 13 141% 239% 323.7% 0 0
A:  0.76 V:  0.29 A-V:  0.463 ct: -0.194  14/ 14 132% 228% 303.4% 0 0
A:  0.74 V:  0.33 A-V:  0.410 ct: -0.189  15/ 15 125% 214% 288.6% 0 0
A:  0.79 V:  0.38 A-V:  0.411 ct: -0.185  16/ 16 118% 206% 271.6% 0 0


A:  0.54 V:  0.46 A-V:  0.083 ct: -0.149  11/ 11 184% 219% 366.0% 1 0
A:  0.61 V:  0.25 A-V:  0.355 ct: -0.145  12/ 12 170% 203% 342.9% 1 0


A:  0.49 V:  0.42 A-V:  0.072 ct: -0.167  10/ 10 ??% ??% ??,?% 0 0 # odd...
A:  0.54 V:  0.25 A-V:  0.291 ct: -0.163  11/ 11 183% 116% 319.5% 0 0


A:  0.49 V:  0.42 A-V:  0.072 ct: -0.160  10/ 10 ??% ??% ??,?% 0 0
A:  0.54 V:  0.25 A-V:  0.291 ct: -0.156  11/ 11 180% 113% 388.2% 0 0

so should add 0.42-0.25 = 0.17

minc, interesting:


A:1547.22 V:1547.21 A-V:  0.015 ct: -0.201 220/220  9%  8% 30.2% 0 0
A:1547.25 V:1547.25 A-V: -0.005 ct: -0.202 221/221  9%  8% 30.1% 0 0
A:1547.29 V:1547.29 A-V: -0.004 ct: -0.202 222/222  9%  8% 30.0% 0 0
A:1547.62 V:  0.00 A-V:1547.619 ct: -0.202   0/  0 ??% ??% ??,?% 0 0
A:  0.12 V:  0.00 A-V:  0.115 ct: -0.198   0/  0 ??% ??% ??,?% 0 0
A:  0.16 V:  0.04 A-V:  0.116 ct: -0.194   1/  1 ??% ??% ??,?% 0 0
A:  0.22 V:  0.08 A-V:  0.139 ct: -0.190   2/  2 ??% ??% ??,?% 0 0
A:  0.21 V:  0.13 A-V:  0.086 ct: -0.186   3/  3 ??% ??% ??,?% 0 0
A:  0.29 V:  0.17 A-V:  0.119 ct: -0.182   4/  4 ??% ??% ??,?% 0 0
A:  0.33 V:  0.21 A-V:  0.120 ct: -0.177   5/  5 ??% ??% ??,?% 0 0
A:  0.37 V:  0.25 A-V:  0.121 ct: -0.173   6/  6 ??% ??% ??,?% 0 0
A:  0.41 V:  0.29 A-V:  0.122 ct: -0.169   7/  7 ??% ??% ??,?% 0 0
A:  0.44 V:  0.33 A-V:  0.102 ct: -0.165   8/  8 ??% ??% ??,?% 0 0
A:  0.48 V:1547.71 A-V:-1547.232 ct: -0.169   9/  9 ??% ??% ??,?% 0 0
A:  0.50 V:1547.75 A-V:-1547.252 ct: -0.173  10/ 10 ??% ??% ??,?% 0 0
A:  0.53 V:1547.79 A-V:-1547.262 ct: -0.177  11/ 11 185% 171% 609.4% 0 0
A:  0.63 V:  0.28 A-V:  0.347 ct: -0.173  12/ 12 171% 159% 574.1% 0 0 # note down to .28 from 0.33
A:  0.67 V:  0.32 A-V:  0.348 ct: -0.169  13/ 13 159% 148% 536.9% 0 0
A:  0.69 V:  0.36 A-V:  0.328 ct: -0.165  14/ 14 149% 138% 503.2% 0 0

it "maybe" the same thing...FWIW.
  does seem to be at a chapter break or something, somehow.

so I think...


A:1488.34 V:1488.35 A-V: -0.010 ct: -0.256 111/111  7%  5% 29.3% 0 0
A:1488.40 V:1488.39 A-V:  0.012 ct: -0.255 112/112  7%  5% 29.1% 0 0
A:1488.74 V:  0.00 A-V:1488.745 ct: -0.255   0/  0 ??% ??% ??,?% 0 0
A:  0.12 V:  0.00 A-V:  0.124 ct: -0.251   0/  0 ??% ??% ??,?% 0 0
A:  0.19 V:  0.04 A-V:  0.147 ct: -0.247   1/  1 ??% ??% ??,?% 0 0
A:  0.23 V:  0.08 A-V:  0.148 ct: -0.243   2/  2 ??% ??% ??,?% 0 0
A:  0.27 V:  0.13 A-V:  0.149 ct: -0.239   3/  3 ??% ??% ??,?% 0 0
A:  0.32 V:  0.17 A-V:  0.150 ct: -0.234   4/  4 ??% ??% ??,?% 0 0
A:  0.36 V:  0.21 A-V:  0.151 ct: -0.230   5/  5 ??% ??% ??,?% 0 0
A:  0.38 V:  0.25 A-V:  0.130 ct: -0.226   6/  6 ??% ??% ??,?% 0 0
A:  0.40 V:  0.29 A-V:  0.110 ct: -0.222   7/  7 ??% ??% ??,?% 0 0
A:  0.47 V:1488.77 A-V:-1488.301 ct: -0.226   8/  8 ??% ??% ??,?% 0 0
A:  0.51 V:1488.81 A-V:-1488.300 ct: -0.230   9/  9 ??% ??% ??,?% 0 0
A:  0.53 V:1488.85 A-V:-1488.321 ct: -0.234  10/ 10 ??% ??% ??,?% 0 0
A:  0.56 V:1488.90 A-V:-1488.339 ct: -0.239  11/ 11 72% 55% 304.3% 0 0
A:  0.66 V:  0.29 A-V:  0.366 ct: -0.234  12/ 12 67% 52% 281.6% 0 0
A:  0.68 V:  0.33 A-V:  0.345 ct: -0.230  13/ 13 63% 48% 263.9% 0 0

== @ -ss 3590 NAV goes down?==

last NAV packet was 3590.966667, mpeg at 0.066733 after -> 29.97 3594.557617
new NAV packet! 3594.557617 [adjusted] at 0.066733 adding 0.000000 to 3594.557617
final: 3594.557617
last NAV packet was 3590.966553, mpeg at 0.100100 after -> 29.97 3594.557617
adding difference 0.033367 adding 0.000000 to 3594.591064
final: 3594.591064


last NAV packet was 3590.966553, mpeg at 95.663109 after -> 29.97 3594.557617
not adding odd diff1? 95.596375adding 0.000000 to 3594.557617
final: 3594.557617
  3590 is like 95 *past* the split @ 3499



7.2.2.2. Telecined
I think "from TV" DVD's are telecined, and movies aren't, so you don't need softskip for the movie DVD's I guess.

== nav packets on -c-=

last NAV packet was 0.000000, mpeg at 0.000000 after -> 29.97 0.000000 # audio packets?


last NAV packet was 1.600000, mpeg at 2.574586 after -> 29.97 1.601600
adding difference 0.759091 adding 0.200000 to 2.360691
final: 2.560691
using mpeg ts appears larger, which if true is definitely better 2.574586 > 2.560691 - 1.0
last NAV packet was 2.400000, mpeg at 2.616294 after -> 29.97 2.402400

NAV packet after 0.8! whoa!
then
last NAV packet was 2.400000, mpeg at 2.983327 after -> 29.97 2.402400
adding difference 0.367033 adding 0.200000 to 2.769433
final: 2.969433
using mpeg ts appears larger, which if true is definitely better 2.983327 > 2.969433 - 1.0
last NAV packet was 2.833333, mpeg at 3.025035 after -> 29.97 2.836167
NAV packet of 0.43 which is *not* 0.5
then 3.6
now 0.8'ish again. fascinating.

many are 0.40 

last NAV packet was 0.400000, mpeg at 0.614300
  so the NAV packets think it starts at...

conc: looks like tmap "typically" tends to go forward [?] from somewhere

== seeking bunny ==

when it goes to a new VOB it must accidentally reset somehow, thus thinking it's at 500'ish

mplayer.exe -framedrop -mc 1 -autosync 30 -nosub -noautosub -forcedsubsonly -sid 1000 -alang en -slang en -msglevel identify=4 -mouse-movements -sws 9 -ssf ls=75.0 -ssf cs=7.0 -lavdopts threads=2 -font c:/dev/ruby/sensible-cinema/vendor/subfont.ttf -volume 100 -vo direct3d  -input conf="/dev/ruby/sensible-cinema/mplayer_input_conf"  -osdlevel 2 -osd-fractions 1  "dvdnav://2/H:" -osd-verbose -ss 298


A: 299.7 V:299.72 A-V:  0.017 ct: -0.096  20/ 17 47% 61%  5.7% 0 0
last NAV packet was 299.000000, mpeg at 299.766144 after -> 29.97 299.299011
adding difference 0.229462 adding 0.000000 to 299.528473
final: 299.528473
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 20 0
libdvdnav: chapter NOT FOUND!
libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 2
libdvdnav: chapter NOT FOUND!

DVDNAV_TITLE_IS_MOVIE
[ac3 @ 00c3fbc0]incomplete frame
weird fella suddenly we're not a DVD? mpeg at 0.000000 adding 0.000000 to 0.000000
final: 0.000000
A: 300.5 V:  0.00 A-V:300.470 ct:  0.905   0/  0 ??% ??% ??,?% 0 0
[ac3 @ 00c3fbc0]frame sync error

last NAV packet was 299.000000, mpeg at 0.041708 after -> 29.97 299.299011
not adding negative diff -299.494965adding 0.000000 to 299.299011
final: 299.299011
A: 299.5 V:  0.04 A-V:299.438 ct:  1.905   1/  1 ??% ??% ??,?% 1 0
last NAV packet was 299.000000, mpeg at 0.083417 after -> 29.97 299.299011
not adding negative diff -299.453278adding 0.000000 to 299.299011
final: 299.299011
A: 298.6 V:  0.08 A-V:298.470 ct:  2.905   2/  2 ??% ??% ??,?% 2 0
last NAV packet was 299.000000, mpeg at 0.125125 after -> 29.97 299.299011
not adding negative diff -299.411560adding 0.000000 to 299.299011
final: 299.299011
A: 297.6 V:  0.13 A-V:297.470 ct:  3.905   3/  3 ??% ??% ??,?% 3 0
last NAV packet was 299.000000, mpeg at 0.166833 after -> 29.97 299.299011
not adding negative diff -299.369843adding 0.000000 to 299.299011
final: 299.299011
A: 296.6 V:  0.17 A-V:296.470 ct:  4.905   4/  4 ??% ??% ??,?% 4 0
last NAV packet was 299.500000, mpeg at 0.208542 after -> 29.97 299.799500
new NAV packet! 299.799500 [adjusted] at 0.208542 adding 0.000000 to 299.799500
final: 299.799500
A: 295.7 V:  0.21 A-V:295.470 ct:  5.905   5/  5 ??% ??% ??,?% 5 0
last NAV packet was 299.500000, mpeg at 0.250250 after -> 29.97 299.799500
adding difference 0.041708 adding 0.000000 to 299.841217
final: 299.841217
A: 294.7 V:  0.25 A-V:294.470 ct:  6.905   6/  6 ??% ??% ??,?% 6 0
last NAV packet was 299.500000, mpeg at 300.099792 after -> 29.97 299.799500
adding difference 299.891266 adding 0.000000 to 599.690796
final: 599.690796

Freaky VOB interloper...

== sintel dvd menu highlight==
VLC "straight"
  red, grey, grey
MPC
  red, red, red
mplayer
  grey, grey, grey :)

VLC on files:
  red, grey, grye

VLC sans libyuv:
  same
VLC sans libyuvp DVD:
  good
VLC sans libyuvp files:
  good
VLC linux:
 red, grey, grye


it "should" be red, with small grey overlay around it, that's it.

== seeking forward or back, with new patch ==
final: 36.870166
A:  37.1 V: 37.10
we're about 0.3 off

35.5 36.0

we're seeking to 36...

real difference:
 36.000000, mpeg at 36.269568

dvd_start_offset" => "0.37",

mpeg stream seems to...lag behind DVDNAV seeks by a bit...at least one old frame is still there somehow...

stream_pts is "supposed" to be always from dvdnav_get_current_time
  which can't be anything but a NAV packet can it?  Maybe I was messing the numbers up...

    case STREAM_CTRL_GET_CURRENT_TIME:
    {
      double tm;
      tm = dvdnav_get_current_time(priv->dvdnav)/90000.0f;
      
last NAV packet was 35.500000, mpeg at 0.133467 after -> 29.97 35.535500
adding difference 0.066733 adding 0.000000 to 35.602234
final: 35.602234
A:  35.7 V:  0.13 A-V: 35.559 ct:  0.027   3/  3 ??% ??% ??,?% 0 0
. =====  PAUSE  =====
"accepting from console"

last NAV packet was 35.500000, mpeg at 35.902534

weird coordination there...

however, that was a "start at 35..."

33 => 33.5
  might not be the nav's fault though...


last NAV packet was 35.000000, mpeg at 35.268574
last NAV packet was 35.500000, mpeg at 35.769073
last NAV packet was 36.000000, mpeg at 36.269573

last NAV packet was 35.500000, mpeg at 0.133467 after -> 29.97 35.535500
adding difference 0.066733 adding 0.000000 to 35.602234
final: 35.602234
A:  35.7 V:  0.13 A-V: 35.559 ct:  0.027   3/  3 ??% ??% ??,?% 0 0
  =====  PAUSE  =====
last NAV packet was 35.500000, mpeg at 35.902534

weird.

first frame is "right place, wrong V: 0.13"
then like 5 audio packets...

last NAV packet was 36.000000, mpeg at 36.269573 (which is right...phew)

32.75 [2947500], 32.99 => 33.5
32.50,32.51,32.55,32.60,32.70,32.74 [2946600] => 33.0

55.75 => 56.5 [same pattern]

seek_to_sec

0 => 0
there *is* an initial NAV packet for zero...whoa!


last NAV packet was 0.000000, mpeg at 0.033367 after -> 29.97 0.000000
adding difference 0.033367 adding 0.000000 to 0.033367
final: 0.033367
last NAV packet was 0.000000, mpeg at 0.367033 (so still ends up being 0.20 almost exact? fascinating, may be more room for coord. in there...)
  so what I want is dvdcss'less "mpeg to NAV offset" based on first "real" NAV packet.
    (is it always 0.37-0.1 ?)
      "dvd_start_offset" => "0.37", # for title 2
  NAV packet was 0.500000, mpeg at 0.767433 => NAV packet was 0.400000, mpeg at 0.667433 # within 0.05 still...hmm...
    
    minc:
      last NAV packet was 0.000000, mpeg at 0.280633 after -> 29.97 0.000000
      0.400000, mpeg at 0.614300
      0.28-0.1 # actually kind'er close...0.21 to 0.18
    jonah:
      0.28
      0.400000, mpeg at 0.614300

seeking in minc
 32.74 => 32.533333
 33.0,33.1,33.2,33.25 => 33.033333
 33.26,33.3 => 33.533333
== precise skipping dvdnav patch/broken DVDNAV EDL ==

seems to be "more tight" even with gottmann DVD

my EDL output is still "temporarily messed" though...

just skipping "to 58" skips to 
A:  54.5 V:  54.6
which is supposed to skip, at 55, to 58.

So that explains that.


54.0 64.5 0 "the freezer/100% pauser"
skips @ 54 to "an attempted" 64.5
 at which point, it keeps repeating, trying to skip to 

mplayer -ss 64.5 actually goes to 58.4

wow that is bad LOL (and explains it too)

maybe seek_rel is saving me, and seeking +5 within the DVD's sphere?

accurate "edl seek to" clue:
libmpdemux\demux_mpg.c static void demux_seek_mpg(demuxer_t *demuxer, float rel_seek_secs,
                           float audio_delay, int flags)


appears that any "seek me forward 10s" that was 

pts = demuxer->stream_pts; // this is DVD accurate! suh-weet... and a double at that...

seems to (audio) work great now with both -c- and -minc-
  I guess video is just broken, but once the seek is in, and to use it, happiness. yipersz-zy-dipers.

== robust vlc ==
if I ever care...

ANS_length=6013.200000
Assertion failed: (vm->state).pgc->cell_playback[(vm->state).cellN - 1].block_mode != 0, file libdvdnav/vm/vm.c, line 1134
  may mean a scratched disk [?]
  may also mean that libdvdnav could do more to become more robust...
  same with mplayer.bat
  VLC "loops" backward with this one...hmm weird.
  actually, this might actually be a bug...
  
Tangled is a good test.
Also gottmann was the other.

== vlc slow ==
27/51 full screen, no interference.  Maybe a dropped frame once a second?
  *much* fewer "late picture skipped" messages...
27/100 with ffmpeg going...

with ffmpeg "at real low prio" it...actually seems to work about the same phew
  once a second'ish late picture skipped
== libdvdnav research ==

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-November/047218.html "dvd nav precise seeking" ?
  this was actually "stable seeking for dvd://" [NAV packets only, I think]
  kind of precursed the stuff I'm doing now...
  except it does have a stream_seek in there...
  
-mc 10 http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-April/079600.html for A/V offset
  though mine seems to be fine when seeking...
  
maybe the assert '0' thing is fixed already, now [mentioned that an update seemed to have done it...]?
  http://projects.archlinux.org/svntogit/packages.git/diff/?h=packages/libdvdnav

== does vobu restart ? ==

A:4104.1 V:4092.9 A-V: 11.242
 when played back at high speed, sans frame drop [does get out of whack]

vobu start time resets?

same before, and after reset:
  updating cell time 17754000
  vobu start time is 84970868
  A: 719.9 V:720.03 A-V: -0.105 ct: -0.163  19/ 19  5%  3% 25.3% 0 0
  only cell time reset, FWIW
  libdvdnav/dvdnav.c
    799:    printf("vobu start time is %d\n", &this->pci.pci_gi.vobu_s_ptm);

OSOH:
  mplayer dvdnav://1 -ss 4500
  
  A:4510.0 V:4510.20 A-V: -0.212 ct: -0.050  40/ 40 12% 10% 55.0% 12 0
  =====  PAUSE  =====
[mpeg2video @ 012537d0]ignoring SEQ_START_CODE after 100
[mpeg2video @ 012537d0]ignoring seq ext after 100
[mpeg2video @ 012537d0]ignoring GOP_START_CODE after 100
[mpeg2video @ 012537d0]ignoring pic after 100
[mpeg2video @ 012537d0]Missing picture start code, guessing missing values
A:4506.3 V:4506.28 A-V: -0.009 ct:  0.092   6/  6 ??% ??% ??,?% 1 0

the other is *right* on with the OSD. like perfeito :P


I guess I'd need to add "accurate where you are" to dvdnav, before being able to add "super accurate seek"...

"we're here, right where you paid me to bring you" is after cut
  VLC "normal" OS X skipped a tidge
  mplayer with cache did, and with nocache too, it seems like it has to flit through video to catch up with audio or some odd.

                    mpctx->time_frame += frame_time / playback_speed; // for nosound maybe esplain that weirdness. Very weird, as in whoa!
A:   2.6 V:  2.32 A-V:  0.237 ct:  0.084  64/ 64 19% 81%  4.9% 56 0
updating edl...
A:   2.6 V:  2.35 A-V:  0.225 ct:  0.084  65/ 65 19% 80%  4.8% 56 0
updating edl...
A:   2.6 V:  2.38 A-V:  0.213 ct:  0.084  66/ 66 19% 80%  4.7% 57 0
updating edl...

it seems to update the EDL with each and every frame...possibly just every video frame, but that's prolly ok :P

conc:     only .0005 off per 0.5seconds, so...straight add could be reasonable...yes!
    and more upstreamable :P

== OSOH highlight ==

VLC "straight" OSOH
  hint of yellow in there menu
  yellow subs [which is right I guess]
  
VLC "without dll"
 yellow menu, same size, hint of white [?] [might be ok]
 yellow subs, look pretty crisp and type-writer-sy [might be ok]

mplayer "thicker" white menu lines
  white subs, well positioned

powerdvd:
 yellow "blurrier" (same size? maybe tidge thicker)
 yellow, crisp subs

mplayer "patched" [both ways]
  same "thicker" white menu lines
  same white subs
  
yikes

linux [my build]:
 white subs
 white "thicker" fellas.  once it worked at all LOL, then the boxes were gone. [possible corrupt/interrupted DVDCSS?]

mplayer @home had yellow subs with some version, some vo

@works: mplayer_me>mplayer dvdnav:// -vo directx -mouse-movements still white on white

== subtitles sync'ing ==
flight:
 ok now david, if you can:
   srt:    32:44,943 = 1964.94
   actual: 34:26.37 = 2066.37


don't take any
 srt: 00:31:52,931 = 1912.93

srt start: 2:25,000 = 145.00
  actual start:  2:47.98 = 167.98
  
srt end: See you later: 01:22:02,271 = 4922.27
 actual end:                01:25:51.17  = 5151.17

so assuming an algorithm:
  take srt, add 22.98, then multiply srt value by real_sum/srt_sum = (5151.17-167.98)/(4922.27-145.00)

so (1964.94-145)*(5151.17-167.98)/(4922.27-145.00)+167.98 = 2066.37 = 0:34:26.37

was I accurate?

(1912.93-145)*(5151.17-167.98)/(4922.27-145.00)+167.98 =  2012.115 = 0:33:32.12
  actual 33:31.997 close enough.
  srt file sed: 0:33:32.12

my math seems ok...

he starts saying this particular one *before* the subtitles actually display...<sigh>.

seems right borderline...
once it totally got it...

actually he starts speaking at  V:2012.12
bad stuff at 2012.6

how can it have missed it sometimes? huh?

ok this one worked great. ok this is nuts LOL

A:2012.0 V:2011.99 A-V:  0.001 ct: -0.148 516/516  6%  7% 25.0% 0 0
  =====  PAUSE  =====
ID_PAUSED
last NAV packet was 2009.800049, mpeg at 2012.032471 after -> 29.97 2011.809814
adding difference 0.041748 adding 0.000000 to 2011.851563
final: 2011.851563
using mpeg ts appears larger, which if true is definitely better 2012.032471 > 2011.851563 - 1.0
A:2012.0 V:2012.03 A-V:  0.001 ct: -0.148 517/517  6%  7% 24.9% 0 0
  =====  PAUSE  =====
ID_PAUSED
last NAV packet was 2009.800049, mpeg at 2012.074219 after -> 29.97 2011.809814
adding difference 0.083496 adding 0.000000 to 2011.893311
final: 2011.893311
using mpeg ts appears larger, which if true is definitely better 2012.074219 > 2011.893311 - 1.0
A:2012.0 V:2012.07 A-V: -0.031 ct: -0.151 518/518  6%  7% 24.9% 0 0

the subtitle is actually at about 2012.03
he starts talking at 2012.07

But also there's .03 of audio out of sync-ness...which shouldn't matter I don't think...

2012.12 2013.47 1

somehow the mute appears to kick in a couple of frames too late...
  maybe one is right on, the next is *after* that frame is already done? [when else can they do it, though, I guess...]
   2012.115967
  
  
without frame drop et al, audio gets ahead

  it does *not* seem to be an A-V: getting ahead problem, those only get to like 0.008 [must just be buffers or something internal [?]]

seemed to work fine now that I drop frames...yipes!

== mplayer sox at muting DVD's with timestamp resets ==
  yep, I think it does <sigh>
  monster's inc. resets PTS with every chapter LOL

== mplayer muting probs ==

worked fine with muting here...with teeny screen video of monster's inc, work desktop, second 1530-1540, with mplayer_edl
 I think it might be fixed now, in general...maybe...

seemed to work fine with the same edl,  Sherpya-SVN-r33574-4.2.5 (older), on the work desktop, too...hmm...

  actually, smplayer seemed to do (muting) EDL's at 1hr just fine OSOH. and various mplayer's.  All spot on.

end of flight:

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:5159.9 V:5159.90 A-V:  0.025 ct:  2.274 7150/7150 189% 100% 608.6% 9958 0
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]
A:5163.9 V:5163.89 A-V: -0.003 ct:  2.339 7271/7268 187% 99% 601.0% 9984 0

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:5164.6 V:5164.56 A-V:  0.006 ct:  2.361 7287/7284 186% 99% 599.8% 9989 0

I think end...

== Sintel timing DVD versus file ==

  seemed to work, right on.  Could have had that 0.3s offset, hard to tell for sure :P
  I think we're good to go...sniff...maybe?

libdvdnav notes:

http://lists.freedesktop.org/archives/gstreamer-devel/2007-September/015724.html might have a patch of some sort
dvdinputstreamnavigator.cpp seems to handle discontinuities "right" or something like that...a gap?
  I bet they're a bit off, though...
  ok this is nuts
  also, I think/guess I need 3 variables, to track this "right" in mplayer...not sure about VLC...

  appears xbmc just tracks it as "nav wide"
    maybe I don't quite understand discontinuity...
    I...think they are unprecise. Oh man this is weird. oh man.
    so I guess their EDL's are based off of "DVD time"
      however one uses an EDL for theirs :P
    I don't really get it though, now do I? :P
    
I'm guessing mplayer "relative seeks" are totally bworked
  but they're not! they seek to past the break...but that's an absolute seek :P
  so they must be using NAV packets'ish for seeking, so relative seeks on long DVD's are probably bworked


 * DVDNAV_NAV_PACKET
 *
 * NAV packets are useful for various purposes. They define the button
 * highlight areas and VM commands of DVD menus, so they should in any
 * case be sent to the SPU decoder/overlaying engine for the menus to work.
 * NAV packets also provide a way to detect PTS discontinuities, because
 * they carry the start and end PTS values for the current VOBU.
 * (pci.vobu_s_ptm and pci.vobu_e_ptm) Whenever the start PTS of the
 * current NAV does not match the end PTS of the previous NAV, a PTS
 * discontinuity has occured.
 * NAV packets can also be used for time display, because they are
 * timestamped relatively to the current Cell.

Fascinating. I guess the "PTS values" are the mpeg PTS values themselves...fascinating.
  this seems to imply that XBMC's extra additions aren't necessary though, since they already use the NAV packets...hmm...
  
  XBMC seems to pass past the "discontinuity" all right though, timestamp wise...
  
  maybe this "isn't" a real discontinuity? whoa! maybe nav packets aren't timestamped relative to the current cell, in reality?
    Either way, I think you're stuck with the triple. Hmm...
    dvdnav doesn't seem to know about the pts at all, ever...it's gotta be local memory that's the only way DVD players must do it LOL
    NAV plus offset
    
== sintel cutting accuracy ==

  "dvd_start_offset" => "0.37", # for title 2
  Input #0, mpeg, from 'dvdout.mpg':
    Duration: 00:00:20.58, start: 0.300300, bitrate: 4305 kb/s
  
    seems that mplayer doesn't quite get the input cut right, I guess...
      not too far off I guess LOL 0.07 ... yeah we can live with that

seems that NAV 0.2 thing is *right on* for OSOH...
  final: 4847.344238
  using mpeg ts appears larger, which if true is definitely better 4847.539551 > 4847.344238 - 3
  last NAV packet was 4842.333496, mpeg at 4847.581055 after -> 29.97 4847.175781
  adding difference 0.209961 adding 0.000000 to 4847.385742
  final: 4847.385742
  using mpeg ts appears larger, which if true is definitely better 4847.581055 > 4847.385742 - 3
  A:4847.6 V:4847.58 A-V:  0.006 ct: -0.251  41/ 41  9%  4% 37.1% 0 0

random conclusions:

commercial" players, like windows media player, will "seek" based on 30 fps, even if
  the underlying is 29.97
	  	
however if you allow them to just continue playing, they use wall time, which is 29.97 fps
	  	
makemkv can give you streams that are up to like 2s out of whack with the DVD.  tsmuxer
	  	
seems to fix those though, if you unmux them.

== mplayer build speedz ==

office:

with "little/default console output", --enable-debug
  4% total cpu -> 23% cpu, with -march=runtime, work, stripped

with "--enable-debug, stripped, -march=generic" low/default console 
  6% -> 27% cpu

disable debug?

w, w/o tons of output, doze

sherpya's various, at home?

sherpya rtm:
 4% -> 13% (has no scrolling console output tho)

sherpya athlon:
 4% -> 11/13%
    
	
home,  -nocache dvdnav://1/f::

"rtm"  Sherpya-SVN-r34118-4.2.5
   34/74

 "p4"
    33/76
   
mplayer_big, no "scrolling screen"
  27/81
  
 mplayer_big, yes "scrolling screen"
  27/84
  
test/mplayer.exe (assume yasm), no scrolling output
    31/81
  yes scrolling
    25/83
	
mplayer_marchnative.exe crash :P

mplayer_no_output
 29/83

 
same thing, in cmd, with a-v after A:20, -nocache:

mplayer.bat:
 39/70 A-V:  -0.028
 
p4:
  no lag I guess
    maybe 34/73'ish
	
mplayer_big,  no output
 35/77, 37/71
    A: 0
	
 gets up to like A-V 1 at second 4, then fighting it down and up till 22, then 0, going full bore
  
  in console, starts at like A-V 2 and then loses...without going full bore.
    5.39,5.5 at 20
	full bore 7.7 at 20 6.9

	so it does/did make a difference, at least with console2
	  but not much...
	  
in cmd @20 0.2 at full bore, but hovering around 0 really. suh-weet.

mplayer_big, yes output

37/71 a-v 0.48, heading to zero. sweet.

mplayer_no_output
  37/73'ish (at times lower)

console2 maybe is doing something else bad? making output slower perhaps, in general?
  
  
mplayer.bat @20: 0.557
  quickly collapses to zero--but this is in console2!  

but in the same console2, my mplayer_no_output is losing ground! I haven't explained the discrepancy!
  
them: 21/27 to my 31/36 LODO huh?
  debug enabled builds perhaps?
  
-O2 -g with mingw raw but had march, so cannot test it...
-O4 -march=i486 -mtune=generic
    with --enable-iconv --enable-freetype --enable-static --enable-fontconfig --enable-runtime-cpudetection
    
34/77 comp.
30/85 with d3d
    
	mine 30/84'ish suh-weet
	
I do declare--it appears that the highlighting is "right" with  Sherpya-SVN-r34118-4.2.5 directx
  
and plus 10 with coiso...

unfortunately directx is the shtinky one for windows 7 aero...hmm...wonder why it's so much more efficient...oh well.

==  mplayers split it differently ==
  http://gk.lka.hu/2009/04/mingw-mplayer-guide mentions compiling ffmpeg separately...
      and says you need that mingw patch...


my "good" one, but without audio:                                  
  V:3499.36 5565/5565 75%  5%  0.0% 0 0                                          
  V:3499.40 5566/5566 75%  5%  0.0% 0 0                                          
  V:  0.04   0/  0 ??% ??% ??,?% 0 0                                             
  V:  0.08   1/  1 ??% ??% ??,?% 0 0                                             
  V:  0.25   2/  2 ??% ??% ??,?% 0 0                                             
  V:  0.29   3/  3 ??% ??% ??,?% 0 0           

at least it doesn't overrun "too" far LOL
   V:  1.21  30/ 30 38822% 10677%  0.0% 0 0                                       
  wonder if dumpstream also overruns...
  does switch though, so looks like mplayer won't save us there...
  last timestamp: 
    V:4364.61 13611/13611 71% 19%  0.0% 0 0                                        
  "good" one last timestamp is:
    A:4364.4 V:4364.3 A-V:  0.007 ct:  7.108 13613/13613 76% 38% 291.8% 30 0       
    A:4364.6 V:   0.0 A-V:4364.649 ct:  7.111   0/  0 ??% ??% ??,?% 30 0           
    A:   0.4 V:   0.0 A-V:  0.322 ct:  7.114   1/  1 ??% ??% ??,?% 30 0            
    it does have a 0.28 DVD offset...
  could I use benchmark for it somehow, though?  I guess not because it needs audio?
    nope I understand it not. Ahead by 0.3? huh?  Good thing this only I guess matters with mplayer whoa!

Ok now this is just plain nuts. Seriously what? LODO LOL

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
  can mean "we hit the trailer, or the preview section, in that DVD"

mplayer_svn_my_configure_devkit_patched:

A:3498.8 V:3498.8 A-V:  0.001 ct:  2.535 5561/5561 85% 45% 313.6% 30 0         
A:3498.9 V:3498.9 A-V:  0.024 ct:  2.538 5562/5562 85% 45% 313.6% 30 0         
A:3498.9 V:3498.9 A-V:  0.003 ct:  2.538 5563/5563 85% 45% 313.5% 30 0         
A:3498.9 V:3498.9 A-V:  0.004 ct:  2.538 5564/5564 85% 45% 313.5% 30 0         
A:3498.9 V:3499.0 A-V: -0.048 ct:  2.534 5565/5565 85% 45% 313.4% 30 0         
A:3499.0 V:3499.0 A-V: -0.026 ct:  2.532 5566/5566 85% 45% 313.4% 30 0         
A:3499.3 V:   0.0 A-V:3499.299 ct:  2.532   0/  0 ??% ??% ??,?% 30 0           
A:   0.1 V:   0.0 A-V:  0.094 ct:  2.536   0/  0 ??% ??% ??,?% 30 0            
A:   0.2 V:   0.0 A-V:  0.116 ct:  2.540   1/  1 ??% ??% ??,?% 30 0            
A:   0.2 V:   0.1 A-V:  0.117 ct:  2.544   2/  2 ??% ??% ??,?% 30 0            
A:   0.2 V:   0.1 A-V:  0.086 ct:  2.548   3/  3 ??% ??% ??,?% 30 0            

worked perfect

updated gcc with yasm, TRUNK:
   
A:3223.0 V:3223.0 A-V:  0.010 ct:  2.300 11234/11234 38% 32% 145.5% 37 0       
A:3223.4 V:   0.0 A-V:3223.363 ct:  2.300   0/  0 ??% ??% ??,?% 37 0           
A:   0.3 V:   0.0 A-V:  0.313 ct:  2.304   0/  0 ??% ??% ??,?% 37 0            
A:   0.4 V:   0.0 A-V:  0.335 ct:  2.308   1/  1 ??% ??% ??,?% 37 0        
  with the freaky "repeater-oo" right there...
  thus we surmise that updated gcc does not fix this freaky repeater-oo, nor does yasm, and neither fixes the seek failure.
    though maybe they might could still with a patch to mingw, or updated svn mplayer might could...
    
mplayer_34118_my_gcc_old_sherpya_diffs_some_patches mplayer_34118_sherpya_patches_my_gcc
A:3498.9 V:3498.9 A-V: -0.017 ct:  2.580 5564/5564 89% 77% 336.9% 71 0         
A:3499.0 V:3499.0 A-V:  0.026 ct:  2.582 5565/5565 89% 77% 336.8% 71 0         
A:3499.3 V:   0.0 A-V:3499.299 ct:  2.582   0/  0 ??% ??% ??,?% 71 0           
A:   0.1 V:   0.0 A-V:  0.094 ct:  2.587   0/  0 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.0 A-V:  0.116 ct:  2.591   1/  1 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.1 A-V:  0.117 ct:  2.595   2/  2 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.1 A-V:  0.108 ct:  2.599   3/  3 ??% ??% ??,?% 71 0            
A:   0.3 V:   0.2 A-V:  0.119 ct:  2.603   4/  4 ??% ??% ??,?% 71 0            
maybe a winner...hmm...
alloc-win maybe...

and the redo of the same:
no freaky looping...hmm...
A:3499.0 V:3499.0 A-V: -0.027 ct:  2.625 5565/5565 88% 68% 321.6% 31 0         
A:3499.0 V:3499.0 A-V: -0.026 ct:  2.622 5566/5566 88% 68% 321.5% 31 0         
A:3499.3 V:   0.0 A-V:3499.299 ct:  2.622   0/  0 ??% ??% ??,?% 31 0           
A:   0.1 V:   0.0 A-V:  0.094 ct:  2.627   0/  0 ??% ??% ??,?% 31 0            
A:   0.2 V:   0.0 A-V:  0.116 ct:  2.631   1/  1 ??% ??% ??,?% 31 0            
A:   0.2 V:   0.1 A-V:  0.117 ct:  2.635   2/  2 ??% ??% ??,?% 31 0            
A:   0.2 V:   0.1 A-V:  0.086 ct:  2.639   3/  3 ??% ??% ??,?% 31 0            
60s of repeated title 1 tho... LOL
  at least it's consistent :)

mplayer_34118_sherpya_patches_my_gcc_redo
  
A:3498.9 V:3498.9 A-V:  0.003 ct:  2.582 5563/5563 89% 77% 336.9% 71 0         
A:3498.9 V:3498.9 A-V: -0.017 ct:  2.580 5564/5564 89% 77% 336.9% 71 0         
A:3499.0 V:3499.0 A-V:  0.026 ct:  2.582 5565/5565 89% 77% 336.8% 71 0         
A:3499.3 V:   0.0 A-V:3499.299 ct:  2.582   0/  0 ??% ??% ??,?% 71 0           
A:   0.1 V:   0.0 A-V:  0.094 ct:  2.587   0/  0 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.0 A-V:  0.116 ct:  2.591   1/  1 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.1 A-V:  0.117 ct:  2.595   2/  2 ??% ??% ??,?% 71 0            
A:   0.2 V:   0.1 A-V:  0.108 ct:  2.599   3/  3 ??% ??% ??,?% 71 0            

Invalid seek to negative position ffffffff8000481c!
[ac3 @ 00bccba0]incomplete frame

[mpeg2video @ 00bccba0]invalid mb type in B Frame at 16 20

  it was a fluke! LOL ok now I'm still a bit confused...maybe it lacked a make clean in there?
  
updated gcc, still no yasm though...:
A:3223.0 V:3223.0 A-V:  0.009 ct:  2.216 11233/11233 39% 25% 146.0% 84 0       
A:3223.0 V:3223.0 A-V: -0.012 ct:  2.215 11234/11234 39% 25% 145.9% 84 0       
A:3223.1 V:3223.1 A-V: -0.022 ct:  2.213 11235/11235 39% 25% 145.9% 84 0       
A:3223.4 V:   0.0 A-V:3223.363 ct:  2.213   0/  0 ??% ??% ??,?% 84 0           
A:   0.3 V:   0.0 A-V:  0.313 ct:  2.217   0/  0 ??% ??% ??,?% 84 0            
A:   0.4 V:   0.0 A-V:  0.335 ct:  2.221   1/  1 ??% ??% ??,?% 84 0            
A:   0.4 V:   0.1 A-V:  0.336 ct:  2.225   2/  2 ??% ??% ??,?% 84 0            
A:   0.5 V:   0.1 A-V:  0.337 ct:  2.230   3/  3 ??% ??% ??,?% 84 0            
A:   0.5 V:   0.2 A-V:  0.338 ct:  2.234   4/  4 ??% ??% ??,?% 84 0            
A:   0.5 V:   0.2 A-V:  0.339 ct:  2.238   5/  5 ??% ??% ??,?% 84 0            
A:   0.6 V:3223.4 A-V:-3222.777 ct:  2.234   6/  6 ??% ??% ??,?% 84 0          
A:   0.6 V:3223.4 A-V:-3222.776 ct:  2.230   7/  7 ??% ??% ??,?% 84 0          
A:   0.7 V:3223.5 A-V:-3222.797 ct:  2.225   8/  8 ??% ??% ??,?% 84 0          
A:   0.7 V:3223.5 A-V:-3222.774 ct:  2.221   9/  9 ??% ??% ??,?% 84 0          
A:   0.8 V:3223.5 A-V:-3222.773 ct:  2.217  10/ 10 ??% ??% ??,?% 84 0          
A:   0.8 V:3223.6 A-V:-3222.773 ct:  2.213  11/ 11 36757% 23440% 136694.2% 84 
A:   0.8 V:3223.6 A-V:-3222.772 ct:  2.209  12/ 12 33930% 21638% 126179.6% 84 
[mpeg2video @ 00ca9420]concealing 450 DC, 450 AC, 450 MV errors
A:   0.9 V:3223.7 A-V:-3222.771 ct:  2.205  13/ 13 31507% 20092% 117166.8% 84 
A:   0.9 V:3223.7 A-V:-3222.770 ct:  2.200  14/ 14 29407% 18753% 109355.8% 84 
A:   1.0 V:   0.3 A-V:  0.715 ct:  2.205  15/ 15 27569% 17581% 102522.0% 84 0  
A:   1.0 V:   0.3 A-V:  0.694 ct:  2.209  16/ 16 25948% 16547% 96491.7% 84 0   
A:   1.1 V:   0.4 A-V:  0.717 ct:  2.213  17/ 17 24506% 15628% 91131.0% 84 0   
A:   1.1 V:   0.4 A-V:  0.696 ct:  2.217  18/ 18 23217% 14805% 86334.9% 84 0   

appears to be looping...

Invalid seek to negative position 1906c008000481c!
[ac3 @ 00ca9420]incomplete frame


linux, with yasm, no configure options, updated "lib"
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
interestingly, even if you pause, or seek, it still seems to display the same overlaps.
What could this ever mean?
  1b) it also freezes if you step frame through it LOL.

A:3498.7 V:3498.7 A-V:  0.003 ct:  4.084 5563/5563 141% 14% 25.1% 166 0 ^[[J
A:3498.7 V:3498.8 A-V: -0.029 ct:  4.081 5564/5564 141% 14% 25.1% 166 0 ^[[J
A:3498.8 V:3498.8 A-V: -0.027 ct:  4.078 5565/5565 141% 14% 25.1% 166 0 ^[[J
A:3499.3 V:   0.0 A-V:3499.321 ct:  4.082   0/  0 ??% ??% ??,?% 166 0 ^[[J
A:   0.2 V:   0.0 A-V:  0.139 ct:  4.087   1/  1 ??% ??% ??,?% 166 0 ^[[J
A:   0.2 V:   0.1 A-V:  0.131 ct:  4.091   2/  2 ??% ??% ??,?% 166 0 ^[[J
A:   0.3 V:   0.1 A-V:  0.125 ct:  4.095   3/  3 ??% ??% ??,?% 166 0 ^[[J
A:   0.3 V:   0.2 A-V:  0.122 ct:  4.099   4/  4 ??% ??% ??,?% 166 0 ^[[J
A:   0.3 V:   0.2 A-V:  0.085 ct:  4.103   5/  5 ??% ??% ??,?% 166 0 ^[[J
A:   0.3 V:   0.3 A-V:  0.080 ct:  4.107   6/  6 ??% ??% ??,?% 166 0 ^[[J
A:   0.4 V:   0.3 A-V:  0.109 ct:  4.112   7/  7 ??% ??% ??,?% 166 0 ^[[J
A:   0.4 V:3499.2 A-V:-3498.756 ct:  4.107   8/  8 ??% ??% ??,?% 166 0 ^[[J
A:   0.5 V:3499.2 A-V:-3498.752 ct:  4.103   9/  9 ??% ??% ??,?% 166 0 ^[[J
A:   0.5 V:3499.3 A-V:-3498.748 ct:  4.099  10/ 10 ??% ??% ??,?% 166 0 ^[[J
A:   0.6 V:3499.3 A-V:-3498.743 ct:  4.095  11/ 11 65755% 6508% 11638.3% 166 0 ^[[J
A:   0.6 V:3499.4 A-V:-3498.739 ct:  4.091  12/ 12 60697% 6008% 10743.1% 166 0 ^[[J
A:   0.7 V:3499.4 A-V:-3498.736 ct:  4.087  13/ 13 56362% 5578% 9975.8% 166 0 ^[[J
A:   0.7 V:3499.4 A-V:-3498.732 ct:  4.082  14/ 14 52606% 5207% 9310.7% 166 0 ^[[J
A:   0.8 V:3499.5 A-V:-3498.728 ct:  4.078  15/ 15 49318% 4881% 8729.0% 166 0 ^[[J
A:   0.8 V:   0.3 A-V:  0.552 ct:  4.082  16/ 16 46418% 4594% 8215.9% 166 0 ^[[J
A:   0.8 V:   0.3 A-V:  0.549 ct:  4.087  17/ 17 43840% 4339% 7759.4% 166 0 ^[[J
A:   0.9 V:   0.3 A-V:  0.545 ct:  4.091  18/ 18 41533% 4110% 7351.0% 166 0 ^[[J
A:   0.9 V:   0.4 A-V:  0.507 ct:  4.095  19/ 19 39456% 3905% 6983.6% 166 0 ^[[J
A:   0.9 V:   0.4 A-V:  0.503 ct:  4.099  20/ 20 37578% 3719% 6651.1% 166 0 ^[[J


mplayer_svn_sherpya_gcc_with_my_configure
A-V:  0.004 ct:  7.246 5565/5565 81%  7% 324.8% 113 0      
osd_level 1 osd_fractions 0 
A:3498.3 V:3498.36 A-V: -0.020 ct:  7.244 5566/5566 81%  7% 324.8% 113 0      
osd_level 1 osd_fractions 0 
A:3499.3 V:  0.00 A-V:3499.321 ct:  7.248   0/  0 ??% ??% ??,?% 113 0         
osd_level 1 osd_fractions 0 
A:   0.2 V:  0.04 A-V:  0.132 ct:  7.252   1/  1 ??% ??% ??,?% 113 0      
(with the freaky overlap, but not looping)
  => seems to imply that it's not a configure issue. Either a library or gcc issue? I'm using all the same ffmpeg's...
  => seems to imply that the stream seek is not an mplayer patch...

mplayer_svn_with_my_changes_only_sherpya_gcc_sherpya_configure_nocache_dvdnav
doesn't loop at least :P
  seems to imply the patches don't matter, and the ffmpeg doesn't amtter
osd_level 1 osd_fractions 0 
A:3498.3 V:3498.32 A-V: -0.028 ct:  7.237 5565/5565 78%  6% 325.5% 100 0      
osd_level 1 osd_fractions 0 
A:3498.3 V:3498.36 A-V: -0.030 ct:  7.234 5566/5566 78%  6% 325.4% 100 0      
osd_level 1 osd_fractions 0 
A:3499.3 V:  0.00 A-V:3499.321 ct:  7.238   0/  0 ??% ??% ??,?% 100 0         
osd_level 1 osd_fractions 0 
A:   0.2 V:  0.04 A-V:  0.132 ct:  7.242   1/  1 ??% ??% ??,?% 100 0           
...
V:3498.78
what if it includes a search or two?
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3498.3 V:3498.32 A-V: -0.034 ct: -0.277 655/655  5% 10% 23.3% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.273   0/  0 ??% ??% ??,?% 0 0
  =====  PAUSE  =====
note this one matches, with and without search...fascinating. with the *same* super updated ffmpeg version. oh man...
also this still shows that freaky "oh I'm back to 3498.78, or wait now I'm not" thing LOL
However, for now the automated way could (I must suppose) just use the old mplayer, or...

they may have used this ffmpeg:
 Download FFmpeg git rev N-32754-g936d4d4 - 09/21/2011
 use his build environment :P

me building using his complete build environment--diffs, gcc, mplayer version--it worked! phew
A:3498.3 V:3498.3 A-V:  0.004 ct:  7.253 5565/5565 80% 12% 347.1% 837 0        
A:3498.3 V:3498.4 A-V: -0.040 ct:  7.249 5566/5566 80% 12% 347.1% 837 0        
A:3499.3 V:   0.0 A-V:3499.321 ct:  7.253   0/  0 ??% ??% ??,?% 837 0          
A:   0.3 V:   0.0 A-V:  0.232 ct:  7.258   1/  1 ??% ??% ??,?% 838 0           
A:   0.3 V:   0.1 A-V:  0.251 ct:  7.262   2/  2 ??% ??% ??,?% 839 0           
A:   0.4 V:   0.1 A-V:  0.239 ct:  7.266   3/  3 ??% ??% ??,?% 839 0           
A:   0.4 V:   0.2 A-V:  0.197 ct:  7.270   4/  4 ??% ??% ??,?% 840 0           
A:   0.4 V:   0.2 A-V:  0.166 ct:  7.274   5/  5 ??% ??% ??,?% 840 0           
A:   0.4 V:   0.3 A-V:  0.124 ct:  7.278   6/  6 ??% ??% ??,?% 840 0           
A:   0.4 V:3498.7 A-V:-3498.288 ct:  7.274   7/  7 ??% ??% ??,?% 840 0         
A:   0.4 V:3498.7 A-V:-3498.322 ct:  7.270   8/  8 ??% ??% ??,?% 840 0         
A:   0.5 V:3498.8 A-V:-3498.281 ct:  7.266   9/  9 ??% ??% ??,?% 840 0         
A:   0.5 V:3498.8 A-V:-3498.273 ct:  7.262  10/ 10 ??% ??% ??,?% 840 0         
A:   0.6 V:3498.9 A-V:-3498.275 ct:  7.258  11/ 11 37484% 5782% 161090.3% 840 
A:   0.6 V:3498.9 A-V:-3498.277 ct:  7.253  12/ 12 34601% 5337% 148701.2% 840 
A:   0.7 V:3498.9 A-V:-3498.268 ct:  7.249  13/ 13 32130% 4956% 138081.2% 840 
A:   0.7 V:3499.0 A-V:-3498.260 ct:  7.245  14/ 14 29988% 4626% 128875.9% 840 
A:   0.8 V:3499.0 A-V:-3498.242 ct:  7.241  15/ 15 28114% 4337% 120823.3% 840 
A:   0.8 V:3499.1 A-V:-3498.243 ct:  7.237  16/ 16 26461% 4081% 113721.4% 840 
A:   0.9 V:3499.1 A-V:-3498.255 ct:  7.232  17/ 17 24991% 3855% 107405.4% 840 
A:   0.9 V:3499.2 A-V:-3498.247 ct:  7.228  18/ 18 23676% 3652% 101754.1% 840 
A:   1.0 V:3499.2 A-V:-3498.239 ct:  7.224  19/ 19 22493% 3469% 96666.8% 840 0
A:   1.0 V:3499.2 A-V:-3498.240 ct:  7.220  20/ 20 21422% 3304% 92064.5% 840 0
A:   1.0 V:3499.3 A-V:-3498.264 ct:  7.216  21/ 21 20448% 3154% 87881.2% 840 0
A:   1.1 V:3499.3 A-V:-3498.234 ct:  7.212  22/ 22 19559% 3017% 84063.0% 840 0
A:   1.1 V:3499.4 A-V:-3498.236 ct:  7.207  23/ 23 18745% 2891% 80560.5% 840 0
A:   1.2 V:3499.4 A-V:-3498.227 ct:  7.203  24/ 24 17995% 2775% 77338.3% 840 0
A:   1.2 V:3499.4 A-V:-3498.219 ct:  7.199  25/ 25 17303% 2669% 74364.1% 840 0
A:   1.3 V:3499.5 A-V:-3498.221 ct:  7.195  26/ 26 16663% 2570% 71611.1% 840 0
A:   1.3 V:   0.3 A-V:  1.031 ct:  7.199  27/ 27 16068% 2478% 69054.7% 840 0   
A:   1.4 V:   0.3 A-V:  1.061 ct:  7.203  28/ 28 15514% 2392% 66674.6% 840 0   
A:   1.4 V:   0.3 A-V:  1.060 ct:  7.207  29/ 29 14997% 2313% 64454.1% 840 0   
A:   1.4 V:   0.4 A-V:  1.048 ct:  7.212  30/ 30 14513% 2238% 62376.2% 840 0   
A:   1.5 V:   0.4 A-V:  1.046 ct:  7.216  31/ 31 14060% 2168% 60427.6% 840 0   
A:   1.5 V:   0.5 A-V:  1.044 ct:  7.220  32/ 32 13634% 2102% 58597.3% 840 0   
A:   1.5 V:   0.5 A-V:  1.043 ct:  7.224  33/ 33 13233% 2041% 56874.7% 840 0   
A:   1.6 V:   0.5 A-V:  1.031 ct:  7.228  34/ 34 12855% 1982% 55249.7% 840 0   
A:   1.6 V:   0.6 A-V:  0.997 ct:  7.232  35/ 35 12498% 1927% 53715.8% 840 0   
A:   1.7 V:   0.6 A-V:  1.028 ct:  7.237  36/ 36 12160% 1875% 52264.2% 840 0   
A:   1.7 V:   0.7 A-V:  1.026 ct:  7.241  37/ 37 11841% 1826% 50888.8% 840 0  
 => wouldn't this imply it's one of his patches?

his "get key" is benign

mine 34118 eternal loops, and has the freakiness LOL
  => maybe updated mplayer's don't have the freakiness?
A:3222.7 V:3222.8 A-V: -0.050 ct:  2.290 11228/11228 48% 44% 164.8% 3177 0     
A:3222.8 V:3222.8 A-V:  0.004 ct:  2.290 11229/11229 48% 44% 164.8% 3177 0     
A:3222.9 V:3222.9 A-V:  0.006 ct:  2.290 11230/11230 48% 44% 164.8% 3177 0     
A:3222.9 V:3222.9 A-V:  0.007 ct:  2.291 11231/11231 48% 44% 164.7% 3177 0     
A:3223.0 V:3222.9 A-V:  0.008 ct:  2.292 11232/11232 48% 44% 164.7% 3177 0     
A:3223.0 V:3223.0 A-V:  0.009 ct:  2.293 11233/11233 48% 44% 164.7% 3177 0     
A:3223.0 V:3223.0 A-V:  0.010 ct:  2.294 11234/11234 48% 44% 164.7% 3177 0     
A:3223.4 V:   0.0 A-V:3223.363 ct:  2.294   0/  0 ??% ??% ??,?% 3177 0         
A:   0.3 V:   0.0 A-V:  0.313 ct:  2.298   0/  0 ??% ??% ??,?% 3177 0          
A:   0.4 V:   0.0 A-V:  0.335 ct:  2.302   1/  1 ??% ??% ??,?% 3177 0          
A:   0.4 V:   0.1 A-V:  0.357 ct:  2.306   2/  2 ??% ??% ??,?% 3177 0          
A:   0.5 V:   0.1 A-V:  0.337 ct:  2.310   3/  3 ??% ??% ??,?% 3177 0          
A:   0.5 V:   0.2 A-V:  0.338 ct:  2.314   4/  4 ??% ??% ??,?% 3177 0          
A:   0.5 V:   0.2 A-V:  0.339 ct:  2.319   5/  5 ??% ??% ??,?% 3177 0          
A:   0.6 V:   0.3 A-V:  0.318 ct:  2.323   6/  6 ??% ??% ??,?% 3177 0          
A:   0.6 V:3223.4 A-V:-3222.735 ct:  2.319   7/  7 ??% ??% ??,?% 3177 0        
A:   0.7 V:3223.4 A-V:-3222.734 ct:  2.314   8/  8 ??% ??% ??,?% 3177 0        
A:   0.7 V:3223.5 A-V:-3222.754 ct:  2.310   9/  9 ??% ??% ??,?% 3177 0        
A:   0.7 V:3223.5 A-V:-3222.753 ct:  2.306  10/ 10 ??% ??% ??,?% 3177 0        
A:   0.8 V:3223.5 A-V:-3222.731 ct:  2.302  11/ 11 45410% 41285% 154257.2% 317
A:   0.8 V:3223.6 A-V:-3222.730 ct:  2.298  12/ 12 41917% 38110% 142391.8% 317
A:   0.9 V:3223.6 A-V:-3222.708 ct:  2.294  13/ 13 38923% 35388% 132221.0% 317
[mpeg2video @ 00bccba0]concealing 450 DC, 450 AC, 450 MV errors
A:   0.9 V:3223.7 A-V:-3222.728 ct:  2.289  14/ 14 36329% 33029% 123406.7% 317
A:   1.0 V:3223.7 A-V:-3222.706 ct:  2.285  15/ 15 34059% 30965% 115694.5% 317
A:   1.0 V:   0.3 A-V:  0.757 ct:  2.289  16/ 16 32056% 29144% 108889.5% 3177 
A:   1.1 V:   0.3 A-V:  0.758 ct:  2.294  17/ 17 30275% 27525% 102840.2% 3177 
A:   1.1 V:   0.4 A-V:  0.738 ct:  2.298  18/ 18 28682% 26077% 97427.8% 3177 0
A:   1.1 V:   0.4 A-V:  0.739 ct:  2.302  19/ 19 27248% 24773% 92556.6% 3177 0
A:   1.2 V:   0.4 A-V:  0.740 ct:  2.306  20/ 20 25950% 23593% 88149.1% 3177 0
A:   1.2 V:   0.5 A-V:  0.741 ct:  2.310  21/ 21 24771% 22521% 84142.7% 3177

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:   1.3 V:   0.5 A-V:  0.720 ct:  2.314  22/ 22 23694% 21542% 80484.4% 3177 0
A:   1.3 V:   0.6 A-V:  0.751 ct:  2.319  23/ 23 22707% 20645% 77131.0% 3177 0
A:   1.3 V:   0.6 A-V:  0.718 ct:  2.322  24/ 24 21974% 19979% 74643.3% 3177 0
A:   1.4 V:   0.6 A-V:  0.727 ct:  2.325  25/ 25 21288% 19355% 72310.7% 3177 0
A:   1.4 V:   0.7 A-V:  0.715 ct:  2.329  26/ 26 20643% 18768% 70119.8% 3177 0
A:   1.4 V:   0.7 A-V:  0.724 ct:  2.332  27/ 27 20036% 18216% 68058.1% 3177 0
A:   1.4 V:   0.7 A-V:  0.712 ct:  2.335  28/ 28 19464% 17696% 66113.5% 3177 0
A:   1.5 V:   0.8 A-V:  0.722 ct:  2.339  29/ 29 18923% 17205% 64277.2% 3177 0
A:   1.5 V:   0.7 A-V:  0.760 ct:  2.342  30/ 30 18412% 16740% 62540.1% 3177 0
A:   1.5 V:   0.8 A-V:  0.748 ct:  2.345  31/ 31 17928% 16299% 60894.4% 3177 0
A:   1.6 V:   0.8 A-V:  0.757 ct:  2.349  32/ 32 17468% 15882% 59333.0% 3177 0
A:   1.6 V:   0.8 A-V:  0.745 ct:  2.352  33/ 33 17032% 15485% 57849.9% 3177 0
A:   1.6 V:   0.9 A-V:  0.733 ct:  2.355  34/ 34 16616% 15107% 56438.9% 3177 0
A:   1.7 V:   0.9 A-V:  0.742 ct:  2.359  35/ 35 16221% 14748% 55095.2% 3177 0
A:   1.7 V:   0.9 A-V:  0.730 ct:  2.362  36/ 36 15844% 14405% 53814.0% 3177 0
A:   1.7 V:   1.0 A-V:  0.739 ct:  2.365  37/ 37 15483% 14077% 52591.0% 3177 0
A:   1.7 V:   1.0 A-V:  0.727 ct:  2.369  38/ 38 15140% 13765% 51422.3% 3177 0
A:   1.8 V:   1.1 A-V:  0.699 ct:  2.372  39/ 39 14811% 13466% 50304.5% 3177 0
A:   1.8 V:   1.1 A-V:  0.729 ct:  2.375  40/ 40 14343% 13040% 48716.0% 3177 0
A:   1.8 V:   1.1 A-V:  0.717 ct:  2.379  41/ 41 14047% 12772% 47711.7% 3177 0
A:   1.9 V:   1.1 A-V:  0.743 ct:  2.382  43/ 42 13764% 12514% 46747.8% 3177 0
A:   1.9 V:   1.2 A-V:  0.752 ct:  2.385  44/ 43 13359% 12146% 45373.0% 3177 0
A:   2.0 V:   1.2 A-V:  0.740 ct:  2.389  45/ 44 13102% 11912% 44500.5% 3177 0
A:   2.0 V:   1.2 A-V:  0.750 ct:  2.392  46/ 45 12855% 11688% 43660.9% 3177 0
A:   2.0 V:   1.3 A-V:  0.700 ct:  2.395  47/ 46 12617% 11471% 42852.4% 3177 0
A:   2.1 V:   1.3 A-V:  0.730 ct:  2.399  48/ 47 12276% 11161% 41694.2% 3177 0
A:   2.1 V:   1.4 A-V:  0.723 ct:  2.402  50/ 48 12059% 10964% 40956.6% 3177 0
A:   2.1 V:   1.4 A-V:  0.716 ct:  2.405  51/ 49 11747% 10680% 39897.4% 3177 0

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:   2.2 V:   1.5 A-V:  0.696 ct:  2.409  53/ 50 11451% 10411% 38892.0% 3177 0
A:   2.3 V:   1.5 A-V:  0.718 ct:  2.413  54/ 51 11101% 10093% 37703.9% 3177 0
A:   2.3 V:   1.6 A-V:  0.710 ct:  2.417  55/ 52 10880% 9892% 36951.4% 3177 0  
A:   2.3 V:   1.6 A-V:  0.732 ct:  2.421  56/ 53 10667% 9698% 36228.3% 3177 0  
A:   2.4 V:   1.6 A-V:  0.712 ct:  2.425  57/ 54 10462% 9512% 35533.1% 3177 0  
A:   2.4 V:   1.7 A-V:  0.713 ct:  2.430  58/ 55 10265% 9333% 34864.0% 3177 0  


theirs  Sherpya-SVN-r34118-4.2.5 doesn't loop... (I have gcc 4.5.1 ... hmm...)

A:3498.3 V:3498.28 A-V:  0.006 ct:  7.296 5564/5564 85% 42% 311.3% 66 0        
A:3498.3 V:3498.32 A-V: -0.028 ct:  7.294 5565/5565 85% 42% 311.3% 66 0        
A:3498.3 V:3498.36 A-V: -0.030 ct:  7.290 5566/5566 85% 42% 311.2% 66 0        
A:3499.3 V:  0.00 A-V:3499.321 ct:  7.295   0/  0 ??% ??% ??,?% 66 0           
A:   0.3 V:  0.04 A-V:  0.232 ct:  7.299   1/  1 ??% ??% ??,?% 67 0            
A:   0.3 V:  0.08 A-V:  0.241 ct:  7.303   2/  2 ??% ??% ??,?% 68 0            
A:   0.3 V:  0.13 A-V:  0.219 ct:  7.307   3/  3 ??% ??% ??,?% 68 0            
A:   0.4 V:  0.17 A-V:  0.197 ct:  7.311   4/  4 ??% ??% ??,?% 69 0            
A:   0.4 V:  0.21 A-V:  0.156 ct:  7.315   5/  5 ??% ??% ??,?% 69 0            
A:   0.4 V:  0.25 A-V:  0.124 ct:  7.320   6/  6 ??% ??% ??,?% 69 0            
A:   0.4 V:3498.69 A-V:-3498.288 ct:  7.315   7/  7 ??% ??% ??,?% 69 0         
A:   0.4 V:3498.73 A-V:-3498.322 ct:  7.311   8/  8 ??% ??% ??,?% 69 0         
A:   0.5 V:3498.78 A-V:-3498.281 ct:  7.307   9/  9 ??% ??% ??,?% 69 0         
A:   0.5 V:3498.82 A-V:-3498.273 ct:  7.303  10/ 10 ??% ??% ??,?% 69 0         
A:   0.6 V:3498.86 A-V:-3498.275 ct:  7.299  11/ 11 39455% 19719% 144452.6% 69
A:   0.6 V:3498.90 A-V:-3498.267 ct:  7.295  12/ 12 36420% 18202% 133343.0% 69
A:   0.7 V:3498.94 A-V:-3498.269 ct:  7.290  13/ 13 33819% 16902% 123820.2% 69
A:   0.7 V:3498.98 A-V:-3498.270 ct:  7.286  14/ 14 31565% 15775% 115565.6% 69
A:   0.7 V:3499.03 A-V:-3498.284 ct:  7.282  15/ 15 29592% 14789% 108342.9% 69
A:   0.8 V:3499.07 A-V:-3498.254 ct:  7.278  16/ 16 27852% 13919% 101975.0% 69
A:   0.9 V:3499.11 A-V:-3498.256 ct:  7.274  17/ 17 26305% 13146% 96312.9% 69 
A:   0.9 V:3499.15 A-V:-3498.247 ct:  7.270  18/ 18 24921% 12454% 91245.4% 69 
A:   1.0 V:3499.19 A-V:-3498.239 ct:  7.265  19/ 19 23675% 11832% 86683.4% 69 
A:   1.0 V:3499.23 A-V:-3498.240 ct:  7.261  20/ 20 22548% 11268% 82556.5% 69 
A:   1.0 V:3499.28 A-V:-3498.274 ct:  7.257  21/ 21 21523% 10756% 78805.4% 69 
A:   1.1 V:3499.32 A-V:-3498.234 ct:  7.253  22/ 22 20588% 10289% 75380.4% 69 
A:   1.1 V:3499.36 A-V:-3498.226 ct:  7.249  23/ 23 19730% 9860% 72240.9% 69 0
A:   1.2 V:3499.40 A-V:-3498.228 ct:  7.245  24/ 24 18941% 9465% 69351.5% 69 0
A:   1.2 V:3499.44 A-V:-3498.219 ct:  7.240  25/ 25 18213% 9101% 66684.3% 69 0
A:   1.3 V:3499.49 A-V:-3498.221 ct:  7.236  26/ 26 17539% 8764% 64215.7% 69 0
A:   1.3 V:  0.25 A-V:  1.031 ct:  7.240  27/ 27 16912% 8451% 61923.4% 69 0    
A:   1.4 V:  0.29 A-V:  1.061 ct:  7.245  28/ 28 16329% 8160% 59789.1% 69 0    
A:   1.4 V:  0.33 A-V:  1.050 ct:  7.249  29/ 29 15785% 7888% 57798.0% 69 0    

shoot.

mplayer_me -nocache dvdnav://1

osd_level 1 osd_fractions 0 
A:3223.0 V:3222.99 A-V:  0.009 ct:  8.135 11233/11233 100%  3% 438.7% 532 0    
osd_level 1 osd_fractions 0 
A:3223.0 V:3223.03 A-V: -0.012 ct:  8.134 11234/11234 100%  3% 438.7% 532 0    
osd_level 1 osd_fractions 0 
A:3223.0 V:3223.08 A-V: -0.043 ct:  8.130 11235/11235 100%  3% 438.7% 532 0    
osd_level 1 osd_fractions 0 
A:3223.4 V:  0.00 A-V:3223.363 ct:  8.130   0/  0 ??% ??% ??,?% 532 0          
A:   0.3 V:  0.00 A-V:  0.313 ct:  8.134   0/  0 ??% ??% ??,?% 532 0           
off, looping.
Ok I am so confused now LOL.

pristine loops, too (gcc 4.5.1)
  
  Invalid seek to negative position 7e98000481c!
  [ac3 @ 00be8680]incomplete frame


next one:

osd_level 1 osd_fractions 0 
A:3223.1 V:3223.08 A-V: -0.021 ct: 14.090 11235/11235 165%  3% 717.6% 546 0    
osd_level 1 osd_fractions 0 
A:3223.4 V:  0.00 A-V:3223.363 ct: 14.090   0/  0 ??% ??% ??,?% 546 0          
A:   0.3 V:  0.00 A-V:  0.313 ct: 14.095   0/  0 ??% ??% ??,?% 546 0           
osd_level 1 osd_fractions 0 
A:   0.4 V:  0.04 A-V:  0.356 ct: 14.099   1/  1 ??% ??% ??,?% 546 0           
maybe it's really restarting for some reason? and that's causing the looping?


Invalid seek to negative position 7e98000481c!
[ac3 @ 00be88c0]incomplete frame


appears to be...

mplayer -volume 0 -nocache dvdnav://1 2>&1 >me_c_volume0_nocache_dvdnav_full.txt
weird restarting?

osd_level 1 osd_fractions 0 
A:3223.0 V:3223.03 A-V:  0.010 ct:  2.258 11234/11234 34%  2% 150.4% 659 0     
osd_level 1 osd_fractions 0 
A:3223.4 V:  0.00 A-V:3223.363 ct:  2.258   0/  0 ??% ??% ??,?% 659 0          
A:   0.3 V:  0.00 A-V:  0.313 ct:  2.262   0/  0 ??% ??% ??,?% 659 0           
osd_level 1 osd_fractions 0 
A:   0.4 V:  0.04 A-V:  0.356 ct:  2.266   1/  1 ??% ??% ??,?% 659 0           
osd_level 1 osd_fractions 0 


>mplayer -volume 0 -nocache dvdnav://1 -vo null 2>&1 >me_c_dvdnav_full_vo_null.txt

osd_level 1 osd_fractions 0 
A:3223.0 V:3222.99 A-V:  0.009 ct:  2.210 11233/11233 34%  0% 148.6% 68 0      
osd_level 1 osd_fractions 0 
A:3223.0 V:3223.03 A-V:  0.010 ct:  2.211 11234/11234 34%  0% 148.6% 68 0      
osd_level 1 osd_fractions 0 
A:3223.4 V:  0.00 A-V:3223.363 ct:  2.211   0/  0 ??% ??% ??,?% 68 0           
A:   0.3 V:  0.00 A-V:  0.313 ct:  2.215   0/  0 ??% ??% ??,?% 68 0            
osd_level 1 osd_fractions 0 
A:   0.4 V:  0.04 A-V:  0.356 ct:  2.219   1/  1 ??% ??% ??,?% 68 0            
wow I don't know how to desribe this.

my_mplayer -autosync 30 -nocache -ss 3450 dvdnav://1

  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3498.9 V:3498.86 A-V:  0.003 ct: -0.267 404/404  6%  6% 23.0% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3498.9 V:3498.90 A-V: -0.029 ct: -0.269 405/405  6%  6% 22.9% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3499.4 V:  0.00 A-V:3499.362 ct: -0.265   0/  0 ??% ??% ??,?% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:   0.2 V:  0.04 A-V:  0.132 ct: -0.261   1/  1 ??% ??% ??,?% 0 0
  =====  PAUSE  =====
  
osd_level 1 osd_fractions 0
A:3499.0 V:3498.98 A-V: -0.028 ct: -0.270 239/239  9%  5% 23.8% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3499.4 V:  0.00 A-V:3499.362 ct: -0.266   0/  0 ??% ??% ??,?% 0 0
  =====  PAUSE  =====

old_mplayer's, notice how it's whackedby like 0.4'ish:
that is nuts.
Maybe it's a bug then, and we're right now :P

A:3498.2 V:3498.23 A-V:  0.003 ct: -0.260 149/149  8%  7% 28.5% 0 0
A:3498.2 V:3498.28 A-V: -0.029 ct: -0.263 150/150  8%  7% 28.3% 0 0
A:3499.4 V:  0.00 A-V:3499.362 ct: -0.259   0/  0 ??% ??% ??,?% 0 0
A:   0.2 V:  0.04 A-V:  0.132 ct: -0.255   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.127 ct: -0.251   2/  2 ??% ??% ??,?% 0 0
A:   0.2 V:  0.13 A-V:  0.123 ct: -0.251   3/  3 ??% ??% ??,?% 0 0
A:   0.2 V:  0.13 A-V:  0.123 ct: -0.247   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.119 ct: -0.247   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.119 ct: -0.242   4/  4 ??% ??% ??,?% 0 0
A:   0.3 V:  0.21 A-V:  0.115 ct: -0.238   5/  5 ??% ??% ??,?% 0 0
A:   0.4 V:  0.25 A-V:  0.111 ct: -0.234   6/  6 ??% ??% ??,?% 0 0
A:   0.4 V:  0.29 A-V:  0.107 ct: -0.230   7/  7 ??% ??% ??,?% 0 0
A:   0.4 V:  0.33 A-V:  0.102 ct: -0.226   8/  8 ??% ??% ??,?% 0 0
A:   0.5 V:3498.69 A-V:-3498.219 ct: -0.230   9/  9 ??% ??% ??,?% 0 0
A:   0.5 V:3498.73 A-V:-3498.214 ct: -0.234  10/ 10 ??% ??% ??,?% 0 0
A:   0.5 V:3498.78 A-V:-3498.242 ct: -0.238  11/ 11 109% 99% 396.2% 0 0
A:   0.6 V:3498.82 A-V:-3498.206 ct: -0.242  12/ 12 101% 91% 370.3% 0 0
A:   0.7 V:3498.86 A-V:-3498.202 ct: -0.247  13/ 13 94% 85% 348.0% 0 0
A:   0.7 V:3498.90 A-V:-3498.198 ct: -0.251  14/ 14 88% 80% 328.6% 0 0
A:   0.7 V:3498.94 A-V:-3498.194 ct: -0.255  15/ 15 83% 75% 309.0% 0 0
A:   0.8 V:3498.98 A-V:-3498.190 ct: -0.259  16/ 16 78% 71% 293.9% 0 0
A:   0.8 V:3499.03 A-V:-3498.186 ct: -0.263  17/ 17 74% 67% 280.5% 0 0
A:   0.9 V:3499.07 A-V:-3498.181 ct: -0.267  18/ 18 71% 63% 267.4% 0 0
A:   0.9 V:3499.11 A-V:-3498.177 ct: -0.272  19/ 19 67% 61% 257.1% 0 0
A:   1.0 V:3499.15 A-V:-3498.173 ct: -0.276  20/ 20 64% 58% 248.0% 0 0
A:   1.0 V:3499.19 A-V:-3498.169 ct: -0.280  21/ 21 62% 55% 239.5% 0 0
A:   1.1 V:3499.23 A-V:-3498.165 ct: -0.284  22/ 22 59% 53% 231.7% 0 0
A:   1.1 V:3499.28 A-V:-3498.160 ct: -0.288  23/ 23 57% 51% 223.0% 0 0
A:   1.1 V:3499.32 A-V:-3498.188 ct: -0.292  24/ 24 55% 49% 214.1% 0 0
A:   1.2 V:3499.36 A-V:-3498.152 ct: -0.297  25/ 25 53% 48% 207.0% 0 0
A:   1.3 V:3499.40 A-V:-3498.148 ct: -0.301  26/ 26 51% 46% 202.6% 0 0
A:   1.3 V:3499.44 A-V:-3498.144 ct: -0.305  27/ 27 50% 45% 197.5% 0 0
A:   1.3 V:3499.49 A-V:-3498.140 ct: -0.309  28/ 28 48% 43% 191.6% 0 0
A:   1.4 V:  0.25 A-V:  1.140 ct: -0.305  29/ 29 47% 42% 185.2% 0 0
A:   1.4 V:  0.29 A-V:  1.136 ct: -0.301  30/ 30 45% 41% 181.3% 0 0
A:   1.5 V:  0.33 A-V:  1.132 ct: -0.297  31/ 31 44% 39% 176.7% 0 0
A:   1.5 V:  0.38 A-V:  1.128 ct: -0.292  32/ 32 43% 38% 171.5% 0 0

so just trust mine LOL.
 they do match up *past* that so I think mine is indeed better. FWIW.

mine, with noaudio:


osd_level 1 osd_fractions 0
V:3499.40 549/549  7%  5%  0.0% 0 0
osd_level 1 osd_fractions 0
V:  0.04   0/  0 ??% ??% ??,?% 0 0

=snow white 0.2=

 0.4 start
 7.120795 -  6.923583 = 0.1972120000000004
 fascinating. nothing in common with start times, perhaps?
 
 and at end:
   it's borked
   
=mtoe 0.2=

 4.137467 - (mineE)  3.903900 => 0.23350000000000026
  from 0.3 even
  yep, this is bizarre
  
  and at end...
  4820.248047 -  4819.983398 0.2646489999997357
  
 =all dogs go to heaven 0.2=
 start "0.3" (probable 0.28)
 
  4.010844 -  3.837166  0.17367799999999978
  
  demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

 594.200256 - 603.069153 -8.86889700000006
 
  3033.053955 -  3041.922363  -8.868408000000272
  oh oops had a split at 9.266098 - 0.34 somehow...

 = little mermaid =
  0.28
  
  4.993670 -  6.998652
   had an early split:
    mpeg at 0.814500,  mpeg at 0.280633 
            V:   1.4 A-V:  0.193 ct:  0.032  36/ 36 31%  7% 55.7% 3 0
   A:   1.7 V:   0.3
   
   # TODO DISALLOW TOO EARLY OF SPLITS ? WARN [?]
   
   A:   0.8 V:  0.81 A-V:  0.031 ct:  0.053  19/ 19 45% 21% 29.0% 4 0             

osd_level 2 osd_fractions 2 
last NAV packet was 1.066667, mpeg at 0.280633 after -> 29.97 1.067733
not adding negative diff -0.533867adding 0.000000 to 1.067733 
final: 1.067733
A:   0.9 V:  0.28 A-V:  0.587 ct:  0.056  20/ 20 44% 21% 27.6% 4 0             

then again:

 0.81 A-V:  0.543 ct:  0.109  36/ 36 34% 20% 22.3% 4 0             

osd_level 2 osd_fractions 2 
last NAV packet was 1.633333, mpeg at 0.280633 after -> 29.97 1.634967
not adding negative diff -0.533867adding 0.000000 to 1.634967 
final: 1.634967
using mpeg ts appears larger, which if true is definitely better 0.280633 > 1.634967 - 10
A:   1.4 V:  0.28 A-V:  1.099 ct:  0.113  37/ 37 34% 19% 22.1% 4 0             


MAYBE IT NEEDS TO EQUAL THE ACKET BEFORE THE NEXT RESTART PACKET...
  or maybe it really actually means...add one frame tho :P
  thinking the 0.28 is to allow for an easier "seamless" transition from one to the next...maybe?

  just subtract one, I'm thinking?
0.814500 -  1.067733 -0.25

too hard to tell LOL. (right on a split, might have been whacked out somehow...)

last NAV packet was 2.200000, mpeg at 0.814500 (equiv. to 2.4 about), so we lost 1.6
we have 

 0.81
 0.28
 ...
 0.81
 0.28

 so if we had split twice at 0.81, we'd be close...
   now I'm torn :P

 mpeg 7.245920 -  9.250908  -2.004988000000001
 
 I'm guessing 0.85 is good for now...
   hmm...actually it might be...and this is one phreaky DVD...hmm...sure :P
   
  I'm guessing this one is actually "those each were 1.0s each, and we don't have a new starting 0.2 at all" however, the "add one frame"
    thing actually almost gets us close...plus we can warn if we're past a split...
    should be 0.81 + 0.04+0.24
  
  
=nanny mcphee=
0.28
  2.733078 - 2.519184 => 0.213
   4797.554688 -  4797.359375 =>  0.19531300000016927
   
=c has some inline=

has some inline switches 30 <-> 29.97 [!]

Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]

Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]

No bind found for key ''.

like twice

mplayer2 seems dead...yipes

== DVDNAV weirdness/search times ==

    // XXX the current version of libdvdnav can't seek outside the current
    // PGC. Check if the place we're seeking to is in a different
    // PGC. Position there & adjust the offset if so.

  http://forum.doom9.org/showthread.php?t=140995&highlight=nav+mpeg
    mentions that you can parse the IFO for information [?]

  http://forum.doom9.org/showthread.php?t=141169&highlight=nav+mpeg "you can just read through the NAV packs"
    "NAV packets just go forward, you can parse them or look in the IFO files"

  http://forum.doom9.org/showthread.php?t=111436&highlight=nav+mpeg

  mentions VTS_TMAPTI table...hmm...that might still be a grande clue, for determining precision...or maybe not...

https://github.com/HandBrake/HandBrake/blob/master/libhb/dvdnav.c
  
== times ==


=c with new mplayer=

split 3499.07

before the split, 
last NAV packet was 3411.699951, mpeg at 3415.309326 after -> 29.97 3415.111572
adding 0.175000 to 3415.111572
final: 3415.286621  => 0.02 short
using mpeg


after split
last NAV packet was 3496.533447, mpeg at 1.310520 after -> 29.97 3500.030029
adding difference 0.325325 adding 0.175000 to 3500.355469
final: 3500.530518

split  3498.984619 this time [?] huh?

old mplayer -nocache dvdnav://1:

A:3498.3 V:3498.36 A-V: -0.036 ct: -0.301 176/176  8%  4% 27.5r% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.297   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:  0.04 A-V: -0.738 ct: -0.297   1/  1 ??% ??% ??,?% 0 0
A:  -0.6 V:  0.04 A-V: -0.598 ct: -0.297   1/  1 ??% ??% ??,?% 0 0

oh great, it seems to agree with straight dvd:// huh?
  this sucks
  assume mine is newer and somehow better...

mplayer_34118
  A:3499.0 V:3499.0 A-V: -0.026 ct: -0.301 396/396  6%  4% 23.2% 0 0
  A:3499.3 V:   0.0 A-V:3499.299 ct: -0.301   0/  0 ??% ??% ??,?% 0 0
  A:   0.1 V:   0.0 A-V:  0.115 ct: -0.297   0/  0 ??% ??% ??,?% 0 0
  
  just because of a newer ffmpeg maybe?
    ffmpeg 1d186e9e120d777cc9f5e68d2974d48bfbdd528e
   mpegts: Fix for continuity counter ?
  I hope newer is better...
    I'm using 51bfaa21c8'ish v of ffmpeg
    I guess I really do need to add 0.5 per split wowza

linux
    A:   1.2 V:3499.6 A-V:-3498.380 ct: -0.379  18/ 18 514% 561% 33.2% 0 0 
then it starts at 0.3
   but it feels messed...like really messed up...the DVD might not be coming through clear...
    
===detect split ===

me dvdnav://, with pauses
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3499.0 V:3499.03 A-V: -0.037 ct: -0.294 624/624  6%  5% 24.6% 0 0
  =====  PAUSE  =====
osd_level 1 osd_fractions 0
A:3499.3 V:  0.00 A-V:3499.299 ct: -0.294   0/  0 ??% ??% ??,?% 0 0 # audio packet
A:   0.1 V:  0.00 A-V:  0.094 ct: -0.290   0/  0 ??% ??% ??,?% 0 0

shooting through:
A:3499.0 V:3499.03 A-V: -0.036 ct: -0.278 216/216  9%  4% 25.2% 0 0
osd_level 1 osd_fractions 0
A:   0.1 V:  0.00 A-V:  0.115 ct: -0.274   0/  0 ??% ??% ??,?% 0 0
 I think this is right LOL

dvdout, theirs, dvd://
bizarre
A:3498.3 V:3498.28 A-V:  0.003 ct:  0.039 2978/2975  6% 11%  0.8% 0 0
A:3498.3 V:3498.32 A-V: -0.031 ct:  0.036 2979/2976  6% 11%  0.8% 0 0
A:  -0.9 V:3498.36 A-V:-3499.291 ct:  0.032 2980/2977  6% 11%  0.8% 0 0
A:  -0.8 V:3498.40 A-V:-3499.250 ct:  0.028 2981/2978  6% 11%  0.8% 0 0
A:  -0.8 V:3498.44 A-V:-3499.242 ct:  0.024 2982/2979  6% 11%  0.8% 0 0
A:  -0.8 V:3498.48 A-V:-3499.244 ct:  0.019 2983/2980  6% 11%  0.8% 0 0
A:  -0.7 V:3498.53 A-V:-3499.268 ct:  0.015 2984/2981  6% 11%  0.8% 0 0
A:  -0.7 V:3498.57 A-V:-3499.237 ct:  0.011 2985/2982  6% 11%  0.8% 0 0
A:  -0.6 V:3498.61 A-V:-3499.229 ct:  0.007 2986/2983  6% 11%  0.7% 0 0
A:  -0.6 V:3498.65 A-V:-3499.231 ct:  0.003 2987/2984  6% 11%  0.7% 0 0
A:  -0.5 V:3498.69 A-V:-3499.222 ct: -0.001 2988/2985  6% 11%  0.7% 0 0
A:  -0.5 V:3498.73 A-V:-3499.214 ct: -0.006 2989/2986  6% 11%  0.7% 0 0
A:  -0.5 V:3498.78 A-V:-3499.248 ct: -0.010 2990/2987  6% 11%  0.7% 0 0
A:  -0.4 V:3498.82 A-V:-3499.207 ct: -0.014 2991/2988  6% 11%  0.7% 0 0
A:  -0.3 V:3498.86 A-V:-3499.199 ct: -0.018 2992/2989  6% 11%  0.7% 0 0
A:  -0.3 V:3498.90 A-V:-3499.191 ct: -0.022 2993/2990  6% 11%  0.7% 0 0
A:  -0.2 V:3498.94 A-V:-3499.193 ct: -0.026 2994/2991  6% 11%  0.7% 0 0
A:  -0.2 V:3498.98 A-V:-3499.194 ct: -0.031 2995/2992  6% 11%  0.7% 0 0
A:  -0.2 V:3499.03 A-V:-3499.218 ct: -0.035 2996/2993  6% 11%  0.7% 0 0
A:  -0.1 V:3499.07 A-V:-3499.178 ct: -0.039 2997/2994  6% 11%  0.7% 0 0
A:  -0.1 V:3499.11 A-V:-3499.179 ct: -0.043 2998/2995  6% 11%  0.7% 0 0
A:  -0.0 V:3499.15 A-V:-3499.171 ct: -0.047 2999/2996  6% 11%  0.7% 0 0
A:   0.0 V:3499.19 A-V:-3499.173 ct: -0.051 3000/2997  6% 11%  0.7% 0 0
A:   0.1 V:3499.23 A-V:-3499.165 ct: -0.056 3001/2998  6% 11%  0.7% 0 0
A:   0.1 V:3499.28 A-V:-3499.156 ct: -0.060 3002/2999  6% 11%  0.7% 0 0
A:   0.2 V:3499.32 A-V:-3499.148 ct: -0.064 3003/3000  6% 11%  0.7% 0 0
A:   0.2 V:3499.36 A-V:-3499.160 ct: -0.068 3004/3001  6% 11%  0.7% 0 0
A:   0.3 V:3499.40 A-V:-3499.152 ct: -0.072 3005/3002  6% 11%  0.7% 0 0
A:   0.3 V:3499.44 A-V:-3499.153 ct: -0.076 3006/3003  6% 11%  0.7% 0 0
A:   0.4 V:3499.49 A-V:-3499.135 ct: -0.081 3007/3004  6% 11%  0.7% 0 0
A:   0.4 V:  0.25 A-V:  0.139 ct: -0.076 3008/3005  6% 11%  0.7% 0 0
  MAYBE SIMILAR TO THE NO AUDIO OPTION THOUGH
  huh?
  I guess it doesn't matter, but this is still freaky-o

played back with theirs,  dvdout.minemplayer.dvdnav.mpg

A:3498.3 V:3498.28 A-V: -0.002 ct:  0.036 2289/2286  6% 12%  1.2% 0 0
A:3498.3 V:3498.32 A-V: -0.036 ct:  0.032 2290/2287  6% 12%  1.2% 0 0
A:  -0.9 V:3498.36 A-V:-3499.287 ct:  0.028 2291/2288  6% 12%  1.2% 0 0
A:  -0.8 V:3498.40 A-V:-3499.246 ct:  0.024 2292/2289  6% 12%  1.2% 0 0
A:  -0.8 V:3498.44 A-V:-3499.248 ct:  0.020 2293/2290  6% 12%  1.2% 0 0
A:  -0.8 V:3498.48 A-V:-3499.240 ct:  0.015 2294/2291  6% 12%  1.2% 0 0
A:  -0.8 V:3498.53 A-V:-3499.283 ct:  0.011 2295/2292  6% 12%  1.2% 0 0
A:  -0.7 V:3498.57 A-V:-3499.233 ct:  0.007 2296/2293  6% 12%  1.2% 0 0
A:  -0.6 V:3498.61 A-V:-3499.235 ct:  0.003 2297/2294  6% 12%  1.2% 0 0
A:  -0.6 V:3498.65 A-V:-3499.227 ct: -0.001 2298/2295  6% 12%  1.2% 0 0
A:  -0.5 V:3498.69 A-V:-3499.218 ct: -0.005 2299/2296  6% 13%  1.2% 0 0
A:  -0.5 V:3498.73 A-V:-3499.220 ct: -0.010 2300/2297  6% 12%  1.2% 0 0
A:  -0.5 V:3498.78 A-V:-3499.244 ct: -0.014 2301/2298  6% 13%  1.2% 0 0
A:  -0.4 V:3498.82 A-V:-3499.203 ct: -0.018 2302/2299  6% 13%  1.2% 0 0
A:  -0.3 V:3498.86 A-V:-3499.205 ct: -0.022 2303/2300  6% 13%  1.2% 0 0
A:  -0.3 V:3498.90 A-V:-3499.207 ct: -0.026 2304/2301  6% 13%  1.2% 0 0
A:  -0.3 V:3498.94 A-V:-3499.198 ct: -0.030 2305/2302  6% 12%  1.2% 0 0
A:  -0.2 V:3498.98 A-V:-3499.200 ct: -0.035 2306/2303  6% 12%  1.2% 0 0
A:  -0.2 V:3499.03 A-V:-3499.202 ct: -0.039 2307/2304  6% 12%  1.2% 0 0
A:  -0.1 V:3499.07 A-V:-3499.184 ct: -0.043 2308/2305  6% 12%  1.2% 0 0
A:  -0.1 V:3499.11 A-V:-3499.176 ct: -0.047 2309/2306  6% 12%  1.1% 0 0
A:  -0.0 V:3499.15 A-V:-3499.187 ct: -0.051 2310/2307  6% 12%  1.1% 0 0
A:   0.0 V:3499.19 A-V:-3499.169 ct: -0.055 2311/2308  6% 12%  1.1% 0 0 # kind of close, kind of really far. weird.
A:   0.1 V:3499.23 A-V:-3499.161 ct: -0.060 2312/2309  6% 12%  1.1% 0 0
A:   0.1 V:3499.28 A-V:-3499.172 ct: -0.064 2313/2310  6% 12%  1.1% 0 0
A:   0.1 V:3499.32 A-V:-3499.196 ct: -0.068 2314/2311  6% 12%  1.1% 0 0
A:   0.2 V:3499.36 A-V:-3499.166 ct: -0.072 2315/2312  6% 12%  1.1% 0 0
A:   0.2 V:3499.40 A-V:-3499.157 ct: -0.076 2316/2313  6% 12%  1.1% 0 0
A:   0.3 V:3499.44 A-V:-3499.149 ct: -0.080 2317/2314  6% 12%  1.1% 0 0
A:   0.3 V:3499.49 A-V:-3499.141 ct: -0.085 2318/2315  6% 12%  1.1% 0 0
A:   0.4 V:  0.25 A-V:  0.133 ct: -0.080 2319/2316  6% 12%  1.1% 0 0



and when straight played:
A:   0.3 V:3499.44 A-V:-3499.143 ct: -0.383 598/595  5% 11% 28.8% 0 0
A:   0.3 V:3499.49 A-V:-3499.145 ct: -0.387 599/596  6% 11% 28.8% 0 0
A:   0.4 V:  0.25 A-V:  0.149 ct: -0.383 600/597  6% 12% 28.8% 0 0
A:   0.5 V:  0.29 A-V:  0.157 ct: -0.379 601/598  6% 12% 29.0% 0 0

mine dvdout.minemplayer.dvd.mpg, played with theirs
A:   0.3 V:3499.40 A-V:-3499.152 ct: -0.079 1917/1914  6% 13%  0.4% 0 0
A:   0.3 V:3499.44 A-V:-3499.143 ct: -0.084 1918/1915  6% 13%  0.4% 0 0
A:   0.3 V:3499.49 A-V:-3499.145 ct: -0.088 1919/1916  6% 13%  0.4% 0 0
A:   0.4 V:  0.25 A-V:  0.139 ct: -0.084 1920/1917  6% 13%  0.4% 0 0
A:   0.4 V:  0.29 A-V:  0.105 ct: -0.079 1921/1918  6% 13%  0.4% 0 0
  so seeking must be all that's borked in mine. LOL. phew!

Input #0, mpeg, from 'dvdout.minemplayer.dvd.mpg':
  Duration: 00:00:06.87, start: 0.280633, bitrate: -2147483 kb/s (this is after the split, note the negative)
  
dvd:
  V:3499.48 1095/1092  4%  0%  0.0% 0 0                                            
  V:  0.25 1096/1093  4%  0%  0.0% 0 0  

  V:3499.48 1095/1092  4%  0%  0.0% 0 0                                          
  V:  0.25 1096/1093  4%  0%  0.0% 0 0                                           

dvd split time for -=c= with full play length, with audio (mine) dvd no cache, mine
  A:3222.0 V:3221.99 A-V: -0.003 ct:  0.289 77266/77256  4%  0% 32.1% 255 0      
  time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 
  osd_level 1 osd_fractions 0 
  A:3222.1 V:3222.03 A-V:  0.019 ct:  0.291 77267/77257  4%  0% 32.1% 255 0      
  time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 3218.801000 time 0.000000 time 0.000000 time 0.000000 time 0.000000 time 0.000000 
  osd_level 1 osd_fractions 0 
  A:   0.2 V:3222.07 A-V:-3221.900 ct:  0.287 77268/77258  4%  0% 32.1% 256 0    
  time 0.400000 time 0.400000 time 0.400000 time 0.400000 time 0.400000 time 0.400000 
  osd_level 1 osd_fractions 0 
  A:   0.2 V:3222.12 A-V:-3221.920 ct:  0.283 77269/77259  4%  0% 32.1% 256 0    
    maybe this is a disney thing? assume this is expected?
          maybe just mine?
??

theirs (old mplayer)
  A:3498.3 V:3498.28 A-V: -0.005 ct: -0.265 326/323  9%  3% 28.2% 0 0
  A:3498.3 V:3498.32 A-V: -0.039 ct: -0.269 327/324  9%  3% 28.0% 0 0
  A:3498.3 V:3498.36 A-V: -0.040 ct: -0.273 328/325  9%  3% 27.8% 0 0
  A:  -0.8 V:3498.40 A-V:-3499.238 ct: -0.277 329/326  9%  3% 28.1% 0 0
  A:  -0.8 V:3498.44 A-V:-3499.230 ct: -0.281 330/327  9%  3% 28.3% 0 0
  A:  -0.7 V:3498.48 A-V:-3499.232 ct: -0.286 331/328  8%  3% 28.3% 0 0

seeking in dvd:// might be broken if MPEG is...not it should work all right, it's using the VOBU...hmm...
  so basically when seeking, what it "should" do it seek you forward until you get to the right spot, one frame at a time, I guess...
  so I could maintain a table of "vobu -> mpeg times" when I pass one...maybe...or maybe for each frame, update the vobu map...
  
A:3188.3 V:3188.42 A-V: -0.156 ct: -0.089 136/133 11%  6% 25.0% 0 0
osd_level 1 osd_fractions 0
A:3188.3 V:3188.46 A-V: -0.155 ct: -0.093 137/134 11%  6% 27.3% 0 0
Invalid seek to negative position 28ed40810b2000! # freeze...hmm...and just with mine? huh?

old ones used to work? huh?
  svn log on that file didn't  33601 latest for dvd://
  
  I guess it only matters what mplayer "thinks" is the split, but still...huh?
    which might be different for dumpstream of dvd:// versus dvdnav:// whoa!
    I guess we're ok then...
    
dvdnav:

V:3499.40 1057/1054  4%  0%  0.0% 0 0                                          
V:  0.04   0/  0 ??% ??% ??,?% 0 0                                             
V:3499.40 1055/1052  4%  0%  0.0% 0 0                                          
V:  0.04   0/  0 ??% ??% ??,?% 0 0                                             

when actually playing it though...
V:3498.98

then 0.00 for the next, which...may mean you should add one frame worth to it :)
  so imagine a split at 3499.02

osd_level 3 osd_fractions 1
last NAV packet was 3495.733398, mpeg at 0.417083 after -> 29.97 3499.229248
adding 0.175000 to 3499.229248
final: 3499.404297
A:   0.5 V:  0.42 A-V:  0.094 ct: -0.231  10/ 10 ??% ??% ??,?% 0 0

so this seems to impliy the split should have been at 3498.98, timing-wise...

osd_level 3 osd_fractions 1
last NAV packet was 3494.833252, mpeg at 3498.984619 after -> 29.97 3498.328125
adding difference 0.458984 adding 0.175000 to 3498.787109
final: 3498.962158
using mpeg ts appears larger, which if true is definitely better 3498.984619 > 3498.962158 - 10
A:3499.0 V:3498.98 A-V: -0.030 ct: -0.277 215/215  5%  9% 23.4% 0 0
  =====  PAUSE  =====
ID_PAUSED
DVDNAV_TITLE_IS_MOVIE

osd_level 3 osd_fractions 1
weird fella mpeg at 0.000000 adding 0.175000 to 0.000000
final: 0.175000
using mpeg ts appears larger, which if true is definitely better 0.000000 > 0.175000 - 10
A:3499.4 V:  0.00 A-V:3499.362 ct: -0.272   0/  0 ??% ??% ??,?% 0 0


which is what dvdnav gave us *when played* ?

old mplayer:
A:3498.3 V:3498.36 A-V: -0.034 ct: -0.292 164/164  9%  4% 27.9% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.288   0/  0 ??% ??% ??,?% 0 0
A:3498.3 V:3498.36 A-V: -0.034 ct: -0.292 164/164  9%  4% 27.9% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.288   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:  0.04 A-V: -0.708 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:  -0.5 V:  0.04 A-V: -0.588 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:  -0.4 V:  0.04 A-V: -0.468 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:  -0.2 V:  0.04 A-V: -0.288 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:  0.04 A-V: -0.108 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.042 ct: -0.288   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.04 A-V:  0.110 ct: -0.284   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.141 ct: -0.279   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:  0.13 A-V:  0.129 ct: -0.256   3/  3 ??% ??% ??,?% 0 0
A:   0.4 V:  0.17 A-V:  0.197 ct: -0.254   4/  4 ??% ??% ??,?% 34 0
A:   0.4 V:  0.21 A-V:  0.186 ct: -0.249   5/  5 ??% ??% ??,?% 34 0
A:   0.4 V:  0.25 A-V:  0.144 ct: -0.245   6/  6 ??% ??% ??,?% 34 0
A:   0.4 V:3498.69 A-V:-3498.288 ct: -0.249   7/  7 ??% ??% ??,?% 34 0
A:   0.4 V:3498.73 A-V:-3498.300 ct: -0.254   8/  8 ??% ??% ??,?% 34 0
A:   0.5 V:3498.78 A-V:-3498.281 ct: -0.258   9/  9 ??% ??% ??,?% 34 0
A:   0.5 V:3498.82 A-V:-3498.283 ct: -0.262  10/ 10 ??% ??% ??,?% 34 0
A:   0.6 V:3498.86 A-V:-3498.295 ct: -0.266  11/ 11 113% 284% 407.4% 34 0
A:   0.6 V:3498.90 A-V:-3498.287 ct: -0.270  12/ 12 105% 262% 377.3% 34 0
A:   0.6 V:3498.94 A-V:-3498.299 ct: -0.274  13/ 13 97% 244% 350.6% 34 0
A:   0.7 V:3498.98 A-V:-3498.290 ct: -0.279  14/ 14 91% 228% 327.2% 34 0
A:   0.8 V:3499.03 A-V:-3498.272 ct: -0.283  15/ 15 86% 214% 308.5% 34 0
A:   0.8 V:3499.07 A-V:-3498.254 ct: -0.287  16/ 16 81% 201% 295.8% 34 0
A:   0.9 V:3499.11 A-V:-3498.256 ct: -0.291  17/ 17 77% 191% 282.7% 34 0
A:   0.9 V:3499.15 A-V:-3498.267 ct: -0.295  18/ 18 73% 181% 268.2% 34 0
A:   0.9 V:3499.19 A-V:-3498.269 ct: -0.299  19/ 19 70% 172% 255.7% 34 0
A:   1.0 V:3499.23 A-V:-3498.260 ct: -0.304  20/ 20 67% 164% 243.5% 34 0
A:   1.0 V:3499.28 A-V:-3498.242 ct: -0.308  21/ 21 64% 156% 235.2% 34 0
A:   1.1 V:3499.32 A-V:-3498.244 ct: -0.312  22/ 22 62% 150% 226.5% 34 0
A:   1.1 V:3499.36 A-V:-3498.256 ct: -0.316  23/ 23 59% 144% 217.3% 34 0
A:   1.2 V:3499.40 A-V:-3498.248 ct: -0.320  24/ 24 57% 138% 208.7% 34 0
A:   1.2 V:3499.44 A-V:-3498.239 ct: -0.324  25/ 25 55% 133% 200.8% 34 0
A:   1.3 V:3499.49 A-V:-3498.231 ct: -0.329  26/ 26 53% 128% 194.6% 34 0
A:   1.3 V:  0.25 A-V:  1.021 ct: -0.324  27/ 27 52% 123% 188.7% 34 0
A:   1.4 V:  0.29 A-V:  1.061 ct: -0.320  28/ 28 50% 119% 185.4% 34 0

you can infer from that that it's 3498.36 + 7 frames, which is close'ish-er...

ooh checkout the audio...thankfully don't have to worry about this:

 without audio: V:3499.40 1057/1054  5% 17%  0.0% 0 0                                          
A:3499.3 V:  0.00 A-V:3499.299 ct: -0.262   0/  0 ??% ??% ??,?% 0 0
A:   0.1 V:  0.00 A-V:  0.115 ct: -0.257   0/  0 ??% ??% ??,?% 0 0

r34118 3498.36

A:3498.3 V:3498.32 A-V: -0.031 ct: -0.221  94/ 91 16%  6% 32.7% 0 0
A:3499.3 V:  0.00 A-V:3499.321 ct: -0.217   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:  0.04 A-V: -0.718 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:  -0.5 V:  0.04 A-V: -0.588 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:  -0.4 V:  0.04 A-V: -0.468 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:  -0.2 V:  0.04 A-V: -0.288 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:  -0.1 V:  0.04 A-V: -0.128 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.062 ct: -0.217   1/  1 ??% ??% ??,?% 0 0
A:   0.1 V:  0.04 A-V:  0.100 ct: -0.213   1/  1 ??% ??% ??,?% 0 0
A:   0.2 V:  0.08 A-V:  0.141 ct: -0.208   2/  2 ??% ??% ??,?% 0 0
A:   0.3 V:  0.13 A-V:  0.129 ct: -0.204   3/  3 ??% ??% ??,?% 0 0
A:   0.3 V:  0.17 A-V:  0.097 ct: -0.200   4/  4 ??% ??% ??,?% 0 0

mine (extracted): no audio (with audio: 3499.401611)
  V:3499.03

mine (cleaned up): no audio
  SVN-r34234-4.5.1
  A:3498.9 V:3498.90 A-V: -0.007 ct: -0.213 108/105 14%  5% 28.1% 0 0
  A:3498.9 V:3498.94 A-V: -0.006 ct: -0.214 109/106 14%  5% 27.8% 0 0
  A:3498.9 V:3498.98 A-V: -0.038 ct: -0.218 110/107 14%  5% 27.6% 0 0
  A:3499.0 V:3499.03 A-V: -0.037 ct: -0.222 111/108 14%  5% 27.4% 0 0
  A:3499.3 V:  0.00 A-V:3499.299 ct: -0.222   0/  0 ??% ??% ??,?% 0 0
  A:   0.1 V:  0.00 A-V:  0.115 ct: -0.217   0/  0 ??% ??% ??,?% 0 0
  A:   0.2 V:  0.04 A-V:  0.138 ct: -0.213   1/  1 ??% ??% ??,?% 0 0

except not cleaned up, when really played, stepping through:

  osd_level 1 osd_fractions 0
  A:3499.0 V:3498.98 A-V: -0.016 ct: -0.212 110/107 13%  7% 28.8% 0 0
    =====  PAUSE  =====
  osd_level 1 osd_fractions 0
  A:3499.3 V:  0.00 A-V:3499.299 ct: -0.212   0/  0 ??% ??% ??,?% 0 0
  A:   0.1 V:  0.00 A-V:  0.094 ct: -0.208   0/  0 ??% ??% ??,?% 0 0
    =====  PAUSE  =====
  
  -vo null seemed to not make a difference. (it was the pausing that mattered)
  
  however, *only when stepping through it with frame pause* ! which seems pretty reliable...except that?

== which is better, pause-wise or straight-through, with parsing? ==
  in this case, we had  3499.4043-0.375 => 3499.0293 somehow :P
    except that we were (mpeg - me) 0.02
  @ 0.33 past:
    (3499.03+0.333)-3499.4043
     => -0.0412999999998647
     which is about one frame off...how bad it was before anyway
    
    started  5.819495 -5.780600
      => 0.0388950000000001
      
    middle 3460.812546 -  3460.631919
     [erroneous]  => 0.180627000000186 # oops, was missing my -osd-add parameter :P
    
    middle  3483.010254 -  3482.987549
      0.0227049999998599
    
    post middle  11.120322 + 3499.03 -  3510.339844
      -0.18952199999967 + 0.175 = -0.01452199999967
      
    end @ 3499.03 : (4208.937500 + 3499.03) -  7708.158691
      -0.19119099999898 + 0.175 = -0.01619099999898
      + 0.04 0.02380900000102
      yes!
      
newer mplayer does it?
newer ffmpeg causes it?

mine (SVN-r34234-4.5.1) without audio:
V:3499.23 116/113 12% 15%  0.0% 0 0
V:3499.28 117/114 12% 15%  0.0% 0 0
V:3499.32 118/115 12% 15%  0.0% 0 0
V:3499.36 119/116 12% 15%  0.0% 0 0
V:3499.40 120/117 12% 15%  0.0% 0 0 # wrong-o I wager...
V:  0.04   0/  0 ??% ??% ??,?% 0 0


Sherpya-SVN-r33574-4.2.5 with audio
A:3498.3 V:3498.3 A-V:  0.005 ct: -0.247  92/ 89  7%  1% 33.1% 0 0
A:3498.3 V:3498.3 A-V: -0.017 ct: -0.248  93/ 90  7%  1% 32.7% 0 0
A:3498.3 V:3498.3 A-V: -0.041 ct: -0.252  94/ 91  7%  1% 32.4% 0 0
A:3499.3 V:   0.0 A-V:3499.279 ct: -0.248   0/  0 ??% ??% ??,?% 0 0
A:  -0.7 V:   0.1 A-V: -0.769 ct: -0.248   1/  1 ??% ??% ??,?% 0 0
A:  -0.6 V:   0.1 A-V: -0.639 ct: -0.248   1/  1 ??% ??% ??,?% 0 0
 does have the freaky back and forth thing though...

 ===== blink @ =c= 105'ish comparing mplayer versions =====
   A: 106.1 V:106.12 A-V: for *both*  Sherpya-SVN-r34118-4.2.5,  SVN-r34234-4.5.1 (mine)
     phew!

  I think I can "assume" that mine is better? ... ?

== how to tell an audio packet came through ==
  osd_level 1 osd_fractions 0
  A:3499.0 V:3499.03 A-V: -0.069 ct: -0.296 192/192  7%  5% 25.5% 0 0 # real video packet
    =====  PAUSE  =====
  osd_level 1 osd_fractions 0
  A:3499.3 V:  0.00 A-V:3499.299 ct: -0.296   0/  0 ??% ??% ??,?% 0 0 # AUDIO PACKET you can tell because it doesn't say "pause", also V doesn't advance
  A:   0.1 V:  0.00 A-V:  0.094 ct: -0.292   0/  0 ??% ??% ??,?% 0 0 # real video packet then I guess...the above didn't count I guess, or maybetwo came in at once.
    => I think you can add one frame to the last v., or 3499.07 ?

=== other ===

hmm, basically...the same-ish LOL. prefere dvdnav barely...

now I'm 2:01:30.36 = 7290.36
mpeg 13791.14
split 3499.4
"should" sum to 7290.54, so I'm 0.2 too low, that's with adding it in.

I "could" fix it by not adding anything...it appears so, anyway, then I'd be within 0.02 the whole way...I guess...
either that or I got the split time wrong.

starts 5.994675 > 5.955780
  so about 0.04 ahead, but that's with the addition of 0.175 I think.
  what's up with the creep?
  
  
  

== converting dvdnav OSD ==

=c= 
A:3460.9 V:3460.85 A-V:  0.002 ct: -0.245 133/130 11%  5% 21.8% 0 0
NAV packet was 3456.800049, mpeg at 3460.896240 after -> 29.97 3460.256836
adding 0.210000 to 3460.715332
final: 3460.925293
A:3460.9 V:3460.90 A-V:  0.003 ct: -0.244 134/131 11%  5% 21.7% 0 0  => 0.025 off...


NAV packet was 3457.300049 (0:57:37.30, 3457.30), mpeg at 3460.937988 after -> 29.97 3460.757324 [           0:57:40.76 => 
adding 0.210000 to 3460.757324
final: 3460.967285 3460.967324 # math is ok... to 0.0001
A:3460.9 V:3460.94 A-V:  0.004 ct: -0.244 135/132 11%  5% 21.5% 0 0

 => 0.03 even

at beginning:
 mpeg at 76.314934 == 76.311020 => 0.003

=osoh=
 mpeg 72.853134 => my  72.865906 => 0.01
 73.437057 => my 73.449829 => 0.0128 too high 0.197228000000002 so maybe 0.19 maybe, from 0.28? from 

 at an hour about 0.01 ahead

 last NAV packet was 6001.466797, mpeg at 6007.647461 after -> 29.97 6007.468262
 adding 0.210000 to 6007.468262
 final: 6007.678223 => 0.03 ahead. hmm...

I wonder if it adds in the equivalent of the initial 0.28 back in by the end of the film. Oh man LOL.
  nope
  
last NAV packet was 6589.966797, mpeg at 6597.194336 after -> 29.97 6596.556641
adding difference 0.458984 adding 0.210000 to 6597.015625
final: 6597.225586

still 0.03 too high now.
I have no idea.


If I'm low, then just use theirs.
Else, add 0.

== 3600 dvdnav OSD ==

fascinatingly, playing dvdout seems to have exactly "on" OSD to the standard time on the console.  Exactly.
  Dunno
  then the OSD actually resets after the shift at 25:46.  Fascinating.  It's just using the mpeg for the OSD I guess (including its opening 0.28 extra secs)

 with -ss 3600 dvdnav://, it seeks me to V:3597.7 (should have 3.6 second diff) hmm...
    how does it do seeking today, dvdnav
    
    59:56.96, should be 59:56.4
      exhibits the weird freaky roundingness...almost a full second of it [?]
    maybe off then...
    
    
    that 0.96 could be coming off the 'real' stream
    YES IT'S LOCK STEP

with my stuff and dvd://, it shows the same "update only at 0.5s"
  hmm <sigh>
  with or without my patches, it sucks like that.
  and its seeking speed is abysmal... hmm...maybe that's just in debug mode? huh?
  but maybe accurate?
  
  so it's exactly the same fix...
  
  My easy fix would be to "remember" the last spot in the demuxer...maybe...
    The real fix would be to fix dvdnav
    
  dvd:// had the same "we're using the exactly wrong extension"
  
  dvd:// on seek to 3600:
     V:3604.21'ish [kind'er close to DVD time?]
  dvdnav:// on seek to 3600:
     V:3597.71'ish huh? implementation detail?
  
  should some stuff be moved to libdvdread from stream_dvd.c ?

=== workaround nav packets ===
  =osoh=
    NAV packet was 0.000000, mpeg at 0.033367 now 0.033367
    NAV packet was 0.000000, mpeg at 0.280633 now 0.280633
    NAV packet was 0.000000, mpeg at 0.314000 now 0.314000?% ??,?% 1 0
    A:   0.6 V:  0.31 A-V:  0.297 ct:  0.003   3/  3 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.347367 now 0.347367
    A:   0.6 V:  0.35 A-V:  0.264 ct:  0.006   4/  4 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.380733 now 0.380733
    A:   0.6 V:  0.38 A-V:  0.231 ct:  0.009   5/  5 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.414100 now 0.414100
    A:   0.6 V:  0.41 A-V:  0.197 ct:  0.011   6/  6 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.447467 now 0.447467
    A:   0.6 V:  0.45 A-V:  0.164 ct:  0.013   7/  7 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.480833 now 0.480833
    A:   0.6 V:  0.48 A-V:  0.130 ct:  0.015   8/  8 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.514200 now 0.514200
    A:   0.6 V:  0.51 A-V:  0.097 ct:  0.017   9/  9 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.547567 now 0.547567
    A:   0.6 V:  0.55 A-V:  0.085 ct:  0.018  10/ 10 ??% ??% ??,?% 1 0
    NAV packet was 0.000000, mpeg at 0.580933 now 0.580933
    A:   0.6 V:  0.58 A-V:  0.052 ct:  0.020  11/ 11 ??% ??% ??,?% 1 0
    NAV packet was 0.400000, mpeg at 0.614300 now 0.400000                **** BEHIND 0.21, though you'll notice 0.31 compared to 0.28 from the dumpstream...
    A:   0.6 V:  0.61 A-V:  0.018 ct:  0.021  12/ 12 ??% ??% ??,?% 1 0
    NAV packet was 0.400000, mpeg at 0.647667 now 0.433367
    A:   0.7 V:  0.65 A-V:  0.006 ct:  0.021  13/ 13 ??% ??% ??,?% 1 0
    seems those NAV packets are like 0.21 behind?
      so now they *match* the file based ones, that require an offset.  Oh man this is nuts!
      But the only way I guess...
      OSOH ffmpeg start: 0.280633
      still a couple of frames off though...
      mplayer: "0.28"
  =c=
    NAV packet was 0.400000, mpeg at 0.614300 now 0.400000  => 0.21
    "0.28"
    
  =jonah=
    "0.06"
    NAV packet was 0.866667, mpeg at 0.944217 now 0.866667 => 0.08 ? wow that is really late...
    
    NAV packet was 6.066667, mpeg at 6.983578 now 6.9508839% 13.5% 1 0
    NAV packet was 6.933333, mpeg at 7.000261 now 6.9333338% 13.6% 1 0
    
    clue! start: 0.060000
    
    so nav packets appear to suffer from that pesky offset....?
    
  =sintel=
   NAV packet was 0.500000, mpeg at 0.734067 now 0.500000 => .23 behind
   start: 0.300300 => seems to corrobrate...
     (unfortunately mplayer reports this one as "0.37" hmm... )
    
   NAV packet was 3.000000, mpeg at 3.503500 now 3.2669336%  7.6% 0 0 # 0.24 off
  
   @ 10 min's'ish
   NAV packet was 604.000000, mpeg at 604.837769 now 604.0000009 -> 604.60 # 0.23 off
  
   might be able to peel off more accuracy via
  
    sintel:
      NAV packet was 0.000000, mpeg at 0.033367 now 0.033367
      NAV packet was 0.000000, mpeg at 0.367033 now 0.367033  # we already get this one...
        and ffmpeg is at 0.30? huh?
      AVS says it starts at 0.40, which kind of corroborates mplayer...
      I'm ok with 0.07 missing I guess...they all seem to have this don't they?
        should I always subtract an extra 0.08 from it tho? yeah, really why would that be?
        0.28 -> 0.21?
        Jonah no, sintel yes, OSOH yes, c yes. I guess inferring is all right here?
        
        So basically, for me to currently accomodate for this, I'd need to pass it into mplayer, and it would have to add it back in.
          Until EDL tracks the accurate DVD time I guess.
          I'm good with being 1/10th out. No worries there :P
      
    OSOH:
      NAV packet was 0.000000, mpeg at 0.033367 now 0.033367
      NAV packet was 0.000000, mpeg at 0.280633 now 0.280633 # except it got this one right...
    
    
    
=c lightning =

dvdsampler
 25.57
 25 f13
 26 f7
 27 f13 + 4
 25 f13
   what in the heck?
 26 f7
 24 f20...if I hadn't seen it with my own eyes... LOL

ok now 

mpc-hc
 25 f6'ish
 25 f4'ish
 26 even.
    bworked again <sigh>.

mplayer raw, OSD corrected:
 23.22

somehow I "thought" maybe powerdvd was accurate but off by 0.5s?

====

It "might" round up the times.
  13 clicks to get to 00:01
  then like 30 to 00:01
     inconsistent?
    
dvdsample.exe 
  57:50 f10 (57:53.89)
was like 2 seconds ahead at =c= car turning left, front tire visible
  and like 3 seconds ahead at the very beinning?

mplayer:
  3471.92 console (57:51.92)
  54:47.92 OSD -> 3467.92 30 fps (29.92: 0:57:51.39 )
     no hiccups...
    
    mplayer OSD math might be messed up, it keeps jumping all around...
      these v bad:  Sherpya-SVN-r33574-4.2.5, and r Sherpya-SVN-r34118-4.2.5
      also with monster's inc.
      mplayer bug :P
      at least it's "always" 1s off.
      I think it's just with dvd's {both dvd:// and dvdnav://}
      
=c= offset:  start: 0.280633
  OSD seemed to start at 0.28, too, which is good/right

mpc-hc
 10 clicks per second [?]
  car 57:52 even
  
== c bright light on W ==
  10 f12
   6.37 mplayer
   OSD 7.37 huh?
  
 mpc-hc 08
  
dvdsample 14 f12 + 2 clicks to 14 f25, one click 15 f18, 
16 f12 + 8 clicks -> 16 f25

18 f17 + 58 clicks -> 20 f2
 this one is *way* too many clicks...maybe the update time is some type of suggestion?  Maybe it's off by negative one VOB unit?

 it "appears" to be advancing by one frame at a time, but its numbers are way whacked compared to powerdvd. Sorry!

== start times ==
titles 7,23 el materdor
7: 
 Duration: 00:00:02.05, start: 0.207756, bitrate: 79689 kb/s
23:
  Duration: 00:00:00.79, start: 0.203833, bitrate: 64868 kb/s
    not sure what this one means... hmm...
??
  Duration: 00:00:05.18, start: 0.203833, bitrate: 14484 kb/s

it seemed to have 0.0's for video when seeking in mplayer, but...umm...I'm not totally sure...

osoh:   ffmpeg start: 0.280633 [OSOH start]

sintel:
   1,5,7[big],: start: 0.300300
   3:  start: 0.367033

monster's inc:
  1,7: start: 0.280633
  
guess: progressive "standard" is 0.28, 0.30 is "standard" for true 29.97 
  
Jonah:
  track 1: Duration: 00:00:23.36, start: 0.060000 (mplayer says it's 0.1)
    dang no standard! :P
    playing with patched: A:   0.4 V:  0.06 A-V:  0.353 ct:  0.000   1/  3 ??% ??% ??,?% 3 0             
  
  
=== close eyes (OSOH) ===

mplayer full mkv:
  A:3600.0 V:3600.0
  A:3600.0 V:3600.0
  A:3600.0 V:3600 [?] => 0.08

ffmpeg -ss 3600
  0.05 in avidemux (even), 3rd frame in, just about right...

avidemux on full ts:
  1:00:00.433 # avidemux might not be reliable tho... this one seems freaky...
              # actually this might match the initial offset, but if it does...huh? 0.28 still a bit off...
              # maybe avidemux skips duplicate frames or something?
              # something is very bad here perhaps, also...probably that :P
    
mplayer full ts
  A:4200.0 V:4199.9
  A:4200.0 V:4200.0
  A:4200.0 V:4200.0 [?]
  seems to match the mkv

mplayer on dvd +- dvdnav
  A:3600.2 V:3600.2
  A:3600.3 V:3600.3
  A:3600.3 V:3600.3 => .35 => seems to corroborate...mplayer on the DVD's, at least, seems to have that extra timestamp in there.
    
  the DVD video seems to always start at 0.3  eh?
     A:   0.3 V:   0.3
     audio is typically 0.1s ahead, so not sure what's going on here...unless audio itself doesn't "start" until 0.9 for real...
     dvd/dvdnav both, and both audio and video seem to start at 0.3, though audio shoots up to 0.9 quickly [?]
  
  mkv/ts start at "0 even"
      if my hypothesis is correct
         i should see this on other DVD's
         the initial frames should already be off, time-wise

dvdout.mpg (mplayer dumpstream)
  A:3600.2 V:3600.3
  A:3600.3 V:3600.3
  A:3600.3 V:3600.3
  
== initial fade in ==

dvdnav:
  A:   1.3 V:   1.3 A-V: 
  A:   1.3 V:   1.3 A-V: 
  A:   1.3 V:   1.3   => 1.37

dvdout.mpg (mplayer dumpstream)
  A:   1.3 V:   1.3 A-V: 
  A:   1.3 V:   1.3 A-V: 
  A:   1.3 V:   1.3 A-V: => 1.37

avidemux on ts 1.376
  except avidemux was way ahead with the other one, too...
    except its first frame starts at 00.000 , then 00.041, then 00.082 ...
      and ffmpeg says the ts starts at 600.000
  
mplayer on {ts,mkv}:
  A: 601.0 V: 601.0 
  A: 601.0 V: 601.0 
  A: 601.0 V: 601.1
    => 1.10, which "might" corroborate ...
    
mplayer dumpstream:
  ffmpeg start: 0.280633 [OSOH start]
  mplayer says it starts 0.3 => seems to corroborate ...
  
what about handbrake? starts at 0?

makemkv (ripper) was heading me south, perhaps?
  does this explain Snow White?
  
This might explain DVD times not syncing right, as well... (the extra 0.5s it "says" it has, but then doesn't)

0.28 is not accomodated in sums:

handbrake 5fps:
  Duration: 01:53:11.60, start: 0.000000, bitrate: 223 kb/s
  A:   1.1 V:   1.0
  A:   1.2 V:   1.2
  A:   1.3 V:   1.2 => 1.25 but only 5 fps so POOR TEST

handbrake real:
  A:   1.0 V:   1.0
  A:   1.0 V:   1.0
  A:   1.1 V:   1.1 => 1.10 => corroborate, 
  conclusion: handbrake seems to be the same "resetting" it back to 0 from 0.3
  
G:\Video\OTHER_SIDE_OF_HEAVEN>ffmpeg -i title00.mkv 2>&1| grep Duration
  Duration: 01:53:11.31, start: 0.000000, bitrate: 7900 kb/s
    last frame: 01:53:11.708 162838
    first frame: 00:00.000
    
G:\Video\OTHER_SIDE_OF_HEAVEN>ffmpeg -i dvdout.mpg 2>&1| grep Duration
  Duration: 01:53:11.26, start: 0.280633, bitrate: 8202 kb/s
  avidemux says it starts at 0:00.000 and has 162740 frames [fewer frames?]
    seems to get to the end though...
    close eyes: 00:59:56.262 frame 86224 [this seems messed...]
    
NB OSOH appears to be all 23.97 fps    
    
G:\Video\OTHER_SIDE_OF_HEAVEN>ffmpeg -i title00.ts 2>&1| grep Duration
  Duration: 01:53:11.26, start: 600.000000, bitrate: 8126 kb/s
  
G:\>ffmpeg -i OTHER_SIDE_OF_HEAVEN-1.m4v 2>&1| grep Duration # 5 fps, so poor check...
  Duration: 01:53:11.60, start: 0.000000, bitrate: 223 kb/s # this one is elongated? huh?
  
avidemux says title00.ts versus dvdout.mpeg (OSOH) is 3 seconds longer.
  I wonder if it (has anything besides progressive but even more) has some frames that don't match perfectly
  which somebody is messing with? huh?
  
=== Monster's Inc. ===

{dvd,dvdnav}: A:   1.1 V:   0.3

castle:
  DVD
    A:   2.2 V:   2.2 
    A:   2.3 V:   2.3 => 2.30
 
ffmpeg on mplayer dump:
  Duration: 00:00:24.15, start: 0.280633

ffmpeg on mplayer dump, title 3, just a piece mind you :):
   Duration: 00:00:03.55, start: 0.280633
  
== Sintel ==

A:   0.4 V:   0.4

landscape: 
  DVD
    A:   3.3 V:   3.2 
    A:   3.3 V:   3.3 
    A:   3.3 V:   3.3 => 3.35
  handbrake:
    A:   2.9 V:   2.9
    A:   3.0 V:   3.0
    A:   3.0 V:   3.0 => 3.05
    
ffmpeg on dump:
    Duration: 00:01:00.62, start: 0.300300 (for OSOH dump was 0.280633)
  title 3:
    Duration: 00:00:21.22, start: 0.367033 [interrupted or not either way same, so can interrupt mplayer dumpstreams all right]

  0.08 variance so far?


  It seems that the start time "doesn't effect" the sum?


title 5, mouse teeny moveleft of box:
 sintel.5.mpg
                1.1
  A:   1.2 V:   1.1 A-V:  0.137 ct: -0.027 240/240  6%  2%  1.1% 0 0
  A:   1.3 V:   1.1 A-V:  0.124 ct: -0.023 241/241  6%  1%  1.0% 0 0 => 1.18

 title03.ts

  A: 600.8 V: 600.8
  A: 600.8 V: 600.8
  A: 600.8 V: 600.8 => 0.88

title03.mkv sum:
 mplayer A: 216.7 V: 216.7


does the grabber fill in blanks at the end or something?
  here's a clue, on the TS:
    A: 815.8 V: 815.7 A-V:  0.005 ct:  0.100 630/630 11% 44%  1.3% 56 0
    TS_PARSE: COULDN'T SYNC
    A: 816.7 V: 816.7 A-V: -0.013 ct:  0.079 659/659 11% 40%  1.4% 56 0
  except mkv seems to actually go through all the way.
  
is the 0.3 evident near the end?
thumbprint
  title03.mkv:
    A: 210.4 V: 210.4 
    A: 213.6 V: 213.6 
    A: 213.6 V: 213.6 => 213.63
    (which is around 3:33)
    
  dump.mpg
    A: 213.9 V: 213.9
    A: 213.9 V: 213.9
    A: 213.9 V: 213.9 => 213.98 => corroborate!

  powerdvd:
    3:33.8 27 frames, 33 total? huh?
    anticipate 0:03:33.84*29.97/30
    
TODO long movie, ending timestamps similar?

== mplayer dvd -ss seeking ==

if you pass it -ss 1:00:00 it seeks to 3604, i.e. it seeks I think to the 30 fps spot :P

But that's just with dvd:// with dvdnav:// it seems to be right on...maybe it has smarter seeking in it or something?

when seeking in the TS it started 0.4 past, but I guess maybe that's expected...

== netflix upscale notes ==

  netflix :width=>657 for "HD" that said it was playing in HD, eh? ... hmm...

 at home: never says playing in HD, but lines look really good full screen...hmm...
  
 hulu has "up to 480p" as options...hmm...
  360p speedracer displays as {:start_x=>535, :start_y=>328, :width=>542, :height=>410}
  480p speedracer displays as {:start_x=>524, :start_y=>331, :width=>550, :height=>408} (same)
    and always the same size minimzed eh...
    
 netflix instant 
    default minimum size is {:start_x=>38, :start_y=>109, :width=>649, :height=>372}
    Jonah is in hd 
     http://blog.netflix.com/2011/03/netflix-lowers-data-usage-by-23-for.html 1080p possible, typically it's 720p apparently [?]
     720p:
        2200 kbps/192 kbps
    while "buffering hd" it looks a bit jagged...hmm...
    if you drag, it loses and discards all buffering. yipes.
    "DIS" allowing HD at first looks junky, then looks really good LOL
    HD looks basically perfect, though maybe some sharpening or what not could help still...
      the lines look awesome to good (this is "apparently probably" 1080p
    non HD, with their upconversion
      lines look pretty good, maybe a teeny touchup
      coloring maybe a bit weak
      maybe barely non sharp lines
      no artifacts that I can tell
        might not need hqdn3d?
        unless they have/use their own...
      
    TODO CGI netflix instant 1080p
      compare HD and non...
      
    
== netflix instant vs srt ==

00:02:34,427 --> 00:02:36,361
l'm sor

init seemed 2:33 or end of 2:32

1.2s off init?

sire, seemed right on



01:00:13,950 --> 01:00:17,716
General lroh, l'm glad you could
accept my

seemed end of 12

this one (netflix instant) seemed to match up really well with the subtitles just about 1.5s "late" the whole time...

== compare upscaling settings ==

regular pullup not very good :P
just with hqdn3d, same low res, seemed not very good
I seem to slightly prefer DVD to directx upscaling (at least).  More detail.
  more hair detail, wood has more detail
    
with qt viewer:

  with 0001:
    1x and 2x seem same
      like identical
  with 26
    seem identical
  99: 
    2x seems to barely pull out more detail out of the metal...interesting...
    
with mplayer to view the jpg (direct3d)
  01:
    wow looks igualzinho weird
  26: 
    igualzinho
  99:
    igualzinho (too dark to tell...kind of weird there) -- ffmpeg bug?
    
  more hair, -ss 2:44 -frames 300
    I guess the same way, -> jpg, compare the jpgs in quicktime
      then tweak it be able to screen scrape it to compare [?]
  
    2x takes *way* way longer...
    
    00:
      if there's a difference, I can't easily see it in picture viewer
    75:
      1x has better "lines" than raw
      1x igual 2x (picture viewer)
    150:
      1x looks like normal LOL
      1x igual 2x hair
    225:
      1x looks better than normal (fruit)
      2x igual 1x
    299:
      raw looks BETTER wood-wise hmm...
      
    really need a better way to record maybe?
    make mplayer go really slow, and have ffmpeg record it from screen [?] -> jpg and hopefully it will catch everything...
      
== upconvert netflix ==

=== mplayer avisynth ===
  http://www.youtube.com/watch?v=hkOnH36S_pY&feature=player_profilepage
    mplayer's default upscaling seems to introduce wild dots..probably
    I think MS's bundled "magnifier" does some internal smudging for me, otherwise it would look awful
    mplayer at default seems to be doing weird things?
    paint.net on the win32::screenshot capture seemed to match quite well what the screen had.
    ffplay seems to show an exact verbatim copy...
    actually mplayer seems to be a good exact duplicate...maybe resizing hurt it though?
    
=== other ===


media player classic appears to have no cache.
"uscreencapture settings" appears to be per app, so lost with a .grf file save [?]
  or maybe appear to be overridden...by WMC, mplayer10, not virtualdub, not ffmpeg, yes mplayer
  works for a demo, long term probably will need my own filter :)
    though for now I could just tell them "ok download graphedit too LOL, run this in virtualdub, position your window up there"

virtualdub seems to get way behind...maybe it doesn't have the "framedrop" options that mplayer does?
"desktop source" does seem to work well mplayer, though perhaps still a bit jerky...
do I need to add a sleep in there? 
  http://www.eggheadcafe.com/microsoft/Win32-DirectX-Video/31543477/csourcestream-fillbuffer--settime.aspx seems to imply that I should...I think.
What matters is the delta from when the graph started running. http://msdn.microsoft.com/en-us/library/dd377506(v=vs.85).aspx

maybe VLC is just a lot more stingey...hmm...it's because it's the only fella I have actually trying to mix and match audio+video


I think I need to set mine to basically sleep until "almost it's time to do this" type of thing...maybe?

It only seems to make sense to me to go "only as fast as x fps" otherwise...you'll be giving them bogus data!  I cannot
imagine that you can depend on the renderer to "backlog" you to exactly as many fps as you need.
However, this doesn't explain VLC accepting these in such an awful way LOL.
Also, maybe implementing IAMLiveSource would help even VLC...maybe...?

It hates my filter! The only one it loves is that other one... <sigh>. Hacky work around it is then...


53 fps with "straight" mplayer go_raw
36.7 at upscale 1280 (1024?) (warmup?)
31.7 at upscale 1680
15.0'ish at upscale 3360
1280 27 fps

*maybe* hulu needs higher hqdn3d

ringing not caused by -ssf ls=75.0 -ssf cs=7.0, yes ringing with filter length 1
 no ringing if you double the screen res :) LOL

basically 100% cpu at 2x screen res fps or what not...kind of 100%...kind of not...
  13.3 fps 2048
  
1280 16 fps

hqdn3d,scale,hqdn3d = weird streaking stars!

-sws 2 2500 16 fps
  has striations :(
  
-sws 2 2500 hqdn3d after: 6fps, before: 22 fps

-sws 9 hqdn3d,2500 16.5 fps
  teeny striations
  
-sws 9 1024 24.6 fps
  not many striations...
  teeny but visible.
  1280 25 fps
    not many striations...yet visible indeed...
  seem to be better at 1024 than 1280...
  
flash can be made faster? http://forum.xda-developers.com/archive/index.php/t-1164908.html

it chooses 32 bits every time, even if I'm in 16-bit mode LODO

=== blttest ===
  one monitor: 160'ish fps capturing at 1680x1050 (no memcpy though!)
    same with aero on or off
    
  dual monitor: 640x480 800fps (no aero) 750fps with aero.
    however with mplayer it was like 14fps with aero, 53 without, and 55 with single monitor (?)
    TODO can I get that 800fps somehow? or can I live without it?

  350 fps aero dual monitor work desktop
  383/700 at times fps non-aero same [?] [just disabling aero auto-made my thing faster LOL]

== phreaky mplayer dvdnav ==

Tangled seemed to "not play without VLC help" at work, but not at home mac where it failed.
Snow White apparently failed quite well at work, however.  Man this is really really weird.


== real time subtitle ==
  0.4 extra + 0.5 not nuf blacky, marked one, hitchhikers

  flight:
    first:  second 168.0 -> 00:02:48.03 sez: 00:02:47,668
    last:  first 5151.2 -> 1:25:51.2 sez: 01:25:50,859

    sum additive needed:
      beginning: add to the end 0.25s
      end: add to the begining 0.35s

  mplayer uses  -framedrop -autosync 30 (no -mc) by default [!]
  
== ts vs. mkv transcoding ==
  mencoder fails c. mkv, succeeds c. ts (editing seems to succeed overall [?])
  I think if I *assume* stretching...hmm...it'll probably be pretty close...hmm...
  
== OSOH ==
  this one seems to show that the makemkv == ts == 29.97
  01:53:11.31, start: 0.000000 mkv
  ts  01:53:11.26, start: 600.000000 (essentially the same as above)
  makemkv11 01:53:11.31
  ts 11:  01:53:11.26
  VLC DVD sum: 1:53:05 -> 1:53:11.8 # rounding error?
  makemkv is quite close to @29.97 fps, which I think is "right"
  ffprobe -show_packets title00.ts
     7391.234311 -> 2:03:11.2 # oh that's comforting LOL
  only has one demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
    at the beginning
  
== C ==
  this one seems to show makemkv == (ts+0.2s) == 29.97

 vlc DVD sum 2:10:56 (-> 2:11:03.9'ish)
  so this time mkv was 29.97 fps accurate less 0.2s?
  
  
 AVS says ts and mkv off by 0.2s

 mkv 02:11:03.84, start: 0.000000
   AVS says it's 2:11:03.778
   maybe lightning strike 2:11:45.096
   720x480 [PAR 32:27 DAR 16:9], 8000 kb/s, PAR 186:157 DAR 279:157, 29.97 fps, 59.94 tbr, 1k tbn, 59.94 tbc (default)
     you'd think that'd be ok...hmm...
     or do the players trust it too mightily or something... [?]
   mediainfo: Frame rate                       : 29.970 fps

   mplayer: VIDEO:  [MPG2]  720x480  0bpp  59.940 fps  8000.0 kbps (976.6 kbyte/s)
     with no switching content messages...so I'm guessing makemkv just maps the given frames into mkv slots [?]
     that should be ok...unless it's getting its math wrong somehow...

 NB: had 4 back and forths telecined to progressive [I imagine telecined...]
    (also had at least one mplayer split)
 
 ts forceidx: 02:24:10.50 # 12 minutes too far! gah!
 ts idx:      02:24:10.50 # again!

 mkv11  02:11:03.84
   mediainfo: 2h 11mn yea
 ts11 
   Processed 188659 video frames
   02:11:03.62
 ts 02:11:03.62, start: 600.000000
    start 600? huh?
 vob [ffmpeg?] 
   02:11:03.77, start: 1.000000
 edited.avi 02:11:03.38
  forceidx.yo.avi (mencoder)
    02:11:03.40, start: 0.000000
 
 c.mplayerdump.mpg [in AVS] sum 2:11:04.89
   lightning: 2:10:45.079 (non AviDemux, so might be spot on)
 HBcli on dvd: handbrakecli --scan -i e:\ 
   02:10:56
 so makemkv is perfect @29.97 on this one?
 fulli
   title00.ts.edited.fulli_unedited.tmp.mpg 02:11:03.05, start: 0.233367
 
 maybe some are stripping trailing blackness? (about 2s'ish)
 mplayer dvd lightning: 2:10:36.0
   Warning! FPS changed 23.976 -> 29.970
   4364.7 it has a break in it though, looks like it anyway
  
 avi 02:11:03.38, start: 0.000000

 apparently had 24 telecined frames (maybe some more at the very beginning...)
   if those were assumed to have been 23.97fps, but were 29.97 fps 25% additive, or about 0.25s I guess
      might explain difference mkv and ts...

  hb ffmpeg sum: 02:11:04.60 [ai ai]
    lightning AVS: 2:10:44.9 (about 0.3 early ?)

 lightning 
   ts AVS: 02:10:45.302 ish
   mkv avs: 02:10:45.0 ish
   also avs says the mkv is 0.2s longer, really pretty close to ffmpeg's thing...
    
== snow white DVD ==
  has a plus 5 freako
  the TS *might* be right on, which would imply ts == 29.97, makemkv = ts*30.03, which somehow feels wrong...

  wall time latest: wrist watch started a tidge behind, ended up even further behind (powerdvd [5??])
    1:23:32 sum powerDVD
    *except* when you scan to the end, then it's 1:23:28 again
    my guess is powerDVD isn't keeping track except internally...
    seeking 1HR "good night" [good] night (her last one)
    yep it's totally internally inconsistent. Fascinating.
    apple dvd player too, IIRC
    
    with powerdvd 12:
      sum 1:23:30 now "reasonably strong" at least 0.5s showing 30, with an end of 1:23:28 advertised
      and if you seek to it, it gets to the "end second shown" 1:23:26 or 1:23:27 then "bumps" to 1:23:28
      yep, this may be still messed up!
        sniff...maybe...EDL's might still work, though...sniff...
  
  120180 frames in the ts
    -> 29.97 1:46:50 <sigh> (totally off)
  120183 frames in the mkv <sigh> LOL
  
 VLC 
    sum DVD: 1:23:28 sum (-> 1:23:33.0 TS) -> 1:23:38.0 freako
 mplayer makemkv: A:5018.0 == 1:23:38 sum
  oh I feel strange...
 too many mplayer splits in this one...
 mpchc 1:23:28 sum DVD
 mpchc 1:23:28 sum mkv [huh? this mkv thing is confusing me...]
 check subtitiles +- file against file, DVD snow white
   ffmpeg ts time: 01:23:32.49
   ffmpeg mkv: 01:23:38.07 differs from mpchc ? differs from VLC makemkv? TODO
 vlc mkv: 1:23:38
 vlc ts: no times
 ffmpeg mkv: 01:23:38.07
 ffmpeg ts: 01:23:32.49
    It appears that makemkv is making certain assumptions that may not be true here?

  makemkv says "length shall be 1:23:11" (oopsy)
  mediainfo mkv: 1h 23mn 38s 70ms

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. only one
V:   0.0   0/  0 ??% ??% ??,?% 0 0
  
  hmm...I'm beginning to wonder if maybe some are more honest than others... ?

  mac dvd player -> 1:23:38 "wall time" [?] anyway it was in lock step, 
    either 28 or 38 yipes probably...28 I'm thinking bit discrepancy in there 
    
  WMP wall time at one hour was 3s ahead of it now...
    which doesn't agree with mac dvd player? when OSOH they *did* agree? huh?
      how did this not agree with mac dvd player? what? that's not true, that's impossible LOL
    end WMP wall time: 1:23:32.8'ish ... sniff ... what the...
      WMP "says" sum is 1:23:28 -> 1:23:33.0'ish      
      
  top of hill "Of one love" mplayer
    mkv: 01:20:35.38
    ts: 01:20:29.8 # 30.5 ? hard to tell... it's pretty close at least...
      "should be" 01:20:30,831 NB the blu-ray subs seemed way different... blu-ray 01:20:14,276 whoa [3 different blu-ray subs agree...]
    powerdvd: 1:20:26 for that one
    
== iq ==

  this one mkv seems to have an extra second in there...
    1h 35mn 49s 596ms and "expected" it errantly to be: 1:35:52.4...it's like half and half!
    ts is 1h 35mn 47s 41ms which might be right on compared to the DVD
    so this one implies that makemkv is just messed up? huh? ts seems fine again...
    
  maybe sometimes mkv stretches it double in error somehow?
    maybe it has *both* problems...LOL
  
  wall time seems to be 29.97 (DVD player reports 30) first hour at least
    at 1:09 it appeared to be like 6s "back", though makemkv may have interfered slightly...
    at 1:20 7s
    sum: 1:35:49.14'ish walltime
  
  so maybe normal subtitles are from rips, which have been transcoded to precisely 23.97 fps,
    so my files aren't precisely that...we shall see if this hypothesis holds true...

V:   1.0  22/ 22 17302% 18%  0.0% 0 0


demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
V:   1.0  23/ 23 10748% 10%  0.0% 0 0                                          
V:   1.0  24/ 24 10319%  9%  0.0% 0 0                                          
V:   1.1  26/ 25 9846%  9%  0.0% 0 0                                           
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

  mplayer for the mkv seemed to creep up?  somehow it seemed to get messed up...
    TODO avidemux/quality editor for these various and its frames...what the?
    replaying mkv might not work so hot...
      maybe I can remux somehow first... [?]
      maybe it's because of all those transitions which caused lossy-stuff within the mkv... [?]
    
  can I use handbrake on mkv output? does it look better?  is it just this one dvd?
    does the mkv match DVD
    
  mplayerdump.mencoderforceidx sum: 1:39:17 (4 minutes extra...somethin went wrong...)
  DVD sum: 1:35:41 -> 1:35:46.7'ish, so maybe we're close...round up LOL
  mkv sum: 1:35:49 [partially expected, partially huh?]
  mkv mac vlc 1:25:20 ish [ugh]
    originally reports it as 1:35:35 in its dashboard, this is without daspi
  mac 
    DVD player: 1:35:41
      converted: sum should be 1:35:46.7
        and if again reconverted -> 1:35:52.4 [!]
    mplayerx cannot play DVD/seek right
    mplayerx on makemkv sum: 1:35:53
    vlc on makemkv sum 1:35:49
    mplayer command line makemkv end/sum TS: A:5749.5 == 1:35:49.5
    seems zactly the same
  what about ffmpeg against that thing?
  ffprobe mkv
    2810.792000 last video pts -> 46:50 or something [?]
  ffmpeg mkv->ts file: 01:35:47.09
  ffmpeg mkv: 01:35:49.59
    * maybe just this one is messed up? *

  AC3 can apparently have 6 channels: Decoding AC3 stream (track 2): Bitrate: 448Kbps Sample Rate: 48KHz Channels: 6
       Stream #0.1(eng): Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s    Metadata:  title           : 3/2+1

  midentify mkv: 1:35:49.6
    midentify ts: 1:00:00
    VLC doesn't get any timing info from it
    
 handbrake seems to be "smart" about it
  mkv "1:35:49" "results in 1:35:45"
  and ts "1:35:45" results in "1:35:45"
    except transcoded is 49 and 47 s. What? (47 might be expected...hmm...)

== mplayer EDL ==

this works, 1:00 type timestamps are ignored
# a comment
10 15 0 # a comment2 also works

mplayer crash on edl 10 15 0 wordworld welcome to wordworld mac+pc dvdnav (dvd ok) title 3

====

http://www.kdenlive.org/forum/xml-format-and-edls kdenlive supports EDL, apparently (video editor)


== upconvert mplayer ==

=== upconvert screen ===
  http://lists.mplayerhq.hu/pipermail/mplayer-users/2005-June/053776.html
  umm...mplayer doesn't seem to support directshow very well...as in, at all LOL.
  VLC at least *tries* to support it <sigh>. Oh give me a break. Oh well.
  I could either go with avisynth + MPC (I think)

=== upconverting to the huge monitor===

 with the black laptop:
   "normal" dvdnav seemed to work all right, slightly jerky at times.
  I think that upconverting to the little monitor used more cpu.
  Anything to the big screen maxed out the cpu.
  I "think" it looked better upconverted than not, big screen too, though both really pretty good.  Except the computer not LOL.
  
  work comp. can scale snow white like 30% cpu [is that out of 50?] to 1680...
    25% cpu at 1680
    1.5 res: 40%, tidge fuzzy
      2520
    2x res: 40%, awesome
    2160 doesn't seem as good as 3360. I don't know why...
    3360 -> 1680 in software is *way* too slow...
      3360 seems better, anyway...
    2160 versus 1680 didn't seem to make much difference...
    2520 vs 2880 versus 3360
    2520 38% cpu
    2880 looks pretty close...
      barely prefer 3360, but...it may have been a different frame
    barely prefer 2880 to 2520
    does 3360 drop?
      A:  14.6 V:  10.0 A-V: yep (work comp.)
      still seemed to use 40% cpu when multi-cored (sounds like an apple)
      -lavdopts threads=2 13.9 versus 14.2s for first 10s [yes! LOL]
    3360 seems smoother than 2880, like much less pixelated.
  
  TODO try various DVD's with 1680 versus 3360...are they all supah clear?
  
 roary, mac:
   1280: fine
   1500: toast speed-wise
   2500: fails

=== various options ===

 avisynth Defaults: HQDN3D(ls=4.0, cs=3.0, lt=6.0, ct=4.5) 
 mplayer
   hqdn3d[=luma_spatial:chroma_spatial:luma_tmp:chroma_tmp]
   mplayer defaults were: hqdn3d=4:3:6 hqdn3d[=luma:chroma:time]


   -vf hqdn3d=2:1:2 ("conservative" from http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html)

  an avisynth upconvert howto: http://avisynth.org/mediawiki/Enhancing_dvd_videos
  http://web.archiveorange.com/archive/v/JbcLEih3ZwhZlMuTkxzR says "if you're upscaling [to grow the image] then do denoise before scale"

 -vo gl fails on a mac [huh?]

 3360 looks quite crisp so far.
 3360 didn't seem to help 1024 [?]
   maybe nothing can help 1024?
   the book should have looked better than "normal" DVD
   couple compare 3360 with 2048 in 1024, see what happens there...LODO

 low cpu mode? unsharp filter without upscaling. [?]

 http://forum.beyond3d.com/showthread.php?p=1008342
    DVD: 
      lanczos 2, -vf size=0:1 [accurate rounding] ...
      3x resolution [!]
      "Luma Sharpen to 1.00-1.50 and Chroma Sharpen to 0.00. Enable Accurate Rounding."
         I don't know if accurate rounding is possible with mplayer+lanczos tho...
      hqdn3d put Chroma to 1.00, Time to 4.00 and Luma to 0.00.
        hqdn3d[=luma_spatial:chroma_spatial:luma_tmp:chroma_tmp] how?
      deinterlacing [I don't think this matters, really I don't]
    xvid:
      Denoise3D settings, put Chroma to 1.00, Time to 4.00 and Luma to 0.00.
      postprocessing "strongest" ("or SPP through usually broken")
      mplayer accurate deblocking
      lanczos luma 0.5-1.5 chroma 0, accurate rounding
      deinterlacing: - Set it to Framerate doubler, and "no motion estimation - blend images"

TODO http://lists.mplayerhq.hu/pipermail/mencoder-users/2009-May/010344.html says use pp=al after hqdn3d to help with trails/blurring

 TODO compare with mpc-hc with ffdshow...same?

 guess I prefer mplayer to VLC at this point anyway <sigh> EDL support is just better...
 is "-mc". It means "max A-V time correction per frame", and defaults to 0.01. For good input, you can go down even to 0.0001, but 0.001 i
  -vop denoise3d
  -vop hqdn3d
  http://freshmeat.net/articles/fine-tuning-mplayer

 -sws 9 lancosz

http://forum.doom9.org/archive/index.php/t-140961.html:
  says "if -ssf ls=90 doesn't sharpen, try a real unsharp filter"
  http://web.archiveorange.com/archive/v/JbcLEyHOOOqckAEhZ7Hd says the same thing. broken?
  LODO see if sharpen is working at all even

http://www.neowin.net/forum/topic/422992-a-how-to-guide-upconverting-video-using-ffdshow:
  denoise3d hq
    luma 7 chroma 7 time 5
  "specify size 1280x768" "no auto aspect correction" TODO why?
    might not matter? might let it "go full screen 4 sure"?
  lancozsa 10
    "Luma sharpen" and "Chroma sharpen" to 1.50 (out of 2.0)
  
http://blog.thewombat.org/2008/11/how-to-use-vlc-096-as-upscaling-media.html  
  "add a video post processing filter"
  "add a video scaling filter"
  "add sharpen as a filter" (manually)
  set sharpen strength to 0.15 (0.25 for hq)
  "set post processing strength to 6" (lower for lesser CPU)"

No. As long as the GL renderer works with your hardware/driver combination, it's a lot better then the directx/overlay renderer.
You might want to try "gl:yuv=4:cscale=5:lscale=5" for even better rendering quality...
http://forum.doom9.org/showthread.php?p=1089768:
  hardware gl: gl:yuv=4:cscale=5:lscale=5

This guy has some very aggressive sharpening parameters [LODO try out]:
  http://www.nrtm.de/index.php/2010/09/11/mplayer-aggressives-scharfen/

   "use the following syntax to playback DVD movies."
Code:
mplayer -pp 0 -vf-clr -vf pullup,yadif=1,hqdn3d=2:1.5:3,scale=-1:-1:0 -ssf ls=100 dvd://

Let us assume that hqdn3d=2:1.5:3 is a good way to clean up MPEG-2 and yadif=1 is a good decent de-interlacer. I would say that the following should work ok for most content.
mplayer -vf yadif=1,hqdn3d=2:1.5:3,scale=-1:-1:0
Maybe adding -ssf ls=100 will increase the sharpness of the content to bring out the details of the video. With mencoder, it is a little different on what options you can use compared to mplayer, so play around with the settings."

http://ubuntuforums.org/showthread.php?t=77329&page=6
  hqdn3d=2:2:3,pp=ac
     like this for anime...LOL I can see my jruby wrapper now...
  
hqdn3d[=luma_spatial:chroma_spatial:luma_tmp:chroma_tmp]
  
http://forum.doom9.org/archive/index.php/t-79335.html lists some less aggressive hqdn3d options...

#This sets the postprocessing into overdrive using all possible spare cpu cycles to make the movie look better
autoq=100
vf=pp=de,hqdn3d

http://freshmeat.net/articles/fine-tuning-mplayer:
  -mc 0.001 # except for slow CPU oh my! 0.5? seconds per frame...I guess this in conjunction with autosync...
  hqdn3d=3.5:7:5 # never > 15 for the last number
  comment:
     -vop pp=hb:y/vb:y and only on low-res (no post processing for HQ videos...hmm...)

-autosync 1 (or more) might resync my cruddy DVD's...
  seems to work! (mac)
 
  more [open]gl: "use these options" http://forum.doom9.org/archive/index.php/t-132325.html hardware renderer
  
  -vo gl by itself causes extreme stuttering and 100% cpu use on the work desktop...maybe not worth it, eh?
  
===
 hqdn3d=7:7:5 # 3.5:7:5 for mpeg??
 -sws 9
   -vop scale=10 # lancosz inensity 10...I think...huh?
 -ssf ls=75 # out of 100? scaling sharpen filter (luma) http://www.linuxquestions.org/questions/linux-software-2/how-can-i-get-top-quality-video-with-mencoder-636846/ uses 100 ...
 -ssf cs=75 # scaling sharpen filter chroma

post processing options:
  "-autoq -vop pp"
  "-vop pp=ab/hl"
  "-pp 6" # deprecated

ummm...does lanczos accept  -ssf ls=75.0 -ssf cs=75.0 ?? or do I still need to add an unsharpen filter somehow?

[swscaler @ 013a25f4]using unscaled yuv420p -> yuv420p special converter
  VO: [directx] 720x480 => 720x540 Planar YV12
  is definitely bad :P

none at all looks...pretty good...

https://discussions.apple.com/thread/1771812?threadID=1771812
  -zoom -sws 9 -vf scale=1280:720:::9:10 -ssf ls=74.0 -ssf cs=7.0
  +- for audio: -ac hwac3 hwdts
  how useful is post processing?
  # do I need hqdn3d at all here?
  do I run well on those images?
  is lancosz 10 best?
  
  -vf spp might help, use lots of cpu [?]
  
=== current sum ===
mplayer filename -autoq 6 -sws 9 -vf hqdn3d=7:7:5,pp,scale=1280:-1:0:0:10  -ssf ls=75.0 -ssf cs=75.0
or 
-sws 9 -vf hqdn3d=7:7:5,scale=1280:-1:0:0:10  -ssf ls=75.0 -ssf cs=75.0
or
-sws 9 -vf hqdn3d=2:1.5:3,scale=1280:-1:0:0:10 -ssf ls=75.0 -ssf cs=75.0

==== prop ====
"upscaling"
http://forum.videolan.org/viewtopic.php?f=14&t=23579&start=0&st=0&sk=t&sd=a
http://www.neowin.net/forum/topic/615696-permanent-upconversion-in-software/
http://forum.videohelp.com/threads/280895-Is-there-computer-dvd-software-that-will-upconvert-regular-dvds
http://forums.cnet.com/7723-7596_102-285455.html
http://www.avsforum.com/avs-vb/showthread.php?t=1060735
http://forums.macrumors.com/showthread.php?t=1129925
wikipedia LOL

== WMC/other EDL plugins ==

  http://superuser.com/questions/34128/xbmc-with-media-player-classic-home-cinema
  apparently mymovies can use power dvd, which seems an external app... http://www.mymovies.dk/forum.aspx?g=posts&m=127771#127771
  http://forum.xbmc.org/showthread.php?t=28795 XBMC doesn't support real-time DVD EDL playback at all <sniff> oh wait maybe it does now... http://forum.xbmc.org/archive/index.php/t-69388.html
  ps3ms edl might work too...
  http://cybernetnews.com/cybernotes-skip-commercials-in-windows-media-center WMC can do it too kind of? might apply to the mymovies community...though looks a bit hard :P 
    (it uses http://babgvant.com/Wiki/view.aspx/DVRMSToolbox/Commercial_Skip_Addin )
  mymovies/WMC to use external app...looks like maybe : http://www.mymovies.dk/forum.aspx?g=posts&t=10956
    from http://www.mediasmartserver.net/2010/01/29/guide-using-mpc-hc-as-your-video-player-in-wmc-media-browser/ which itself uses the "media browser" plugin
  appears that WMC *has* to use a plugin to launch an external app...and mymovies doesn't always even then [?]
  is thereatek upconverting? forget it either way LOL
  
== subtitle accuracy ==

  narnia dawn treader had 1 subtitle that was "hand crafted", had the wrong timestamps, but was more accurate.  
    The several others were accurate though.

== auto subtitle download for a DVD ==

  opensubtitles' viewer gets "nothing" for subtitles of DVD's...smplayer requires you to manually search, too...
  splayer doesn't seem to attempt auto-download either of subs for DVD's.  Feels so nice tho :P
  
== true dvdid ==

  dvdid /Volumes/BAM0NNM1
  3121d937|cc97b745 (seems consistent like a champ...)
  
==  ffmpeg vs. AVS vs. powerproducer zact timings...splitting fulli c lightning ==

  try with all x*y ways to do this LOL
  fascinatingly, on the mplayer dump file, the OSD doesn't work right, and resets. LOL
  mplayer dvdnav OSD:
    preceding: 02:10:36.-4
    actual strike: 02:10:36.00

== does it work with makemkv with ts muxer? ==

  OSOH/ title00.ts
    transition: frame 107798 00:59:56.863
    with ffmpeg 3596.82 seems to be in perfect lock-step with the other.
    both have sound.
    perfeito

== so...does it work with makemkv without tsmuxer? ==

  using -ofps 30000/1001 -mc 0 -noskip caused the audio/video to mismatch wildly :P
  extracting audio didn't play back in VLC with correct sig [which means nothing]
  me having to demux to *ts* is not an option :P
  mencoder1 -mc 0 -noskip title00.mkv  -ofps 24000/1001 -of mpeg -mpegopts muxrate=300000 -alang en  -sid 1000 -oac mp3lame  -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=1:vstrict=0:acodec=ac3:abitrate=192:autoaspect  -o something.mpg
    did *not* seem to work (avidemux: audio messed up, transition 86250 00:59:57.347 which is kind-er right...)
  to be continued...
  demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. OSOH only saw it once
  
== ja donatei ==

  ossfarm, putty, tons others, I think...

== ffmpeg vs. AVS vs. powerproducer zact timings...splitting fulli ==

  conclusion: 
    mencoder splitting for zact timing seemss off
    ffmpeg is consistent with ffprobe I...would guess.
      which *seems* to match the DVD "quite closely"

  note this was fulli from mplayer rip...though ffmpeg seemed to match better with both [?]

  transition on fulli:
    avs: 59:56.867, pp: 56.90, avidemux: 56.863
      maybe pp was .86 but didn't update its framing right?
  ffprobe shows possible vcodecs at: 3596.826 3596.793 3596.826 3596.8597 3596.893 3596.926 
    counting them: 107790 doesn't line up at all...10 frames off? it must duplicate some frames implicitly...
  ffmpeg at 3596.866 got avidemux's frame: 59:56.930 (107800)
  ffmpeg at 3596.83 got avidemux's frame: 00:59:56.896 (107799)
  ffmpeg at 3596.82 got avidemux's frame: 00:59:56.896 (107798) which seems to match ffprobe...and imply that 3596.826 is the transition frame [?]
   so basically everything is...one frame off? ffmpeg is one frame off from avs/others?
  mplayer DVD OSD: 00:59:53.25 (converted: 3596.84) V:3597.3 [V value huh? ]
    previous frame to transition one was 59:53:21 [pre-switch] (3596.80 converted)
    about one frame off avs/avidemux []
      . = frame advance in mplayer 
      
  title00.ts
    (non-finger frame)
    AVS on ts (not fulli): ffmpeg's 3596.82 frame is shown 57.042 [+ crash?]
    powerproducer: 57.0 even (meaning probably the frame before 57.03)
    mplayer: 4197.0 [second .0], (OSD from file)
    avidemux on .ts: 00:59:57.347 86250 (but the timing is always off for that one...)
    however with fulli I guess we're closer somehow magically [?]
    
    mencoder 3596.82 seemed *way* too early frame-wise...
      used: mencoder1 -ss 3596.82 -endpos 3 -oac copy -ovc copy  title00.ts.mencoder.fulli.mpg -o  title00.ts.mencoder.fulli.mpg.mencoder.3596.82.mpg
    NB: "non knuckles" *is* the first transition frame...
      and it "should" be OSD, above...huh? the ts file is off?
    
  title00.ts.fulli
    AVS 59:56.887 [phew pretty close again...what?]
    conclusion: the ts is a bit off somehow? what?
    powerproducer: 56.86 or 56.90
    
  AVS on original mkv:
    non finger frame: 56.966 (previous was .926)
  
== ? ==

mkv2vob just extracts singles, not re-muxes them [not useful here]
mkvmerge only ... [not useful here]

conclusions: mencoder -forceidx can make a copied rip file play great in mencoder [and presumably be cut right?]
  makemkv has no problems with/signs of internal resets.
  VLC playing any mpeg *file* is actually pretty close to right on [?]

dvdoutmplayer.mpg.mencoder.ofps.mpg did not save avidemux

VLC playing mpeg *file* is actually pretty accurate.  Oh the insanity...I guess the extra abstraction of reading from disc kills it.

mplayer playing mplayergrab *does* reset internally...and osd also fails...interesting...
  *however* running mencoder1 -forceidx c.mpg -ovc copy -oac copy -o c.mencoderidx.mpg *does fix it* (for mplayer anyway...)
    unfortunately unseekable in avidemux...
  makemkv doesn't reset ever...timestamps are I think 29.97 in that case (both OSD, other)
    tsmuxer on that *lacks* timestamps at all in VLC, mplayer is 10 minutes off, it's in french [?]
      splitting it goes a bit early (oh duh it has all the i-frames still...)
      
== splitting osoh/accuracy ==

old way: rip/fulli with mencoder dvdnav+fulli freaky, split with ffmpeg, join with mencoder

mencoder filename -of mpeg -mpegopts format=dvd:tsaf -alang en -nocache -sid 1000 -oac mp3lame -vf scale=720:480,harddup -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=1:vstrict=0:acodec=ac3:abitrate=192:autoaspect -ofps 30000/1001 -o something.mpg
  avidemux on this had way off audio--video looked ok
  avs on this: unseekable
  
ffmpeg -i filename -vcodec copy -acodec copy -ss 3595 -t 10 part1.avi
  transition at 1.835 frame 55 that actually might be right...wow it actually seemed to work I am *flabberghasted*
  avidemux can open it well
  AVS can open it, but not seek nor play it [useless]

the painful virtualdubmod: http://forum.videohelp.com/threads/326615-Play-an-MTS-file-frame-by-frame-displaying-timecode-or-frame-number

machete can't open mpeg avi's :(
  can't open anything from the old work flow...guess it's out.

0.0334 is length of one...except then it ignores that :P

ffprobe (dvdoutmplayer):
  I think pts is what matterz over dts
  duration_time doesn't seem to match LOL.
  3594.904978 3594.955022 [3594.988411 3595.038456] 3595.071822
  videos pts' at: 3596.906978 3596.957022, 3597.040456, 3597.073822, 3597.123878 so telling it 
  last video: 6791.515056 1:13:11.52, or possibly 6791.431644 1:13:11.43
    these don't match AVS precisely...no no...
  first video: pts_time=0.280633 though one was N/A, so what is AVS's 0.016 ? nothing matches? (unless they have some internal counter they're "matching" against it... hmm...)

double check AVS: 

  mplayer 59:56.991 (3596.991) (one at 3596.990411, next at 3597.040456 )
  mkv 56.971 (with lots of back clicks...) 56.987 with 14 clicks... I think hitting the stop button does reset it. clicks divide by 2?
    59:56.969 with lots of forward clicks...
    
  says sum is 1:53:11.334

"ideal" would be a transition at 1.987 I believe (off 59:56.987)

[-5,5]
  1.301 for (avidemux) change of scene for ffmpegdvdout.vlc.8.mpeg, ffmpegdvdoutmplayer.mpg
  2.102 for (avidemux) change of scene ffmpeg.mencoder.dvdoutmplayer.mpg [what is that anyway maybe fulli from dvdoutmplayer ?]
    that looks like an odd difference.  Except maybe they went in different directions searching for an iframe...

  ffmpeg splitting dvdoutmplayer.mencoderfulli.mpeg resulted in no audio avidemux, and the poor video that we saw before in avidemux [way off]
    $ created it with mencoder filename.whatever -of mpeg -mpegopts format=dvd:tsaf -alang en -nocache -sid 1000 -oac copy -vf scale=720:480,harddup -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=1:vstrict=0:acodec=ac3:abitrate=192:autoaspect -ofps 30000/1001 -o output.mpeg 
    mencoder splitting the same had audio [seemingly not accurate?], and the same way off video.  Seems that 
    *that* fulli is *honestly* messed [same as in how_to I believe] except now I try it again later and it works? maybe -oac copy messed it up?
    mencoder went really fast though :P
    did have oac copy tho...
    
  mencoder splitting OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi:
    audio was the same as the beginning of the movie LOL [needs to be re-transcoded?]
    transition: 00:00:02.080 frame 52...hmm...maybe 3 frames off/late? hmm...well 3 frames (maybe 2) is better than 9 uh guess (still only 0.1s which...maybe acceptable...)
    
 OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi.ffmpeg.10.mpg
    not even VLC can play/open it LOL
    $ splits it with ffmpeg -i OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi -vcodec copy -acodec copy -ss 3595 -t 10 OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi.ffmpeg.10.mpg
    that was handbrake I suppose...
    
  maybe I can survive with raw mpeg -> fulli ...
  
  AVS *might* be a tidge off, too...but I'm starting to think it might be spot on...but maybe not...

  avidemux on "mp4'ed" ffmpeg dvdoutmplayer:
    transition 00:59:56.963 # maybe machete was rounding this up?

  dvdoutmplayer.ffmpeg-copy.ffmpeg.mpg [NB avidemux likes this much better than avi!] 1.3s [like the old one...]
  
  with big avi's avidemux always says "rebuilding frames", also it did not fix avidemux to become frame accurate, with the normal lossless mpeg's in there.
    cannot avidemux seek, or rather it is truly painful! gah!
    cannot seeming AVS seek? dvdoutmplayer.ffmpeg.copy.avi

 OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi
   when played in VLC, seemed to transition at about 59:56.9'ish
  
 OTHER_SIDE_OF_HEAVEN-1handbrake.ffmpeg.fulli.avi.ffmpeg.10.mpg unplayable in even VLC

 dvdoutmplayer.mpg.ffmpeg.mpg.ffmpegcopy.10.mpg played fine 1.3s, maybe it's an mp3 ffmpeg splitter bug thing?
    from avidemux it's cutting at (albeit useless) 00:59:55.720 

  re-avi or mpeg'ing with ffmpeg doesn't save avidemux. k?
    plus re-mpegin'g it's unopenable with AVS Editor
  
  AVS can't seem to use dvdoutmplayer.mpg ?

== never try ==
  check if mencoder/ffmpeg go forward to backward to find the nearest I-frame...
  mencoder as ts muxer? vlc?
  virtualdubmod mpeg2...
  mkv to mpg? mencoder -ovc copy -oac copy -idx -o <name of the merged file> <files you want to be merged>
  mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001 http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html # should set it right :P
  I think ps > ts ? and VLC will trust it? [does it avidemux help?]

== makemkv to mpg OSOH ==

conclusions: 
  tsmuxer is quite good
  makemkv seems great frame-accuracy-wise
    also mplayer...
  makem4v -> tsmuxer -> avidemux isn't enough

tsmuxer cannot unmix handbrake's file.

ffmpeg seems out as ts muxer: https://ffmpeg.org/trac/ffmpeg/ticket/177, even with June 3 version
  Ffmpeg.exe -i myfile.264 -i myfile.aac -vcodec copy -f mpegts -acodec copy output.ts

mencoder "hurls" through it: 
  mencoder -ovc copy -oac copy -idx -of mpeg -o yo.mpg big.mkv
tsmuxer? 
  http://juliensimon.blogspot.com/2009/01/howto-converting-mkv-files-to-play-on.html
  http://www.smlabs.net/en/products/tsmuxer/
  
mkvtoolnix doesn't work...

maybe if I use ffmpeg to fulli it first...

My first question is...does handbrake and makemkv match, +- fulli

makemkv => tsmuxer => ts
  avidemux:
    still needed frame shifter...
    audio still off...
    transition 86250 59:57.347
  
I seem unable to very the frames of the HANDBRAKE one LOL.  It keeps segfaulting Avidemux no matter what it's status...
  plus I can't compare except by framecount, which is probably messed up anyway...hmm...

mkvextract{+...} over tsmuxer?

ffmpeg -r 23.976 -f h264 -i video.h264 -f ac3 -i audio.ac3 -vcodec copy -acodec copy -f vob output.vob 
tsremux ?
m2ts ?
H264TSCutter ?

speed indexing avidemux off blacky slow: 3 MB/s 
tsmuxer blacky fast -> slow: 8 min 37 secs for 5.33 GB
avidemux blacky fast: 38 MB/s...blacky slow started choking near the end...

== c ==

conclusions: mplayer's are consistent grabbing cross-platform
  makemkv is consistent size-wise, same boxes...
  vlc seems to always be consistent with itself, frame-wise
  vlc is off of mplayer/mkv by 0.3s, but not at the beginning so what the....
  can discard vlc dvd :)
  one frame off is probably ok/accurate.
  avidemux cannot read makemkv output.

timing "cairo next week" powerdvd, "10 %" vlc, mplayer's OSD "cairo next week" [!]
  mplayer1 dvd://1
  
  mpui has the same "crash" with dvdvnav...

vlc dvd-straight  dvd://f:\@1 --sout "#standard{access=file,mux=ts,dst=dvdout.vlc.dvd.3.mpg}" vlc://quit caused it to go past the end of the title and just keep looping oddly :P
  at the end there was a menu but only for about 5s...hmm...
  mplayer can't play it seemingly.
  avidemux thinks it's the menu, 1 frame long
  this is the loopy one
  vlc can play it at the beginning, seeking seems to end early or...take forever?
  
vlc dvdsimple
  that file plays in VLC without timestamps, with always 00:00, seeking takes forever :P
  plays in smplayer, timestamps/seeking way messed.
  avidemux: lookup and smile and breath 1:00:00  
  188642 frames 02:11:07.951 (should be 188654 but that's ok...)
  transition back 2:00:00.533 frame 172640 (same with second copy)
  at home: 15 MB/s, 39% cpu
  total: 188642 frames, 2:11:07.951
  end frames lookin' very black...
  lightning hits ground: 188097 02:10:45.220
  fading in c: 111
  
mplayer.raw: mplayer -dumpstream dvd://1 -dvd-device d: -dumpfile dvdout.mpg
 playable VLC, seeking a bit odd.
 playable mplayer
  says it's 1:27 total [disc break?]
  I do declare, it suffers from the same time repeat stuff that mplayer does
  and mplayer appears to exit if you go past the first's end timeout :P
  sound in sync
  can't seek [?]
  on the DVD it has about one disc break
 avidemux:
    says it's 2:11:09.828  188687 frames total
    2:00:00 look at him, he looks back, look at him "hey"
    transition back to him after 2: 2:00:00.909 frame 172649 hmm...
  at home: 8.6MB/s, 5% cpu [scawah slow!]
  D:\>md5sum  dvdout.mplayer.dvd.dumpstream.mpg  mplayer.dumpstream.2.mpg
  a147eb922cb00eff5d3a25e155390380 *dvdout.mplayer.dvd.dumpstream.mpg
  a147eb922cb00eff5d3a25e155390380 *mplayer.dumpstream.2.mpg
  total: 188687 frames 2:11:09.828
  fading in c: frame 111
  lightning hits ground: 188106 02:10:45.595 (vlc off by 0.375 ?)
  
they all have the beginning dot of the poof at 228...

handbrake at home: 6fps, 237K/s [compressed]/s

widely different sizes:

4786500 -rwx------+  1 Melissa        None     4901372252 Jun  2 20:54 dvdout.vlc.dvdsimple.mpg
4948560 -rwx------+  1 Melissa        None     5067325116 Jun  2 21:09 dvdout.vlc.2.mpg [loopy?]
   5372 -rwx------+  1 Melissa        None        5496968 Jun  2 22:05 dvdout.vlc.dvdsimple.mpg.idx
5102140 -rwx------+  1 Melissa        None     5224591360 Jun  2 22:10 dvdout.mplayer.dvd.mpg

good news is vlc didn't seem to crash anymore

makemkv -c-: 11 MB/s, [says 4.5x] no pauses, 13.5 MB/s, 14.5 MB/s, seems to grow as it goes... 19 Mb/s...18...11:31
  plays well with no freaky seeking in smplayer, timing "feels close or right on" white subtitles
  plays well vlc, same, but with yellow subtitles [subtitles always enabled by default???]
  avidemux
    appears to be a raw rip...
    opens very slowly in avidemux at home...feels longer...3 minutes to load each time?
    2:11:08.618 188658 frames total
    had to set it to 24 frames [? huh it worked once?]
    no video, audio jerky, r7149

makemkv -> tsmuxer -> avidemux:
  188657 frames total
  transition: 172649 02:00:00.909 [didn't have to adjust frame rate]
  lightning strikes: 188106 02:10:45.595
  jerky audio but works [and video works]
  
06/04/2011  11:26 AM     5,140,185,916 title00.mkv
06/07/2011  10:22 PM     5,330,395,396 title00.ts
06/07/2011  10:27 PM         5,659,886 title00.ts.idx
   5,140,185,916 title00.mkv other one, 934 on mac
  
They start the same, then consistently get 9 frames off at some "hiccup" point...so one is wrong...

dumpstream mac: [md5 reads at 23 MB/s]
real	45m56.187s
user	0m49.138s
sys	5m43.019s
a147eb922cb00eff5d3a25e155390380 mac.dump.mpg
  flash: 188106

vlc dvdsimple mac:
vlc dvdsimple://d:\@1 --sout "#standard{access=file,mux=ts,dst=dvdout.mpg}" vlc://quit
/Applications/VLC.app/Contents/MacOS/VLC dvdsimple:///dev/disk1@1 --sout #standard{access=file,mux=ts,dst=dvdout.dvdsimple.vlc.mpg}
seems to be writing at about 4 MB/s, is in super time, 28% cpu
  55-32 = 23 minutes 
  lightning: 188097

makemkv mac: 3.9 MB/s  [2.9x]...5.0 MB/s...40% cpu
 5140185934 Jun  4 14:29 title00.mkv
 5140185934 Jun  4 22:29 title00.mkv # that's nice...pretty close :P
 avidemux (old) no video, tsmuxer doesn't work, so can't tell if accurate.

  via tsmuxer pc: 015257ed8192206d8b6f1d25ce2800a0 *title00.ts
    correct frame-age 106
  *can* edit it via avidemux mac
    correct frame-age 106
    md5[sum] takes 8 MB/s read speed [a bit slower than the desktop felt like half'ish for indexing]
   mac tsmuxer MD5 (title00.ts) = 015257ed8192206d8b6f1d25ce2800a0
 
avidemux matroska from blacky fast drive: 35 MB/s
copy blacky slow drive to fast: 30 MB/s (until hit non defrag is my guess, then lik2 2 MB/s)

== disc id ==

http://forums.thetvdb.com/viewtopic.php?f=8&t=1726&p=25563#p25563
  seems to imply that their disc id field is currently useless...not sure they'll be useful to me at all then...
  
== VLC as a ripper ==

Can't figure out how to use the gui at all, files are always blank or not there? yipes.
Looks like dvdsimple still uses dvdnav so we should be all right with dvdsimple I think.

== ripping sintel ==

thoughts:
  VLC cuts off a bit at the end, it appears
  mencoder seems a bit trippy, also cuts off the end [?] huh?

makemkv: [says 14.7 MB/s]
  avidemux: cannot seek easily, audio seems right on, cannot see video
  2,277,725,773 title04.mkv
  2,277,725,773 title04.mkv # accurate size...
  5a25ac6a97dea8989fa18d35562eb9a0 *Sintel_NTSCa\\title04.mkv
  e08d829137b8c1f0008d4bd974f8a0ba *Sintel_NTSCb\\title04.mkv

handbrake has "inconsistent" output (timings seem fine, however, huh?)
  05/25/2011  01:20 PM       223,727,993 Sintel_NTSC-2.dvdcss.2.m4v
  05/25/2011  01:47 PM       223,728,412 Sintel_NTSC-2.dvdcss.3.m4v
  05/25/2011  01:01 PM       223,727,952 Sintel_NTSC-2.dvdcss.m4v
  05/25/2011  12:13 PM       223,727,148 Sintel_NTSC-2.m4v
  # pretty close though
  213M May 25 13:01 Sintel_NTSC-2.dvdcss.m4v
  213M May 25 13:20 Sintel_NTSC-2.dvdcss.2.m4v
  avidemux:
    sound and audio work! :P
    "voice" at 14:33

vlc Sintel.handbrake.m4v
  14:33 "voice"
  15:02 total, got to the "real" end

using mencoder for raw copying seems...to not work so well.  Maybe it was warning me how cruddy it is.
  it's either mplayer or VLC uh guess. I think.

vlc dvdsimple.1
  avidemux:
    26607 frames
    sum 14:47.787 [bizarre]
    sound is on
    voice 14:33
    seems to go through to the end
  vlc to play:
    no timing info, seems to go through to the end
    
vlc dvdsimple.2
  avidemux:
    26607 frames
    sum 14:47.787
    "t" 14:39

mencoder dvd/dvdnav has *tons* of 
  ERROR: scr 137.884, dts 0.000, pts 137.022

  1 duplicate frames(s)!
  Post: 321.7s 1000f... [normal status line]

  at least it says "success" at the end yipes. Yiperipers mencoder.

mencoder.dvd when replayed with WMP had messed up audio, same with mencoder.dvdnav

mplayer dvd played fine with WMP

sintel has 3F2R/LFE audio

dvdout.mencoder.straight-copy.dvd
  avidemux ends too early 13:26 huh?
    switching to 24fps doesn't help...
    24180 frames
    audio is in perfect sync
    avidemux doesn't show as much of the end as VLC does huh?
  in VLC has no sound at the end ** loses end **
    ends early still, just cuts out at 14:47
    "your voice" at 14:33
  
dvdout.mencoder.dvdnav
  avidemux 13:54
  25005 frames
  I will be listening for the drum...

dvdout.mplayer.dvd
  avidemux:
    27030 frames
    15:01.901s
    "voice" 14:33
  vlc
    "voice" 14:33
    15:01
  ffmpeg
     Duration: 00:15:01.63, start: 0.300300 (like 15:01.93?)

dvdout.mplayer.dvd.full.2
  avidemux 27030, 15:01.901

dvdout.mplayer.dvdnav.2
  avidemux 
    27030, 00:15:01.901
    "voice" 14:33

sintel_open_source.fulli_unedited.tmp.mpg
  avidemux
    26607 frames, 14:47 (is complete)
    audio is absolutely off
  VLC
    audio is on
    total 14:47 (complete ?)
    your voice 14:33
    what the....it's on but then too short but it's not?
      guess is it's "ok" but indexed poorly somehow...
      this is ridiculous    

mplayer rip's seem to be md5 consistent, with dvd and dvdnav (though slightly different)

handbrake md5's/sizes don't match...
  ba99d43dc28d8407be7e194008594615 *Sintel_NTSC-2.dvdcss.2.m4v
  657bba230231ac18669de6a6c86f81bc *Sintel_NTSC-2.dvdcss.3.m4v
  6ec89d2ed2fcb7a468f2ee0d98a997f7 *Sintel_NTSC-2.dvdcss.m4v
  4bb9f388ee964697f21129fd4b9caacc *Sintel_NTSC-2.m4v

109242 -rw-r--r--    1 packrd   Administ 223727148 May 25 12:13 Sintel_NTSC-2.m4v
109243 -rw-r--r--    1 packrd   Administ 223727952 May 25 13:01 Sintel_NTSC-2.dvdcss.m4v
109243 -rw-r--r--    1 packrd   Administ 223727993 May 25 13:20 Sintel_NTSC-2.dvdcss.2.m4v
109243 -rw-r--r--    1 packrd   Administ 223728412 May 25 13:47 Sintel_NTSC-2.dvdcss.3.m4v

== timing dvd player time versus clock/wall time: ==

at 1:44:00 or so I seemed about 6s ahead. yup yup.
  at end, I had like 1:53:20'ish'ish [?] (ok probably like 1:53:11 but who knows for sure :P)

appears that 29.97 is closer to "wall clock time" and DVD players tell you 1:00:00 when it has taken you 1:00:04 in reality.
  at 1:00:00 wristwatch was about 4s ahead

== using handbrake's file for splitting ==

I think it's accurate...and with conversion to fulli editable in avidemux :P

using ffmpeg/mencoder against handbrake, they seemed to be a few seconds forward I think...sigh...
  TODO figure out how to use handbrake, if I ever need to <sigh> it's almost user friendly, dang!
  TODO try the parsers on the...handbrake fella somehow? avidemux?
  maybe convert to mpeg or something +- GOP 1
  maybe handbrake is "reading my mind" time-wise and inserting 30fps timestamps on each frame?

handbrake -> ffmpeg I think sameq -> ffmpeg split
  avidemux:
    1.96
    same with same file split again...hmm...at least it's consistent...
  vlc:
    no audio
  mplayer:
    I o[o]nce was lost

handbrake -> ffmpeg I think sameq -> mencoder split
  audio is the beginning LOL
  avidemux
    2.04 [pretty close...interesting]

== blu subtitles versus dvd ==

=c= [2004] {English} [XviD].srt doesn't seem to match up with mplayer OSD, like 6 seconds off per hour?
  mplayer OSD seems way off...or actually match normal players whoa!?
865
01:28:47,322 --> 01:28:48,864
… we have…
866
01:28:49,908 --> 01:28:51,325
… dragons.
dvd subs:
869
01:28:47,602 --> 01:28:49,126
<i>...we have...</i>
870
01:28:50,205 --> 01:28:51,604
<i>...dragons.</i>
0.3 off?

how to train dragon DVD srt right on with mplayer DVD 29.97

== mplayer dvdnav  ==

mplayer os x extended has the same "where am I?" on this DVD problem mplayer has.

monsters' inc. plays fine with CCCP+WMP in XP.  No 'where am I?' syndrome.

== avidemux on ripped files ==

my *guess* is that any transcoding will save it, anything else won't :( [bounty is out for it though!]

avidemux barely off lips:
  mencoder -forceidx -oac copy -ovc copy  dvdoutmplayer.mpg -o yo3.mpg is unseekable
  ffmpeg -i dvdoutmplayer.mpg -sameq yo.mpg took forever, grabbed wrong audio track :P

avidemux from all "normal" rips are still off frame-rate wise somehow...

  "wretch" and "me" were visually on, WMP, VLC, VLC on a VLC grab was either on or really really close, mplayer is right on with the DVD

  handbrake file:
    segfault

avidemux on dvdoutmplayer.mpg
  sound right on 1:00:00 wa[a]s lost, looks good.

avidemux on mplayer grab:
  sound ok, lips off
  top C of cast: 156622 01:48:52.449
    
avidemux on VLC grab:
  1:00:00 "once wa[a]s lost" audio, video appears messed up lips [looks like they are really grabbing raw data]
  top C of cast: 156622 01:48:52.449

== AVS vs. avidemux OSOH/attempt fix avidemux ==

  powerproducer has an edit option, seems accurate [!] 59:56.96 transition, audio is on

  AVS
    59:56.981 transition with OSOH.handbrake.m4v
    seems to get the audio right LOL. No frame counts but does seem to have frame accurate seek/timing
    59:56.97 mplayer grab [!]
  
  AviDemux ffmpeg.fulli 59:56.96 without frame adjustment [!] (prolly doesn't even need the fulli, it's just the consistent frames it needs [?])

  mencoder/ffmpeg "save" avidemux without fulli?
    maybe mencoder with -idx is good nuff to fix it for avidemux?

  ffmpeg on OSOH.handbrake.m4v *fail* 12GB, freezes Avidemux, no video VLC
  
  ffmpegifying mplayerraw: no audio in avidemux, same frame: 28650 00:59:57.347
  [mencoder, ffmpeg both maxed out on cpu with no transcoding [?]]
  
  mencodefiying mplayerraw (mpeg -> mpeg): 
    mencoder1 dvdoutmplayer.mpg -o dvdoutmplayer.mencoderified.mpg -forceidx -oac copy -ovc copy
    lots of "1 duplicate frame(s)!"
    unseekable, with jerky video
    
  OSOHhandbrake.m4v
    avidemux:
      00:59:57.130 for  [close but no cigar]
    AVS
      loaded great. transition 59:56.987 
    machete 
      won't open the mkv file

  playing OSOH with mplayer resulted in *one* mpg_demux switching frames message, at the beginning...and yet this means avidemux was hosed?
    I guess so, since its audio was very accurate, it has no video adjust, it is hosed.s
    
  AVS dvdout.7.mpg
    transition: 59:56.994 [appears right on, this is accurate]
    
  mencoderified mpeg fulli:
    had to set frame rate to 24.  Actually that didn't work it was just broke
    audio right on though
    so non editable avidemux
      actually it shouldn't matter, since we just use this internally, and ffmpeg likes it,
      maybe they can only use the original for editing
      assuming it still works to cut it well though...
  
  ffmpegified dvdoutmplayer avidemux (mpeg -> mpeg no transcoding):
    no audio, transition at 86250 00:59:57.347 (exactly same as normal mpeg)
  
  avidemux on mkv raw sintel:
    no video
    
  avs on mkv raw sintel:
    seems to work great, took awhile loading :P
    
  avs on dvdoutmplayer.mpg:
    cannot seek
  
  avs on mencoder.fulli.mpg (of the above):
    cannot seek or play...is this normal? Is it just me?
  
== DVD player versus PC player various times ==

conclusions:
  VLC's are all pretty consistent across platforms/versions
  VLC DVD playback can be 30s off
  mplayers are at the 29.97 offset
    I think mplayer.exe's are pretty consistent across platforms/versions
    smplayer off a tidge, of course, blame on being a GUI
    dumpstream is md5 accurate, length accurate too
  WMP is pretty close, but internally inconsistent by some odd
  powerdvd is pretty close but internally inconsistent by some odd factor.
  mplayer grab seems very consistent, and "correct" (well, when played back with VLC, so loose rating there).
  mencoder didn't grab it all the way? but is md5 accurate, even with dvdnav or without [can disregard]
  VLC grabs it fine
  WMP on handbrake'd is around 29.97 -- couldn't play back the mplayer grab, guessed on the VLC grab
  fulli on handbrake does "save" avidemux [full editable] [unfortunately that's handbrake...]

speeds: ffmpeg: vertex 2 SSD: 105MB/s old HD desktop 58 MB/s

I wonder if mplayer is just a little bit ahead, or internally inconsistent based on poor seeking for GOP's or some odd...it's either right ahead or right on?

appears smplayer is "like a second" or something behind mplayer, and mplayer doesn't quite agree with VLC but is pretty close, and mplayer.exe seems internally consistent.

are all windows GUI wrapper players internally inconsistent, except maybe VLC which is still itself "a tidge off"?


== OSOH ==

  mplayer1 to play mencoder.dvdout.8.part.mpg had timing that was totally wrong/unseekable
  mencoder.dvdoutmplayer.part.mpg was unseekable in avidemux

  mplayer -> mencoder
    see above
  mplayer -> ffmpegify
    see above

  makemkv -> tsmuxer -> mpg:
    162838 frames total
    avidemux:
      audio off [as expected]
      59:57.305 transition
      top C of cast: 156622 01:48:52.449

  avidemux mencoder.dvdout.2.mpg
    transition 00:59:57.389 86251
    total frames 148031 
    file was truncated but said it got to 100% [?]
    mencoder1 -ovc copy -oac copy dvd://1 -dvd-device e: -of mpeg -o mencoder.dvdoutmplayer.2.mpg
    VLC "thinks" it's 1:53:11 sum, but only can play to like 20minutes off the end, also VLC cannot play the audio right? [avidemux can tho]    
    1 duplicate frame(s)!
    Pos:7470.6s 162842f (100%) 74.28fps Trem:   0min 5958mb  A-V:-0.060 [6767:448] # dvdnav:  162843f
    only 6.1G compare to normal 6.8
    mplayer can't play it back with right audio, either :P
    re-doing it didn't help. This way is hosed :P
    ripping it this way and dvdnav were both really jerky...dirty?
    7b11bc3c0d05df5f6667f5ccb15ec6e9 *mencoder.dvdout.3.mpg
    7b11bc3c0d05df5f6667f5ccb15ec6e9 *mencoder.dvdout.2.mpg
    7b11bc3c0d05df5f6667f5ccb15ec6e9 *mencoder.dvdnavout.1.mpg # !
    when played back within VLC, audio gets out of sync when searching [plays from beginning ignoring seeks [?]]
    goes to he's crying, a tear, leans in for beijinhos numa moca <snip>

  windows movie maker, dvdout.8.vlc.mpg
    1:00:00 sweet that sound that [s]aved a wretch
    kinder close to VLC...

  VLC on OSOH-handbrake.ffmpeg.fulli.avi
    1:00:00 is smoking "up" apex [audio is absent, which looks like "wa[a]s" lost actually...hmm...we might be able to salvage this...]
    transition: 00:59:56.96 frame 89924 (but shouldn't match, since this one has accurate audio...)
    
  AviDemux on OSOH-handbrake.ffmpeg.full.avi
    1:00:00 saved a wretch [like] me (audio is way off the video, and off accurate)
      video is smoking "up" apex [right]
      transition 59:56.96 frame 89924
      169781 total frames :P
      didn't require video frame rate adjustment
      so fulli'ing it didn't seem to hurt it, this way...

  mplayer.exe2 dvdoutmplayer.mpg:
    1:00:00 I once [w]as lost but now

  some mplayer.exe's may have been  Sherpya-SVN-r33216-4.2.5
    versus Sherpya-SVN-r30369-4.2.5 for smplayer
    they seem pretty close though...

    smplayer's mplayer.exe on mplayer file:
    1:00:00 I once [w]as lost but now

  smplayer's mplayer.exe on VLC file:
    unknown timing (no times), but lips are in sync
    
  smplayer's mplayer.exe DVD:
    1:00:00 I was wa[a]s lost like perfect --- I was w[a]as lost -- I once [wa]as lost like every time the w, or just right after it... 3/4 of the way through the w

  WMP on handbrake:
    1:00:00 I was wa[a]s lost

  WMP on VLC file:
    1:00:00 that saved a [wr]etch like me --- that save[d] a wretch like me [huh? it's guessing, like VLC does?]

  WMP on mplayer file:
    cannot seek

  smplayer DVD
    1:00:00 once was [lo]st

  smplayer playing VLC grab:
    lips are in sync 
    searching is "odd"
    1:00:00 once was [l]ost --- once was []lost --- once wa[s] lost
    
  mplayer.exe playing any VLC grab:
    the timing are all messed up, starting at 47453, but it appeared to be right one somewhere "once was lost"

  the mplayer grab can be frame accurate, with matching md5's (I think it's actually mpg) dvdoutmplayer1.avi  dvdoutmplayer.mpg
    87402c45126207884bacc46e6f681722

  vlc grab appears to have the exact same file size, different md5sum's [!] dvdout.vlc3.mpg  vlcdvdout2.mpg
    1b32659b94ea01b45e2860809db49539 *dvdout.7.mpg vlc
    eb4ff70f8bfb1147294d218242492322 *dvdout.8.mpg vlc
    bdcfadd21f09de4de011694af75b67cd *dvdout.vlc3.mpg # they seem to all work fine...
    same sizes though...
    05/16/2011  08:54 AM     6,890,419,584 dvdout.vlc3.mpg
    05/16/2011  03:16 AM     6,890,419,584 vlcdvdout2.mpg
    
    
  vlc doesn't have timing replay info for dvdout.9.mpg (its own grab) just approximates
  
  dvdoutmplayer2 seems corrupt (garbled, too short, green)
  
  WMP dvdoutmplayer1.avi works (doesn't know how to seek), VLC works 29.97

  smplayer from dvdoutmplayer1.avi:
      1:00:00 once was [l]ost  --- once was []lost (because of smplayer?)
      seeks fine

  VLC from mplayer grab:
    1:00:00 once wa[a]s lost 
    
  VLC reading OSOH from handbrake m4v:
    1:00:00 I once w[a]s lost but now --- I once [w]as lost but now am found -- I once wa[a]s lost
       [pretty close to 29.97, maybe within GUI incosistency consistency]
    1:53:11 sum [?] (accurate with mplayer!)
  
  VLC reading OSOH from handbrake m4v after an "oac straight copy" from ffmpeg:
    I once wa[a]s lost
  
  smplayer from DVDD:
      1:00:00 I once was [l]ost but now

  avidemux reading OSOH from mplayer grab:
    1:00:00 accurate wa[a]s lost audio, video way off LOL
      copy and paste also unfortunately video inaccurate <sigh>
    transition 59:57.347  86250
    total frames 162840
      
  avidemux reading OSOH vlc grab:
    1:00:00 accurate wa[a]s lost audio, video way off LOL
      copy and paste also unfortunately video inaccurate <sigh>
    transition 59:57.347 frame 86250
    total frames 162835 dvdout.8.mpg, dvdout.7.mpg too  
    
  avidemux reading OSOH from handbrake.mkv straight:
    1:00:00 accurate wa[a]s lost
    162840 frames
    transition: 00:59:57.130 (frame 86252) only about 3 frames off...
    audio and video were
      
  ffmpeg reading OSOH from handbrake m4v:
    1:00:00 I once [was] lost but now (no audio though but looks like it would be accurate...)
    
  VLC reading dvdoutmplayer.mpg, handbrake m4v:
      1:00:00 accurate wa[a]s lost

=== All DVD players' comparison below this ===

  Mac's DVD Player total:
    1:53:04 (almost 5 I think) [barely shows 5 at the beginning]
    1:00 once was lost but now[ow] am found, possible slight hiccup immediately after
  mac mplayer:
     total: 6791.6 1:53:11.6
      1:00:00 that saved a wretch like me, I once [w]as lost
      other "normal DVD player" this is at about my 3604.7
  VLC mac:
    at beginning, seemed to think it had 1:53:05 left negative
    sum: 1:53:04 but it seemed to be cheating...I think it was cheating near the end, too :P
    1:00:00 saved a wret[ch] like me
  Emerson DVD player:
    barely displayed the 4 of 1:53:04
    1:00 once was lost but no[w] am found
  VLC XP 1.1.7
    1:53:05 total
    1:00:00 saved a wr[ehhh]tch like me 59:49'ish on others I think.
  MPCHC
    1:53:05 total
    1:00:00 once was lost but n[ow] am found beginning of oh on now
  WMP CCCP
    1:53:05 total
    1:00:00 once was lost but [n]ow am found [quite close to above I think, might be normal]
  smplayer XP:
    1:53:05 total [!] fake total
    unable to seek [crash]
  mplayer XP
    1:00:00 that saved a wretch like me, I once [w]as lost
    sum: 6791.6 (= 1:53:11.5)
  mac mplayer extended:
    sum: -1:53:05, in reality went to 1:53:11 :P
    1:00:00 that saved a wretch like me, I once [w]as lost
    
  [should be 3.6 off per hour, 6.8 for osoh's sum, is 6.6 'ish :P]
  
  WMP windows 7 DVD:
    -1:53:05
    1:00:00 once was lost but n[o]ow am found
    ended with last second at 1:53:03...interesting.
  powerdvd 8:
    ended with last second at 1:53:03...interesting.
    1:00:00 once was lost but no[o]w am found
  VLC 7 1.1.9 DVD
    that saved a wre[tch] like me
    exhibits same odd lagging timestamps at end.
  
tron

  WMP
    15: knock knock, hey carl shows something, [switch scenes]
    seek with WMP itself seems about 10s off late, but consistent
    
    60: and not just for me...[] what do you mean?
    2:00:00 Beau Garrett last just barely all left of straight center
    
  mplayer:
    15=900: see above exactly
    60=3600: the golden ticket the way out []
      "not just for me" is about 3603
      
    2:00=7200-4749=2451: bruce boxlightner barely left, half way to next
      2458 is beau garret done about
      
  VLC    
    15: knock [knock] hey carl  
    60: so it's open now[] not for long
      1:00:26 not just for me
    2:00:00 james fran middle
      boxlietner 1:59:55
      beau 2:00:04
      
  powerdvd:
    15: hey carl [switch scenes]
    60: not just for me [] what do you mean
    2:00:00 beau garrett stage left

Jonah:

15, 30, 45
 k-lite XP mplayer:
 15: before you [eat]
 30: a man that .. can count on to deliver his message yes [well]
 45: big smile from after duck
 
DvdSample (k-lite xp)
 15: before [you] eat
 30: a man that .. can count on to deliver his message yes [well]
 45: big smile from after duck

VLC
 15: and [if] you follow god's commands (early?)
 30: something about nineveh makes you feel sad [I dont' really ] want to talk about it [?]
 45: fire 3, I'm coming traveling buddy [flash back to them] (in wmp this is at 44:27) 

smplayer, mplayer r30369
 15: wash your hands [before] you eat
 30: a man that .. can count on to deliver his message yes [well]
 45: big smile from after duck

mplayer
 45: middle of squeak of duck

hulu
 15: wash your hands [before] you eat
 30: a man that .. can count on to deliver his message yes [well]
 45: just before the big grin from duck
 sum: 1:22:51 1:22:52 in thing, seems to get that far... hmm...

youtube jonah: appears lower quality?
 15: wash your hands before you [eat]
 30: yes well [you] and ...
 45: big smile, turns [to his right]
 sum: (says 1:22:59 for pay version [?]) says 1:22:54 in index, and on vid, felt really like 1:22:52 or so

powerdvd 8 (DVD):
  15:
    wash your hands before you [eat]
    wash your hands [before] you eat
    wash your [hands] before you eat LOL
  30: 
    can count on to deliver his messages yes [] well  
    yes well ... you and [] ... are like peas in a pod
  45: 
    big smile [] he turns to his right
    turns [to his right] 
    [] turns to his right

wmp windows 7: [wmp feels slightly unstable timing-wise]
  15:  before [] you eat --- before [you] eat
  30:  yes []well --- yes well[]
  45:  turns [to his right] --- turns to his right[]
  
blu-ray powerdvd:
  30: deep in my family [] my uncle * 2
  45: blue light shines down 44:58 or 59
    duck 44:47 look left about 44:48      
  1:22:45 sum, seems to have the same closing credits et al...
  totally uses 100% cpu

netflix instant jonah

 15: be a friend say your prayers, heavens knows a heart that cares, taht is why I've come to share a mes[sage] from the Lord (at times it's [mes]sage, once it was [from])
     chrome at work: 
        a[]message, 
        a messa[ge] from the Lord
        message [] from the Lord
        [share] a message from the Lord
        a message[] from the Lord
        me[ss]age from the Lord [HD]
     IE at work: 
       [fr]om the Lord
        a [mes]sage from the Lord
        [fr]om the Lord.
        me[ss]age from the Lord [HD]
        
 conclusion: browser doesn't matter, (at least for HD stream at work)
        
 30: like two humps on a camel, you always sway the same way, humor runs in my family, my uncle was a [big] star
     IE at work: humor runs very deep in my family[] my uncle was, my uncle was[] a big star, my [uncle] was a big star

 45: (LIKE 12 seconds after the big grin) (big smile, next scene) blue fades in [oooh]
     IE at work: 2 seconds after blue light fades in * 3
     chrome: 1.5 seconds as blue light fades in
     it's like 10 seconds in...
     same with mac
     47 duck
     conclusion: netflix doesn't care about mac versus pc timing-wise
     59 blu ray how apropo
    
     conclusion (based on this compared with the blu-ray): netflix instant seems to match pretty close, within 1s to the blu-ray

 conclusion: netflix varies pretty widely from instance to instance of playing back (same computer, same movie, same browser).

forever strong (chrome work netflix instant):

 15: I'm sorry, are you in the home add me now ... []almost, almost(two spaces)[], almost(one space)[]
 30: (ambulance...) let's go guys keep it tight (3 secs or so), same at 57-58, tight right on 58
 45: we stand on this field ready for battle []*2
 1:30 where I was 40 years ago...[don't] spend another, don't [spend] another minute being angry

saints and soldiers (chrome work netflix instant):

 15: is the squarest guy I know...[he's] from some little backwards,  [] he's from some little
 30: flirting with the girl at my dad's store...[] what's her name*2
 45: music...basically second footstep, first footstep,  end of first footstep
 1:15: kendrick's dead 1:14:56-7
 1:30: "copyright 2003...all rights reserved" is about in the middle, maybe barely above

jonah if you watch it all the way through
  30: my uncle [was] a big star     

VLC jonah_edit.tmp.mpg
 15: (on camel) do not fight, do not cheat [wash] your hands
 30: can count on to deliver his messages [] yes well
 45: the duck surfaces [right before big grin]
 
mplayer jonah_edit.tmp.mpg
 15: (on camel) do not fight, do not cheat wash your hands [before] you eat
 30: can count on to deliver his messages [] yes well
 45: between duck surfacing [] big grin
 
forever young
 30: netflix: some running at 29:50...


MPlayer git-20100211-1-g1c6846f-Kovensky-mt (C) 2000-2009 MPlayer Team
  can play dvd:// and dvdnav:// with seeking at the beginning without crashing...[because old, maybe?]
  mulder's: http://mulder.googlecode.com/files/MPUI.2010-10-17.Full-Package.exe crashes like normal [dvdnav only]
    smplayers seem to always play dvd:// so never crash [?]

the internet seems to "not tell me" if transcode's avisplit is frame accurate or not.

watching a DVD "from the new DVD ISO" in smplayer seemed to have the right audio always. yep.
  i.e. transcoding from dvd flick fixed it [probably]

previewing section on HP 2 hours or so and the first thing overlapped the muted section in error...went too long...huh?
  call ffmpeg -i C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -vcodec copy -acodec copy  -ss 7260.0 -t 10.499 C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.1.avi
  call ffmpeg -i C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -vcodec copy -acodec ac3 -vol 0  -ss 7270.5 -t 1.499 C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.2.avi
  call ffmpeg -i C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -vcodec copy -acodec copy  -ss 7272.0 -t 3.999 C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.3.avi

  resulted in sectors of 13.17 1.93, 5.03 instead of 10.5, 1.5, and 4. huh?
   with FFmpeg version SVN-r19313, [BAD VERSION probably]
  call ffmpeg -i C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -vcodec copy -acodec copy  -ss 7260.0 -t 10.499 yo.1.avi
    with r32676 seemed much more sane (!)

$ to fix mplayer out of sync audio:
$ ffmpeg -i HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -target ntsc-dvd -t 1600 yo.mpg
seemed to be as good as adding a harddup via mplayer.  except...umm...VLC can play it right so why can't mplayer?  Hopefully all doesn't matter [?]

ffmpeg "copy copy" on HP fulli seemed to not have audio when that was replayed via mplayer.

monsters inc. overlaps at 25 minutes, 50'ish, 70, "when they land" and there's like 30 'select scenes' (chapters) in that time frame...

bob "they will come" has no mplayer overlap (45 minutes long)

HP 2 "full and edited version" had a twidge off of audio even in VLC (unsure if that was copy or lavc audio)
  seems consistent
  The DVD (flick) burned, then played, appeared to have audio in perfect sync, always.
  seems to play fine in smplayer
  the fulli version was *totally off* in smplayer
  fulli, edited version had some artifacts in VLC
  fulli version had perfect audio in VLC
  audio looks barely off VLC for the whole thing

mplayer (updated) playing dvd:// (bob) can't seek if past 30 minutes or so (pause/hang)

mplayer (updated) playback, if it ever goes off the screen, chokes and hurles and dies (or if it goes under a window that is always on top).

an edl with (updated mplayer and) dvdnav:// (bob) results in a crash when seeking the first few seconds, at least.

Seeking using the "forward 10, back 10" works in mplayer console, 
  also works (!) with smplayer (+10, back 10).
  
Also edl works *perfectly* when playing from the ripped file.

There is only one break in cars DVD. A:3756
  Is it the same in other large DVD's?
  so certainly, mplayer's edl playback is broken currently, for DVD's.

if I change the mute to 2:13, then it works [!], though probably doubly.

"enable dvd menus" in mplayer doesn't seem to help with seeking weirdness in smplayer

smplayer edl against cars DVD *fails* on later ones (1:05), but succeeds on 15:00, mute-wise.
Like epic fail.
also seeking totally fails:
  58 -> 58 works (cars)
  transition to broken seeking:1:02:44
  also always thinks its chapter 1 :)
  
smplayer playing cars fulli (of some sort) seems to be a split second off, audio-wise

smplayer on HP2 -> edited version (ffmpeg through mencoder) with oac copy, is off by an annoying split second when replayed in smplayer
 at other times, it fails everywhere almost, sync-wise
  that "might" have been with HP and -oac lavc, but without harddup.  or maybe it was -oac copy
  VLC plays the audio splendidly on the same.
  plays well from DVD, though.  Just that one file isn't playable with mplayer...
  how does EDL fit into all of this, though?
  also note that mplayer originally couldn't cut right because of audio (with oac copy, I believe)

ffmpeg said that the huge HP grab was always 48 minute duration [?] (then proceeded to work right)

edl *fails* with HP at the 2 hour mark, audio.  The audio did seem to line up, at least, with their lips.
  and if it's video--fails the same. Seems to think it's at second 2678, or minute 44, not minute 120?

smplayer on bob pets pickle and baby has sync'ed audio with oac copy
  in general, if it starts sync'ed, smplayer stays in sync all the way through
  
got av_interleaved_write_frame(): Operation not permitted
  on call ffmpeg -i C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.fulli_unedited.tmp.mpg -vcodec copy -acodec copy  -'
;?Pss 749.0 -t 4109.999 C:\HP_AND_THE_CHAMBER_OF_SECRETS_edited_version.5.avi
  then it passed (reading off the "old fulli" with poor audio) when did it again. huh?
  out of disk perhaps??
  
edl works *great* with cars at 15 minutes, and appears to at an hour, too.  Oh, and the audio matches perfectly.

The kicker is that if I want to watch the "unedited all" option in mplayer (which I do for the "quick start" mode), then it needs to be as is...

audio_codec = these_settings['audio_codec'] || 'lavc' # not copy...sniff...or you can't hear cars...as ffmpeg loses it on transfer [?] at least the intermediates you *cannot* hear.

HP with edl (only) seriously fails at the 2 hour mark, even with 5 seconds added, or seems to, at least.

windows media player is able to playback the "fulli" that mplayer gets out of sync on (lavc audio), at least with cars.

mplayer dvd://23 -dvd-device e:\ -edl C:\Users\packrd\AppData\Local\Temp\mplayer.temp.edl
  seems to play with audio in sync always, with cars (now with potter...)

what if you grab with "full" audio...does it make its way back out to the DVD? what does dvd flick do audio wise?

without harddup smplayer got audio video out of sync playing DVD, as well as playing ripped files, however
  when you wrote those to DVD, they seemed to get back in sync. ffmpeg, perhaps, is/was fixing them?

fulli with lavc audio and video: mplayer cannot play it back right, but if it's re-encoded with mencoder first [? or is it ffmpeg?], mplayer
seems to play it fine then. Thin ice here...

if I pull from dvd with -acodec lavc (basically downgrade to stereo), then ffmpeg can extract to avi with sound.
  otherwise (cars only), it lacks sound *only on computer players*

Note that mencoder cannot have an endpos on a dvd. Weird.

Note that dvdflick "appears" to encode correctly even if the size is too big, as in it just encodes it "lossy-y"
  The encoding actually appears to be fairly high quality, that dvd flick does, video wise, at least.

ffmpeg -i bigg.mpg -acodec copy -vcodec copy bigg.reindexffmpeg.mpg

resulted in a sound with no audio

I got bigg trying to combine (mencoder ?) two large files.

I think .big has honestly messed up audio, no reindexing seems to help it, at all.