MKVs with RealVideo in VFW mode and RealAudio ATRAC3

[GoogleCodeExporter]

Describe the issue you're having:

Matroska files containing RealVideo wrapped in VfW-mode make LAV Video freeze 
the graph. ffdshow and MPC Video Decoder work OK. Also, if the MKV contains 
RealMedia ATRAC3, LAV Splitter refuses connecting to ffdshow Audio Decoder. 
This problem doesn't happen if the ATRAC3 stream uses the ACM mode though.

How can the issue be reproduced? Sample File?

Checked with Graphstudio. Sample files:

http://www.mediafire.com/?ggb18sppidld355

http://www.mediafire.com/?aab0uxsf55ef9ru

What version of the product are you using? In which Player?

LAV Filters 0.56.2.0 ; MPC-HC and Graphstudio ;

Please provide any additional information below.

Mplayer works OK with both sample files.

Original issue reported on code.google.com by wsm....@gmail.com on 4 May 2013 at 3:40

[GoogleCodeExporter]

The first clip is working just fine here with LAV Video as decoder. No freezes.

The second clip, i'm not sure it can be fixed that it connects to ffdshow. 
ffdshow could fix accepting it, but since that project is dead, its doubtful.
The problem is that the MKV in this mode does not contain the full RealAudio 
header, but only the format-specific header.
I imagine that ffdshow expects the full header, and doesn't accept the short 
header only.

LAV Splitter is not able to generate the missing header, but i made sure that 
LAV Audio instead can process both the full RA header, or only the 
format-specific header.

--
So, are there any other hints that would allow me to reproduce the freezing on 
the first clip?

Original comment by h.lepp...@gmail.com on 4 May 2013 at 6:57

• Added labels: Filter-Video, Usability

[GoogleCodeExporter]

So, one of the problems is fault of ffdshow, thanks for the clarification.
As for the freezing in the combination LAV Splitter + LAV Audio, well, I've 
been trying to determine the actual source of the issue, but no luck so far :-/ 
FWIW, I have found that LAV Audio works as it should when fed by the AV 
Splitter (v. 1.2.2.14) 0_o

Anyway, thanks again for the attention.

Original comment by wsm....@gmail.com on 4 May 2013 at 9:20

[GoogleCodeExporter]

I tested with LAV Splitter + LAV Audio + LAV Video, and nothing bad ever 
happens here.
Some detail must be missing.

Original comment by h.lepp...@gmail.com on 4 May 2013 at 9:21

[GoogleCodeExporter]

Ooops, I meant Lav *VIDEO* works ok when connected to AV Splitter.

Original comment by wsm....@gmail.com on 4 May 2013 at 9:24

[GoogleCodeExporter]

All right, since you cannot reproduce the video problem on your machines, I 
think you can tag this issue as "Invalid". If and when I find the solution, I 
will post the info in the LAV Filters' thread at doom9.org.

Original comment by wsm....@gmail.com on 4 May 2013 at 10:18

[GoogleCodeExporter]

I have a special status for tickets which i can't reproduce myself. :)

Are you running any other filters in the graph that may cause this?
Or just plain LAV + LAV + some renderer? Maybe ffdshow for video 
post-processing?

If you figure out which factor is responsible, do let me know, maybe i can fix 
something.

Original comment by h.lepp...@gmail.com on 4 May 2013 at 10:21

• Changed state: CannotReproduce

[GoogleCodeExporter]

I stopped using ffdshow's raw video filter ages ago. The playback chain is 
always:
File Source(async) -> Splitter -> Decoders -> Renderers.

As an off-topic but necessary note, I'm glad to confirm that the performance 
issues of the RealMedia demuxer were solved "sometime between February of 2012 
and April of 2013" :-)

Again, many thanks for the great job =^.^=

Original comment by wsm....@gmail.com on 5 May 2013 at 12:26

[GoogleCodeExporter]

I think I've found something important :-)
When the sample file "~v_VFW-a_ACM.mkv" is demuxed by SolveigMM Splitter or by 
AV Splitter, the output pin says "bFixedSizeSamples=TRUE, 
bTemporalCompression=FALSE",
BUT when it's demuxed by LAV Splitter, the output pin says the opposite, id 
est, "bFixedSizeSamples=FALSE, bTemporalCompression=TRUE" 0_o

Hope this helps.

Original comment by wsm....@gmail.com on 23 May 2013 at 10:53

[GoogleCodeExporter]

These two values are basically not read by anything, so they are not relevant.

Original comment by h.lepp...@gmail.com on 24 May 2013 at 8:08