[MPlayer-users] nsv problems

[Lunadog]

> > 
> > > http://72.35.226.80:9138
> > 
> > Works perfectly.
> >
>

This one does not work perfectly. I got the following output with
demuxer 35:

nsv_resync(), offset = 76726, state = 0
NSV resynced on BEEF after 2 bytes
NSV CHUNK 0 aux, 570 bytes video, 273 bytes audio
nsv_read_packet: using cached packet[0]
nsv_read_packet()
nsv_read_packet: using cached packet[1]
nsv_read_packet() A-V: -2.357 ct: -0.283  52/ 52  8%  2%  2.3% 0 0 67% 
nsv_read_chunk(0)
nsv_resync(), offset = 77576, state = 0
NSV resynced on BEEF after 2 bytes
NSV CHUNK 0 aux, 628 bytes video, 261 bytes audio
nsv_read_packet: using cached packet[0]
nsv_read_packet()
nsv_read_packet: using cached packet[1]
nsv_read_packet() A-V: -2.400 ct: -0.289  53/ 53  8%  2%  2.3% 0 0 67% 
nsv_read_chunk(0)
nsv_resync(), offset = 78472, state = 0
NSV resynced on BEEF after 2 bytes
NSV CHUNK 0 aux, 683 bytes video, 117 bytes audio
nsv_read_packet: using cached packet[0]
nsv_read_packet()
nsv_read_packet: using cached packet[1]
nsv_read_packet()
nsv_read_chunk(0)
nsv_resync(), offset = 79279, state = 0
NSV resynced on BEEF after 2 bytes
NSV CHUNK 0 aux, 1872 bytes video, 222 bytes audio
nsv_read_packet: using cached packet[0]
nsv_read_packet()
nsv_read_packet: using cached packet[1]


MPlayer interrupted by signal 11 in module: decode_video
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in
DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in
your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions
there. We can't and
won't help unless you provide this information when
reporting a possible bug.

This is an intermittent problem.. more prevalent when the server is
busy? When changing streams???

Also, although the demuxer 35 option does seem to work with the other
streams, it is not an option for my program since it is impossible to
work out what type of stream it will be prior to playing it. 

The result at present, is that users have to put up with program
lockups requiring ctrl-c or xkill and then type in the other option
manually. Although okay for a workaround, it is no good for a
permanent solution.

It would be much better if all nsv files played with the nsv demuxer,
or mplayer automatically selected the correct demuxer. Of course, this
is just a wish on my part. At present, mplayer is still the best
option. It would be a shame if vlc overtook mplayer in terms of codec
handling.

James