[DVDnav-discuss] question regarding data coming from libdvdnav

[Sergey 'Jin' Bostandzhyan]

On Thu, Nov 20, 2008 at 12:55:10AM +0100, Nico Sabbi wrote:
> > I have a question regarding data that is coming from libdvdnav.
> > 
> > The text below may seem a little off topic, but please stay with me here,
> > I would appreciate any hints regarding this matter :)
> > 
> > The reason behind the question is: we observed various problems when feeding
> > the data to players (I'm not talking mplayer or vlc, but hardware players like
> > the DSM-510, PlayStation 3 and others). In our setup the player gets the
> > data from a HTTP server that is embedded into the application, the data
> > comes from a ripped iso, the data is read with the help of libdvdnav.
> > 
> > Some players will simply crash after a couple of minutes of play or will
> > immediately refuse to play the stream. Others will play, however with an
> > effect like on the old vinyl records - from time to time parts of the video 
> > are being looped.
> > 
> > We tried to plug in a transcoder (like vlc, ffmpeg, mencoder) and remux the
> > stream to ts, this seemed to generally enable playback on devices that refused
> > to play the original data, however the success rate was low: the transcoding 
> > apps were not handling the on the fly remuxing too well. I only had some 
> > success with mencoder, however from time to time it printed messages like:
> > "1 duplicate frame(s)!" or "Skipping frame!" and the "looping effect" could
> > be observed on the player.
> > 
> > So, back to the original question: what kind of MPEG comes from libdvdnav?
> > Is there anything "special" about it? Is it normal PS or is it PES? Do you 
> > have any idea on what might be causing troubles for the decoding apps?
> 
> PS including the PSI/DSI/NAV packets (that shouldn't cause any problem)

So the only difference from the "normal" MPEG2 that one would encode
himself are these additional packets, right?

> > Of course it's difficult to guess why some player with proprietary black box
> > firmware is crashing, but since MPEG2 files encoded in a "normal" way work, 
> > it must be something special, related to the data coming from the DVD.
> 
> maybe those players don't like the NAV packets, but in this case they
> are *really* broken. You can discard them when the event returned by
> dvdnav_stream_read() is DVDNAV_NAV_PACKET

We are discarding the NAV packets, actually the menus.c example app that
is shipped with libdvdnav and that I used to reproduce the problem does
not write the NAV packets to the output mpeg.

What about those PSI and DSI packets?
 
> > To make sure that it is not a bug within my app I tried extracting an mpeg from
> > my test iso using libdvdnav/libdvdread 4.1.3 (this is also the version that
> > I am currently running), I used the "menus" example application that comes 
> > with libdvdnav. After ripping the mpeg I tried streaming it with the DSM-510 
> > and it also crashed.
> 
> what is DSM-510 ?

One of the UPnP players that I use for testing with my server:
http://www.dlink.com/products/?model=DSM-510

We also observed problems playing back media that comes from libdvdnav
with other devices.

> > The image is CSS-free, so decryption is not involved.
> > 
> > My app is an open source UPnP media server, so you guys will make a lot of
> > people happy if you help me to resolve this problem :)
> > 
 
> can you post a title to reproduce this problem and the instructions to
> generate the network stream?

Do you mean the original iso or the extracted part? I could offer both if
needed, the iso is about 4GB.

Right now I have a 258MB version of an extracted mpeg (extracted using menus.c,
I (s)kipped about 5 times and then (a)ppended cell to the output, then (q)uit).
When streaming this to the DSM-510 it crashed the device once at around 0:0:34 
and once at 0:0:57, I'll email you the URL to the file directly (off the list).

Do you see anything suspicious there?

I am not sure if the network stream scenario would help, you'd need some
hardware device for testing, because mplayer has no problems streaming 
that data.

My minimalistic test scenario with the DSM-510 comes down to a HTTP GET
request from the palyer to the webserver to stream an mpg which I previously
ripped out of the iso with the help of the "menus" example program.

If you think that it makes sense, I can give you a detailed walkthrough on how 
to reproduce the complete setup, but I guess we should probably wait till
you had a look at that test file?

Thanks for the fast response!

Kind regards,
Jin