Closed GoogleCodeExporter closed 9 years ago
I don't have ZoomPlayer handy right now, but the file plays just perfectly in
any other players I've tried.
Original comment by h.lepp...@gmail.com
on 2 Sep 2014 at 11:26
Interestingly, MediaInfo reports the WAV file as PCM. In Zoom Player, the
Windows wave parser attempts to send the audio to LAV, and LAV rejects the
audio as being AC3 format (sub type 00000001-0000-0010-8000-00AA00389B71).
Original comment by forum.an...@gmail.com
on 2 Sep 2014 at 12:46
The original issue that lead to this report was from a user who had Zoom Player
hang when they played the MP4 file in that archive, with the Zoom Player 'Load
External Audio Tracks' option enabled (so the MP4 file would play and Zoom
would attempt to load the WAV file as the audio). This was when using LAV as
the audio decoder. That does indeed hang Zoom - but I understand from bLight
that he has reported this issue to you previously.
Original comment by forum.an...@gmail.com
on 2 Sep 2014 at 12:58
LAV Audio Decoder doesn't accept raw PCM audio, unless its from LAV Splitter.
Its a protection to avoid useless instances in the graph, or even repeated
filters, since its a decoder, and not a processor. There is one exception for
LAV Splitter, because of some complexity when dealing with files that contain
both raw PCM and a compressed stream (so you can switch between streams
properly).
If you're using the Wave Parser, simply connect its output to the audio
renderer, or use LAV Splitter to read the file, which then can connect to LAV
Audio.
No idea why the player would hang from this, i guess it doesn't like graph
building failures?
Original comment by h.lepp...@gmail.com
on 6 Sep 2014 at 1:23
nev: See the following post in your LAV thread, and the follow-on replies to
that:
https://www.doom9.org/showthread.php?p=1565754#post1565754
That is all related to this report.
We're trying to trace this issue in Zoom Player's code to get an in-depth
understanding of what's going on.
When Zoom Player's DSP filter receives the stop event (a few other events are
affected as well), it calls the "Inactivate" method on the input pin (which
doesn't return any error) and then tries to lock the critical section to
receive the buffers.
Would you have any idea why it would deadlock if the input pin (which I believe
is the source of the other locking thread) is supposed to be disabled?
Zoom Player's DSP code is based on the DS-DSP filter by the way, which dcoder
donated for Zoom Player's use many years ago.
Original comment by forum.an...@gmail.com
on 7 Sep 2014 at 12:06
For info, the DSP source code is here:
http://download.dsp-worx.de/?f=DCDSPFilter_v1.03_Source.zip
Function TDCDSPFilter.Stop: HRESULT; is the function it freezes in, on line
"FcsReceive.Lock;"
Original comment by forum.an...@gmail.com
on 7 Sep 2014 at 12:09
Original issue reported on code.google.com by
forum.an...@gmail.com
on 2 Sep 2014 at 7:04