[MPlayer-users] MKV demuxing problems on some files with lavf

[Vladimir Mosgalin]

Hi Carl Eugen Hoyos!

 On 2010.12.31 at 14:55:30 +0000, Carl Eugen Hoyos wrote next:

> As said it works for me with a 32 stream (video+audio) file, because after "Too
> many streams", it tries other demuxers:
> [matroska,webm @ 0x16b8a20] Too many streams               
> LAVF_header: av_open_input_stream() failed                 
> Checking for YUV4MPEG2                                     
> ASF_check: not ASF guid!                                   
> Checking for REAL                                          
> Checking for SMJPEG                                        
> [mkv] Found the head...                                    

Maybe this was implemented very recently, my mplayer is almost 3 months
old. I'll try to compile newer version when I have time (since I'm using
several mplayer patches that are important for me but aren't in tree, i
have to tweak them a bit each time I update my mplayer source so they
will apply).

> Could you try with a file with too many audio streams (instead of subtitles) or
> make your sample available so we can try to reproduce the problem?

I gave link to my sample, direct link to .torrent is
http://www.nyaatorrents.org/?page=download&tid=179110 - you can download
any of 14 episode files from that torrent to see the problem.

If torrent is really inconvenient I could upload a file to mplayerhq but
.mkv can't really be processed by dd so it would have to be 400 mb
sample at least.

I could also upload ending, 36 mb only but it doesn't show the problem
because it doesn't use Myriad Pro or other fonts that are outside range
of 20 streams, and "Too many streams" is the only sign of a problem on
that file.

> 
> > Also note ffmpeg -i output in the end of mail which shows problem even
> > better than mplayer -v.
> 
> The FFmpeg problem is known, see issue963.

Well that issue is reported and explained over a year ago and now it's
"closed" but still unfixed, I mean maybe for developers it's "fixed"
but how does that matter if old API is activated and no one can use
solution, and the bug is "closed" though it's still here >.<

So I guess we could concentrate on why mplayer doesn't switch to next
demuxer. Though, honestly, I find it a bit sad that it's easier to
workaround such problem in mplayer when it's known and unfixed for
a year in libavformat, which you described as "actively maintained
demuxers"..


-- 

Vladimir