• 台湾“裤子大王”:百姓三餐不济谈啥“台湾价值” 2019-05-23
  • 韩国釜山海滩变“垃圾场” 清洁工叫苦不堪 2019-05-23
  • 浙江宣讲十九大:之江大地“好声音”“红船”精神入人心 2019-05-19
  • “回天地区”下月开放千套人才公寓 ——凤凰网房产北京 2019-05-13
  • 中国智能手机在东南亚受追捧 2019-04-25
  • 阜阳网络达人“点赞”颍泉绿化提升专项工作 2019-04-23
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • Welcome to

    Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

     

    Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

    Reply
     
    Thread Tools Search this Thread Display Modes
    Old 16th March 2019, 02:59   #81  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by zorr View Post

    Code:
    from zoptilib import Zopti
    
    # read input video
    orig = core.ffms2.Source(source=r'source.avi')
    
    # initialize output file and chosen metrics 
    zopti = Zopti('results.txt', metrics=['ssim', 'gmsd'])
    
    #   ... process the video ...
    # alternate = some_process(orig)
    
    # measure similarity of original and alternate videos, save results to output file
    zopti.run(orig, alternate)
    quick question:

    trying to run some GMSD, SSIM and MDSI metrics via Zopti - same as outlined on page 1 in the thread...

    when I specify all three metrics as a list to Zopti, it creates a log file w/ the three results... when I then run the same distorted clip again via Zopti but only use ONE of the metrics (e.g.) GMSD, I get a log file with only one metric but the result does not match any of the results in the log file that contains all three metrics...

    Code:
    Example - all on the same distorted clip
    
    GMSD, SSIM, MDSI
    stop 123.25129597713656 228.20727309992276 230.492983448053 
    
    GMSD
    stop 83.77192685888292 
    
    SSIM
    stop 431.9516453872494

    What am I missing ?


    I'm running Zopti via a .vpy file executed by vspipe...

    Thanks.
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 05:40   #82  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Would you mind posting your script(s) for the 3-in-1 and individual metric tests ?
    __________________
    Nostalgia's not what it used to be
    WorBry is offline   Reply With Quote
    Old 16th March 2019, 05:46   #83  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,793
    Works for me . Same values in the same colorspace

    MDSI requires RGB , so I converted to RGB for the 3 way test . Same values for the individual runs in RGB

    But I got the same values within YUV for 2 way test GMSD ,SSIM, as single runs (within YUV, different values than converted RGB)


    What source filter were you using ? When something is off like that, usually it's a frame mismatch
    poisondeathray is offline   Reply With Quote
    Old 16th March 2019, 07:32   #84  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by WorBry View Post
    Would you mind posting your script(s) for the 3-in-1 and individual metric tests ?
    I'm using same file you've used for some of your tests: Crowdrun 1080p50 420, 500 frames (crowd_run_1080p50.y4m)

    The encoded file was created via ffmpeg x265 CRF 28 preset slow

    Code:
    vid_ref = core.ffms2.Source(source=ref_fp)
    vid_enc = core.ffms2.Source(source=enc_fp)
    log_fp = r'd:\zopti.log'
    
    metrics = ('gmsd', 'ssim')
    matrix = None
    
    zopti = Zopti(log_fp, metrics=metrics, matrix=matrix)
    zopti.addParams('ssim', dict(downsample=False, show_map=False))
    
    zopti.run(vid_ref, vid_enc)

    Quote:
    Originally Posted by poisondeathray View Post
    Works for me . Same values in the same colorspace

    MDSI requires RGB , so I converted to RGB for the 3 way test . Same values for the individual runs in RGB

    But I got the same values within YUV for 2 way test GMSD ,SSIM, as single runs (within YUV, different values than converted RGB)


    What source filter were you using ? When something is off like that, usually it's a frame mismatch
    thank for the hint that MDSI gets converted to RGB... that changes all values for GMSD and SSIM (if requested in the same run), which makes this absolutely pointless...

    ONLY MDSI should be done in RGB, everything else in YUV, so that results stay consistent...


    but even with that, the results using the Zopti class are as unstable as I've seen...

    look at this... consecutive execution of the exact same script, just the requested metrics have been changed in each run - only using GMSD and SSIM... this is odd to say the least....


    Code:
    GMSD #1
    stop 82.89543157743563 
    
    SSIM #1
    stop 436.64183973524297
    
    GMSD #2
    stop 95.29160100865921 
    
    GMSD #3
    stop 82.89543157743563 
    
    GMSD #4
    stop 82.89543157743563 
    
    GMSD #5
    stop 82.89543157743563 
    
    GMSD #6
    stop 82.89543157743563 
    
    GMSD, SSIM - #1
    stop 122.23059696996059 236.93252855842488 
    
    GMSD, SSIM - #2
    stop 121.9632105098167 237.4638095431857 
    
    SSIM #2
    stop 436.641839735243 
    
    GMSD, SSIM - #3
    stop 82.89543157743563 436.641839735243
    
    GMSD, SSIM - #4
    stop 122.14837149649146 236.40679167570883 
    
    GMSD, SSIM - #5
    stop 123.8819626481414 228.86426005799092 
    
    GMSD, SSIM - #6
    stop 120.18331285114424 246.86257738654993
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 09:00   #85  |  Link
    Registered User
     
    Join Date: Dec 2005
    Location: Germany
    Posts: 770
    Check your video file with https://github.com/theChaosCoder/vap...4/seek-test.py
    python.exe seek-test.py video.mp4 0 100
    0 100 = start_frame end_frame
    __________________
    Search and denoise
    ChaosKing is offline   Reply With Quote
    Old 16th March 2019, 11:46   #86  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by ChaosKing View Post
    Check your video file with https://github.com/theChaosCoder/vap...4/seek-test.py
    python.exe seek-test.py video.mp4 0 100
    0 100 = start_frame end_frame
    tested the encoded/distorted clip, result

    Code:
    Press 1 for FFMS2000
          2 for L-SMASH-Works
          3 for D2V Source
          4 for AVISource
          5 for FFMS2000(seekmode=0) [slow but more safe]
    Number: 5
    ffms2seek0
    Clip has 500 frames.
    Hashing: 80%
    Clip hashed.
    
    Test complete. No seeking issues found :D
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 11:56   #87  |  Link
    Registered User
     
    Join Date: Dec 2005
    Location: Germany
    Posts: 770
    Have you also tested with number 1 (without seekmode=0)?
    __________________
    Search and denoise
    ChaosKing is offline   Reply With Quote
    Old 16th March 2019, 15:32   #88  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by Iron_Mike View Post
    I'm using same file you've used for some of your tests: Crowdrun 1080p50 420, 500 frames (crowd_run_1080p50.y4m)

    The encoded file was created via ffmpeg x265 CRF 28 preset slow
    Actually I converted the crowd_run_2160p50.y4m file to lossless 1080/50p x264 CRF0 Intra mp4 to serve as the 'Master' source and reference for the 1080/50p tests.

    For the 2160/50p tests I used the original crowd_run_2160p50.y4m file as the 'Master'.

    Re-testing the files I have archived, I get the following raw scores for 1080/50p x265 CRF28 (default settings, except -preset slow):

    Code:
    SSIM:GMSD (together): 478.4192336998458;43.506163861971956
    
    SSIM(alone) : 478.4192336998458 
    GMSD (alone): 43.506163861971956
    Exact same scores whether tested together or separately.

    I'm using ChaosKing's Portable Fatpack VapourSynth and running the scripts with VSEditor > (F7) Benchmark. Now using Wolfberry's FFMS2 build:

    //www.zs-x.com/showthread.php?t=176198
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 16th March 2019 at 15:42.
    WorBry is offline   Reply With Quote
    Old 16th March 2019, 15:56   #89  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,793
    Quote:
    Originally Posted by Iron_Mike View Post
    thank for the hint that MDSI gets converted to RGB... that changes all values for GMSD and SSIM (if requested in the same run), which makes this absolutely pointless...

    ONLY MDSI should be done in RGB, everything else in YUV, so that results stay consistent...

    The point is you should get the same consistent results in RGB (the multi run should be same as individual runs in RGB). If you didn't - it would add support that there was something wrong .

    You did not clarify how you converted to RGB or any of the other procedures, so maybe there were other errors in your procedure?

    So I even added the 2way YUV runs, which were the same within YUV as the individual YUV runs - and it looks like you're still getting different inconsistent results

    I did multiple 5 runs of the same script, everything is consistent here

    One thing that is odd, is sometimes the frame number will out of numerical order in the log e.g it might go 45,44,46 . I assume it has to do with the threading. But the actual values are the same.

    Another difference is I did not prevent SSIM downsample (I went by the 1st script you quoted) , but that shouldn't affect GMSD , and I used vsedit to run the benchmark like WorBry . But I cannot see how using vspipe would alter the results .



    Try another ffms build.

    If seeking is accurate, maybe something else is up with your machine. Maybe start looking at memory integrity tests, hardware checks, temps, overheating
    poisondeathray is offline   Reply With Quote
    Old 16th March 2019, 18:28   #90  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by poisondeathray View Post
    Another difference is I did not prevent SSIM downsample (I went by the 1st script you quoted) , but that shouldn't affect GMSD
    Disabling downsample changes the GMSD scores profoundly - examples:

    //www.zs-x.com/showthread.p...14#post1866314

    ...and

    //www.zs-x.com/showthread.p...58#post1868858

    These are the raw SSIM and GMSD scores I get testing the x265 CRF28 encode with Downsample=False:

    Code:
    SSIM:GMSD (together): 446.2983305603785; 75.80431917408734
    
    SSIM (alone): 446.2983305603785
    GMSD (alone): 75.80431917408734
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 16th March 2019 at 18:32.
    WorBry is offline   Reply With Quote
    Old 16th March 2019, 20:32   #91  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,793
    Quote:
    Originally Posted by WorBry View Post
    Disabling downsample changes the GMSD scores profoundly - examples:


    Code:
    SSIM:GMSD (together): 446.2983305603785; 75.80431917408734
    
    SSIM (alone): 446.2983305603785
    GMSD (alone): 75.80431917408734
    He only specified addParams for SSIM . Are you saying that changes GMSD too ? Don't you have to addParams('msdn' etc...) explicitly too ?


    You you don't expect downsampling to change the consistency of the results .

    You would expect any operation resize, or filter, or blur etc.. to affect the actual values.

    But you do not expect it to change the values between multi testing at once vs. single testing; unless that filter uses some random property (e.g. a noise generator with random seed)

    ie. When you run it you should get the same values when the settings are the same. You expect repeatable, consistent results within the same testing parameters. It shouldn't give you different values based on the time of the day or the phase of the moon
    poisondeathray is offline   Reply With Quote
    Old 16th March 2019, 21:03   #92  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by WorBry View Post
    Actually I converted the crowd_run_2160p50.y4m file to lossless 1080/50p x264 CRF0 Intra mp4 to serve as the 'Master' source and reference for the 1080/50p tests.

    For the 2160/50p tests I used the original crowd_run_2160p50.y4m file as the 'Master'.
    ah, thank you for clarifying that. I was looking at some scores I got for the 1080p50 src I used and they did not perfectly match yours...

    okay, I'm gonna convert the 2160p src to see if I can match your results throughout the thread - as a little (although not perfect) unit test.

    Could you state the command how you converted to "1080/50p x264 CRF0 Intra mp4" ? (just to be sure I match your result)

    Quote:
    Originally Posted by WorBry View Post

    I'm using ChaosKing's Portable Fatpack VapourSynth and running the scripts with VSEditor > (F7) Benchmark. Now using Wolfberry's FFMS2 build:

    //www.zs-x.com/showthread.php?t=176198
    I'm using CK's Fatpack as well.

    Btw, when I ran extensive tests before (using CK's Fatpack and VSPipe) on the VS VMAF implementation (vs. ffmpeg VMAF), there were never any inconsistencies...
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 21:14   #93  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by ChaosKing View Post
    Have you also tested with number 1 (without seekmode=0)?
    just did that, and yes it found many errors... seeking seems to be 3 frames off

    Code:
    Press 1 for FFMS2000
          2 for L-SMASH-Works
          3 for D2V Source
          4 for AVISource
          5 for FFMS2000(seekmode=0) [slow but more safe]
    Number: 1
    ffms2
    Clip has 500 frames.
    Hashing: 80%
    Clip hashed.
    
    Requested frame 478, got frame 481.
        Previous requests: 478
    Requested frame 358, got frame 361.
        Previous requests: 478 358
    Requested frame 284, got frame 287.
        Previous requests: 478 358 83 284
    Requested frame 274, got frame 277.
        Previous requests: 478 358 83 284 274
    Requested frame 242, got frame 245.
        Previous requests: 478 358 83 284 274 242
    Requested frame 214, got frame 217.
        Previous requests: 478 358 83 284 274 242 98 214
    Requested frame 195, got frame 198.
        Previous requests: 478 358 83 284 274 242 98 214 30 195
    Requested frame 200, got frame 203.
        Previous requests: 358 83 284 274 242 98 214 30 195 11 200
    Requested frame 381, got frame 384.
        Previous requests: 83 284 274 242 98 214 30 195 11 200 381
    Requested frame 184, got frame 187.
        Previous requests: 284 274 242 98 214 30 195 11 200 381 184
    Requested frame 405, got frame 408.
        Previous requests: 98 214 30 195 11 200 381 184 5 55 405
    Requested frame 436, got frame 439.
        Previous requests: 30 195 11 200 381 184 5 55 405 33 436
    Requested frame 275, got frame 278.
        Previous requests: 195 11 200 381 184 5 55 405 33 436 275
    Requested frame 425, got frame 428.
        Previous requests: 200 381 184 5 55 405 33 436 275 47 425
    Requested frame 247, got frame 250.
        Previous requests: 381 184 5 55 405 33 436 275 47 425 247
    Requested frame 395, got frame 398.
        Previous requests: 184 5 55 405 33 436 275 47 425 247 395
    Requested frame 346, got frame 349.
        Previous requests: 5 55 405 33 436 275 47 425 247 395 346
    Requested frame 427, got frame 430.
        Previous requests: 55 405 33 436 275 47 425 247 395 346 427
    Requested frame 323, got frame 326.
        Previous requests: 436 275 47 425 247 395 346 427 3 499 323
    Requested frame 160, got frame 163.
        Previous requests: 275 47 425 247 395 346 427 3 499 323 160
    Requested frame 111, got frame 114.
        Previous requests: 47 425 247 395 346 427 3 499 323 160 111
    Requested frame 145, got frame 148.
        Previous requests: 395 346 427 3 499 323 160 111 76 52 145
    Requested frame 316, got frame 319.
        Previous requests: 346 427 3 499 323 160 111 76 52 145 316
    Requested frame 158, got frame 161.
        Previous requests: 427 3 499 323 160 111 76 52 145 316 158
    Requested frame 122, got frame 125.
        Previous requests: 3 499 323 160 111 76 52 145 316 158 122
    Requested frame 230, got frame 233.
        Previous requests: 499 323 160 111 76 52 145 316 158 122 230
    Requested frame 251, got frame 254.
        Previous requests: 160 111 76 52 145 316 158 122 230 94 251
    Requested frame 253, got frame 256.
        Previous requests: 111 76 52 145 316 158 122 230 94 251 253
    Requested frame 166, got frame 169.
        Previous requests: 76 52 145 316 158 122 230 94 251 253 166
    
    ... (many more)
    
    Test complete. Seeking issues found :-(
    so why has this encoded file seeking issues ?

    or is it my ffms2 version ? (it's the one from your Fatpack)
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 21:19   #94  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by poisondeathray View Post
    He only specified addParams for SSIM . Are you saying that changes GMSD too ? Don't you have to addParams('msdn' etc...) explicitly too ?
    Sorry, misunderstanding on my part.

    Quote:
    Originally Posted by poisondeathray View Post
    When you run it you should get the same values when the settings are the same. You expect repeatable, consistent results within the same testing parameters. It shouldn't give you different values based on the time of the day or the phase of the moon
    Absolutely.
    __________________
    Nostalgia's not what it used to be
    WorBry is offline   Reply With Quote
    Old 16th March 2019, 21:20   #95  |  Link
    Registered User
     
    Join Date: Dec 2005
    Location: Germany
    Posts: 770
    I added the lastest build from the ffms2 thread. You could try your old ffms2 version. Maybe something broke. L-SMASH is usually a bit more safe and is frame accurate for many more containers like m2ts or even vob.

    p.s. that is why it is always good to test for seeking issues first. I have a h264 mkv but every ffms2 version has seeking issues with that file for some reason. lsmash no problemo.
    __________________
    Search and denoise

    Last edited by ChaosKing; 16th March 2019 at 21:24.
    ChaosKing is offline   Reply With Quote
    Old 16th March 2019, 21:27   #96  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by Iron_Mike View Post
    Could you state the command how you converted to "1080/50p x264 CRF0 Intra mp4" ? (just to be sure I match your result)
    Probably better that I run the tests again with crowd_run_1080p50.y4m as source and post my results for x265 CRF28, rather than introducing another variable.
    __________________
    Nostalgia's not what it used to be
    WorBry is offline   Reply With Quote
    Old 16th March 2019, 21:51   #97  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,793
    Quote:
    Originally Posted by ChaosKing View Post
    I have a h264 mkv but every ffms2 version has seeking issues with that file for some reason. lsmash no problemo.
    Is that with seekmode=0, threads=1 too ?

    Did you examine that mkv to see what characteristics cause the problem ?

    Can you share the file ? It would be a good debugging test clip
    poisondeathray is offline   Reply With Quote
    Old 16th March 2019, 21:54   #98  |  Link
    Registered User
     
    Join Date: Mar 2018
    Posts: 213
    I did some tests too. With SSIM and GMSD the first two runs gave identical results, but the third one gave a different one. The difference is not big - starts with the 6th decimal - but it should not happen.

    stop 49.08846907182173 3.484012159548981 3762.3334999999825
    stop 49.088468378240414 3.4840229354201178 3428.1400000000417

    There's no RGB conversion involved here so it has to be something else.

    Looking at the individual frame results:

    0; 0.9794317688604798; 0.07659219540647606; 0.0;
    1; 0.9793688841540404; 0.07778895381762808; 0.0;
    2; 0.9801722825175584; 0.07465046759649577; 0.0;
    3; 0.9805196896947995; 0.07238442343729419; 0.0;

    0; 0.9794317688604798; 0.0765921875457907; 0.0; <--- GMSD different from 8th digit
    1; 0.9793688841540404; 0.07778895381762808; 0.0;
    2; 0.9801722825175584; 0.07465046759649577; 0.0;
    3; 0.9805189190488873; 0.07238807894499658; 0.0; <--- SSIM and GMSD different from 6th digit

    Looks like there are differences on some frames only. Does not look like a seeking issue either, the errors are much smaller than what would happen if the frame was different.

    I remember seeing this kind of issue when I first tested SSIM metric with Vapoursynth but then the error disappeared and I forgot about it.
    zorr is offline   Reply With Quote
    Old 16th March 2019, 22:01   #99  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by WorBry View Post
    Now using Wolfberry's FFMS2 build:

    //www.zs-x.com/showthread.php?t=176198
    I just exchanged the FFMS2 plug in the Fatpack w/ Wolfberry's latest version...

    same result run CK's seek test script (on the same encoded video file), it is always 3 frames off...

    I also ran the #1 FFMS2 seek test on the original download of "crowd_run_1080p50.y4m" - zero issues found.


    Alright, so I assume my encodes are bad...

    did multiple re-encodes using Wolfberry's build or Zeranoes build... all have frame seeking issues, always 3 frames off...

    here's the ffmpeg command:

    Code:
    <ffmpeg path> -y -thread_queue_size 8092 -i <path/to/crowd_run_1080p50.y4m> -c:v libx265 -preset slow  -crf 24  -color_range tv -color_primaries bt709 -color_trc bt709 -colorspace bt709 
    -pix_fmt yuv420p -x265-params "keyint=100:min-keyint=100:rc-lookahead=100"  -r 50 <path/to/output.mp4>
    I also tested w/o specifying colorspace and keyframes... same result, 3 frames off


    any pointers what I'm doing wrong in my encoding settings ?
    Iron_Mike is offline   Reply With Quote
    Old 16th March 2019, 22:03   #100  |  Link
    ifb
    Registered User
     
    Join Date: Dec 2009
    Posts: 64
    Quote:
    Originally Posted by WorBry View Post
    Can ffmpeg even ingest Canon XF-HEVC (10bit 422) camera footage yet ?
    Yes. It was added to the MXF demuxer 8 days ago.

    Samples
    ifb is offline   Reply With Quote
    Reply


    Posting Rules
    You may not post new threads
    You may not post replies
    You may not post attachments
    You may not edit your posts

    BB code is On
    Smilies are On
    [IMG] code is On
    HTML code is Off

    Forum Jump


    All times are GMT +1. The time now is 10:56.


    Powered by vBulletin® Version 3.8.11
    Copyright ©2000 - 2019, vBulletin Solutions Inc.
  • 台湾“裤子大王”:百姓三餐不济谈啥“台湾价值” 2019-05-23
  • 韩国釜山海滩变“垃圾场” 清洁工叫苦不堪 2019-05-23
  • 浙江宣讲十九大:之江大地“好声音”“红船”精神入人心 2019-05-19
  • “回天地区”下月开放千套人才公寓 ——凤凰网房产北京 2019-05-13
  • 中国智能手机在东南亚受追捧 2019-04-25
  • 阜阳网络达人“点赞”颍泉绿化提升专项工作 2019-04-23
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 百家樂详细补牌规则 中国福彩网下载app pc蛋蛋预测器 香港六合彩137期 天津时时彩平台登录 福彩欢乐生肖奖金 t6娱乐平台 现场开奖 彩客网北单 下载玩彩票软件 半全场比分直播 排列五和值和尾分布图 北京pk10五码分析技巧 七星彩图规 快乐飞艇是官方彩票吗 超级大乐透开奖结果