TODO List
=========
*) Test 3.2.3 core in different linux version
*) More test cases for bind mode
*) key rip need to be retested
*) Process option need to be retested
+) BUGS: Chinese characters broken in SView
+) BUGS: SView could not be updated when appending files, wrong length of sview
+) BUGS: Percentage lost update in sview

DO NOT FIX
==========
*) 20150227: ezthumb -p scan --accurate middle.avi
In '--accurate' mode, ezthumb would decode P/B frames between two I frames.
Some dodge clips, like middle.avi which badly encoded the B frame, would cause
ffmpeg messed around I frame unless keep decoding every frames. For example,
while only decoding I frames by ezthumb -p scan middle.avi:

Decoded , KEY:1, CPN:16, DPN:0, FF_I_TYPE DTS:2122, PKey:1  EKey:0
Decoded , KEY:1, CPN:17, DPN:0, FF_I_TYPE DTS:2362, PKey:1  EKey:0
[0127101225] video_snapshot_scan: [OR] 2602/2510
Decoded , KEY:1, CPN:18, DPN:0, FF_I_TYPE DTS:2602, PKey:1  EKey:1
Frame   1: Pos:6986090 Size:12708 PAC:1 DTS:2602 (0:01:48,525) Type:FF_I_TYPE FRAME EKey:1
Decoded , KEY:1, CPN:19, DPN:0, FF_I_TYPE DTS:2842, PKey:1  EKey:0
Decoded , KEY:1, CPN:20, DPN:0, FF_I_TYPE DTS:2917, PKey:1  EKey:0
Decoded , KEY:1, CPN:21, DPN:0, FF_I_TYPE DTS:3027, PKey:1  EKey:0
Decoded , KEY:1, CPN:22, DPN:0, FF_I_TYPE DTS:3267, PKey:1  EKey:0

while decoding P/B frames by ezthumb -p scan --accurate middle.avi:

Decoded , KEY:0, CPN:243, DPN:0, FF_P_TYPE DTS:2506, PKey:0  EKey:1
Decoded , KEY:0, CPN:244, DPN:0, FF_P_TYPE DTS:2508, PKey:0  EKey:1
Decoded , KEY:0, CPN:245, DPN:0, FF_P_TYPE DTS:2510, PKey:0  EKey:1
Frame   1: Pos:6827272 Size:4336 PAC:2 DTS:2510 (0:01:44,688) Type:FF_P_TYPE FRAME EKey:1
Decoded , KEY:0, CPN:246, DPN:0, FF_P_TYPE DTS:2603, PKey:0  EKey:0
Decoded , KEY:0, CPN:247, DPN:0, FF_P_TYPE DTS:2843, PKey:0  EKey:0
Decoded , KEY:0, CPN:248, DPN:0, FF_P_TYPE DTS:2918, PKey:0  EKey:0
Decoded , KEY:0, CPN:249, DPN:0, FF_P_TYPE DTS:3028, PKey:0  EKey:0

According to the DTS tag, ezthumb decoded to 2510, then jump to next I frame,
which should be 2602 rather than 2603. And every I frame had error from 2603.
This issue can be fixed by keeping decoding since 2510 untill a proper I frame
is hit. However the logic of the program would be messy and the cost efficency
would be bad, considering it only happens in old clips and most people would
use key frame thumbnails, so I'm not going to fix this.


*) 20150227: binding mode
In binding mode, the AR correction is only applied to the first clip in all
clips. If the second, third or more clips apply the different AR ratio, 
ezthumb won't follow the change.

The binding mode is assumed to work with same but seperated clips. Different
AR should not be used in mix.


*) 20150304: Win32 version no avformat_close_input()
This is the most weird thing I've ever had. In this FFMPEG release, the 
av_open_input_file() has been depricated and avformat_open_input() has been
introduced. But there's no avformat_close_input() so you still need to use
av_close_input_file() to close the video.

I reckon the Win32 version must have grabbed an intermediate version of FFMPEG
so there's some inconsistency. Since the FFMPEG development package will follow
the upstream soon, this bug need no fix.


*) Failed keyframe in feral.rm and other RMVB files.
Logs like this: 
[0204234236] video_snapshot_skim: [IF] 33767/40571
[rv40 @ 0x85fa320] First slice header is incorrect
Decoding KEY:1 CPN:0 EKey:0 [0] DTS:33767 PKey:1 Pos:3663332 Size:4805
[rv40 @ 0x85fa320] Invalid decoder state: B-frame without reference data.
Decoding KEY:1 CPN:0 EKey:0 [0] DTS:33666 PKey:0 Pos:3663332 Size:6264
[rv40 @ 0x85fa320] Invalid decoder state: B-frame without reference data.
Decoding KEY:1 CPN:0 EKey:0 [0] DTS:33700 PKey:0 Pos:3663332 Size:7865
[rv40 @ 0x85fa320] Invalid decoder state: B-frame without reference data.
Decoding KEY:1 CPN:0 EKey:0 [0] DTS:33733 PKey:0 Pos:3663332 Size:9290
[rv40 @ 0x85fa320] warning: first frame is no keyframe
Decoded  KEY:1 CPN:0 EKey:0 FF_I_TYPE DTS:33767 PKey:0 Pos:3663332 Size:14484
Decoded  KEY:0 CPN:0 EKey:0 FF_P_TYPE DTS:43710 PKey:1 Pos:4526394 Size:8764
Decoded  KEY:1 CPN:1 EKey:0 FF_I_TYPE DTS:53787 PKey:1 Pos:5498865 Size:6548
Frame   0: PAC:5 EKey:1 DTS:33767 (0:00:33,767) Type:FF_I_TYPE CACHE PTS:33900

The first key frame can not be properly decoded. However the rv40 decoder
still returned the look-good frame, actual contents were all grey images. 
Currently ezthumb can not tell which key frame was successfully decoded.

*) IUP GUI do not save MAXIMIZED status.
The MAXIMIZED ezthumb dialog window do not save the MAXIMIZED status. Instead
it saves the previous window size so when a MAXIMIZED ezthumb is restarted, 
it won't be MAXIMIZED.

The reason is setting
IupSetAttribute(gui->dlg_main, "PLACEMENT", "MAXIMIZED");
won't generate the resize event so the client area of ezthumb couldn't be
updated. Ezthumb can not maximize itself either because the window manage
would not know the recent window size.

