=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
# Although each of the world's countries
# 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 .
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 of 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....
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
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
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 .
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... . 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)
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.
120180 frames in the ts
-> 29.97 1:46:50 (totally off)
120183 frames in the mkv 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 . 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 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 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
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 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
...we have...
870
01:28:50,205 --> 01:28:51,604
...dragons.
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
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
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
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 bigg has honestly messed up audio, no reindexing seems to help it, at all.