seek on an open file causes hard lock

[GoogleCodeExporter]

Describe the issue you're having:
I need to play f4v files that are being actively downloaded by rtmpdump.  The 
problem is, if the buffer attempts to read past the end of the file, the player 
will lock-up and spin the CPU.  This does not occur with the same file if 
rtmpdump is not running and it tries to read past the end of file.

How can the issue be reproduced? Sample File?
Any file that is open for writing while it is playing, and then seek close to 
or past the current end of file.  See patch below to enable the ability to seek 
in unknown duration files for MPC-HC.  9 MB binary with the below patch can be 
provided on request.

What version of the product are you using? In which Player?
LAV 0.63.0, MPC-HC 1.7.7.73 (compiled from git)

Please provide any additional information below.

The following patch to enable seeking in files of unknown duration was applied 
to MPC-HC before compiling; it will be submitted to them for inclusion in 
upstream repository as well:

--------------------------- src/mpc-hc/MainFrm.cpp ----------------------------
index 301914f..2ee2361 100644
@@ -13796,7 +13796,7 @@ void CMainFrame::SeekTo(REFERENCE_TIME rtPos, bool 
bShowOSD /*= true*/)
     if (!IsPlaybackCaptureMode()) {
         __int64 start, stop;
         m_wndSeekBar.GetRange(start, stop);
-        if (rtPos > stop) {
+        if (m_wndSeekBar.HasDuration() && rtPos > stop) {
             rtPos = stop;
         }
         m_wndStatusBar.SetStatusTimer(rtPos, stop, !!m_wndSubresyncBar.IsWindowVisible(), GetTimeFormat());

Original issue reported on code.google.com by ywlke...@gmail.com on 29 Oct 2014 at 4:39

[GoogleCodeExporter]

Seeking in files without a known duration is known to be rather error prone, 
which is why many players will never allow you to do that.

I strongly recommend to simply not do that.

Original comment by h.lepp...@gmail.com on 31 Oct 2014 at 1:20

[GoogleCodeExporter]

To elaborate, DirectShow doesn't support the concept of a seek "failing", ie. 
if you tell it to seek, it absolutely expects playback to continue from the 
point you sekeed to.

If however the seek failed, you may actually resume reading from some random 
other point (maybe where you were before the seek, maybe somewhere else), which 
totally throws DirectShow off and causes all sorts of havoc, which is why 
seeking in files which don't even have a known duration is rather ill advised.

Original comment by h.lepp...@gmail.com on 31 Oct 2014 at 1:23

[GoogleCodeExporter]

I agree that makes sense, but seeking works reliably with a closed file of 
unknown duration in MPC-HC/LAV without havoc, and VLC handles both open and 
closed files of unknown duration just fine.  Alternatively the old 
MPC-HC/FLVFilter works with open files by detecting the currently available 
duration and uses that, but it doesn't rescan the file so playback stops at 
whatever duration was initially detected, whereas LAV can play open files past 
the initial duration.

In fact, this also occurs with files of "known" duration but are incompletely 
downloaded, if they are being downloaded when MPC-HC/LAV opens the file, even 
if rtmpdump is not running at the time that MPC-HC/LAV approaches the end of 
the file.  However, if MPC-HC/LAV opens the incomplete file when rtmpdump is 
not running, then seeking past the downloaded portion fails safely.

Original comment by ywlke...@gmail.com on 31 Oct 2014 at 2:37