headers
Eric Sharkey | 1 Jan 2009 01:24

Re: missing audio on Wall-E Blu-Ray

On Wed, Dec 31, 2008 at 5:27 AM, Nico Sabbi <nicola.sabbi <at> poste.it> wrote:
> ahhhhh, that horror in action!
> There are 8192 pids in a transport stream and what did those bastard
> idiots do? Use a single pid (a substream in the TS) to carry 2 or more
> audio streams. Can anyone be more _IDIOT_ , willing or not ?
>
> I'm not very inclined to support that shit, but if you upload a sample
> and if I find some good mood I may give it a look without any promise.

Is it really any worse than the whole BluRay DRM fiasco?

I've uploaded the first 32MB of the file as walle_start.m2ts.  I'd appreciate
anything you can do.  I'd imagine that this affects more than just me.

Thanks,

Eric Sharkey
Permalink | Reply | 9 comments |
headers
Ilja Sekler | 1 Jan 2009 10:52
Picon
Picon

Re: Crash seeking to chapters in a multi-VTS DVD if title is gt 1

On 31.12.2008 19:02, Nico Sabbi wrote:

> Il giorno mer, 31/12/2008 alle 15.06 +0100, Reimar Döffinger ha
> scritto:
> 
>> AFAICT the dvdread API is supposed to return 0 on error (I have no
>> clue what then the point is of allowing negative values, since I
>> can't see how they would make any sense, I only see this API
>> behaviour bloating up the libdvdread code for no good reason). 
>> Problem is, dvdcss read function may also return negative values on
>> read errors, and the return values of dvdcss are passed through. So
>> we will end up with len < 0 here and thus an endless loop. Changing
>> !len to len <= 0 fixes it, and while I am in favour of such a fix
>> it breaks the dvdread API.
> 
> thanks for fixing it :)

Unfortunately, the fix for the hang seeking to chapters > max available
doesn't help against the crash
<http://lists.mplayerhq.hu/pipermail/mplayer-users/2008-December/075498.html>.
It is apparently a different bug.

--

-- 
Regards

Ilja

_______________________________________________
MPlayer-users mailing list
MPlayer-users <at> mplayerhq.hu
(Continue reading)

Permalink | Reply | 4 comments |
headers
Reimar Döffinger | 1 Jan 2009 11:22
Picon
Picon

Re: Crash seeking to chapters in a multi-VTS DVD if title is gt 1

On Thu, Jan 01, 2009 at 10:52:31AM +0100, Ilja Sekler wrote:
> On 31.12.2008 19:02, Nico Sabbi wrote:
> 
> > Il giorno mer, 31/12/2008 alle 15.06 +0100, Reimar Döffinger ha
> > scritto:
> > 
> >> AFAICT the dvdread API is supposed to return 0 on error (I have no
> >> clue what then the point is of allowing negative values, since I
> >> can't see how they would make any sense, I only see this API
> >> behaviour bloating up the libdvdread code for no good reason). 
> >> Problem is, dvdcss read function may also return negative values on
> >> read errors, and the return values of dvdcss are passed through. So
> >> we will end up with len < 0 here and thus an endless loop. Changing
> >> !len to len <= 0 fixes it, and while I am in favour of such a fix
> >> it breaks the dvdread API.
> > 
> > thanks for fixing it :)
> 
> Unfortunately, the fix for the hang seeking to chapters > max available
> doesn't help against the crash
> <http://lists.mplayerhq.hu/pipermail/mplayer-users/2008-December/075498.html>.
> It is apparently a different bug.

Well, that is no surprise. To everyone's joy libdvdread never got beyond
exporting a raw dump of the hopelessly convoluted DVD structure with
contradicting information placed all over.
Unfortunately, I do not have a DVD where the main feature is not the
first title, so I can not actually check if it works for those files,
but I think this patch might be correct:
Index: stream/stream_dvd.c
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ilja Sekler | 1 Jan 2009 11:51
Picon
Picon

Re: Crash seeking to chapters in a multi-VTS DVD if title is gt 1

On 01.01.2009 11:22, Reimar Döffinger wrote:

> Unfortunately, I do not have a DVD where the main feature is not the 
> first title, so I can not actually check if it works for those
> files, but I think this patch might be correct: [...]

Thank you very much! The patch does the magic and fixes the bug :-)

--

-- 
Regards

Ilja
Permalink | Reply | 2 comments |
headers
Reimar Döffinger | 1 Jan 2009 11:57
Picon
Picon

Re: Crash seeking to chapters in a multi-VTS DVD if title is gt 1

On Thu, Jan 01, 2009 at 11:51:03AM +0100, Ilja Sekler wrote:
> On 01.01.2009 11:22, Reimar Döffinger wrote:
> 
> > Unfortunately, I do not have a DVD where the main feature is not the 
> > first title, so I can not actually check if it works for those
> > files, but I think this patch might be correct: [...]
> 
> Thank you very much! The patch does the magic and fixes the bug :-)

Did you/can you check if it actually works right for an non-first title
with chapters? As said my test DVD had only 2 chapters (start and end)
in that title, so I could not actually test...
Permalink | Reply | 1 comment |
headers
Ilja Sekler | 1 Jan 2009 12:17
Picon
Picon

Re: Crash seeking to chapters in a multi-VTS DVD if title is gt 1

On 01.01.2009 11:57, Reimar Döffinger wrote:

> On Thu, Jan 01, 2009 at 11:51:03AM +0100, Ilja Sekler wrote:
> 
>> On 01.01.2009 11:22, Reimar Döffinger wrote:
>> 
>>> Unfortunately, I do not have a DVD where the main feature is not
>>> the first title, so I can not actually check if it works for
>>> those files, but I think this patch might be correct: [...]
>> 
>> Thank you very much! The patch does the magic and fixes the bug
>> :-)
> 
> Did you/can you check if it actually works right for an non-first
> title with chapters?

This is what I have done, sorry if it was not clear. Verified with a
patched r28220 with three different multi-VTS DVD including "Code
Inconnu" (by Michael Haneke, artificial eye No. 204) with 46 chapters in
VTS (and title) No. 6. Calling MPlayer with

./mplayer -dvd-device /dev/scd0 dvd://6 -chapter 24

(for example) or seeking to chapters with " <at> " and "!" works perfectly now.

Thank you again for the patch!

--

-- 
Regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nico Sabbi | 1 Jan 2009 12:21
Picon
Favicon

Re: missing audio on Wall-E Blu-Ray

Il giorno mer, 31/12/2008 alle 19.24 -0500, Eric Sharkey ha scritto:
> On Wed, Dec 31, 2008 at 5:27 AM, Nico Sabbi <nicola.sabbi <at> poste.it> wrote:
> > ahhhhh, that horror in action!
> > There are 8192 pids in a transport stream and what did those bastard
> > idiots do? Use a single pid (a substream in the TS) to carry 2 or more
> > audio streams. Can anyone be more _IDIOT_ , willing or not ?
> >
> > I'm not very inclined to support that shit, but if you upload a sample
> > and if I find some good mood I may give it a look without any promise.
> 
> Is it really any worse than the whole BluRay DRM fiasco?

yes: it's worse because from a technical point of view the DRM has a
reason to exist, but not the muxing of 2 audio streams in the same pid

> 
> I've uploaded the first 32MB of the file as walle_start.m2ts.  I'd appreciate
> anything you can do.  I'd imagine that this affects more than just me.
> 
> Thanks,
> 
> Eric Sharkey

thanks. I hope it's big enough
Permalink | Reply | 0 comments |
headers
Nico Sabbi | 1 Jan 2009 13:22
Picon
Favicon

Re: missing audio on Wall-E Blu-Ray

Il giorno mer, 31/12/2008 alle 19.24 -0500, Eric Sharkey ha scritto:
> On Wed, Dec 31, 2008 at 5:27 AM, Nico Sabbi <nicola.sabbi <at> poste.it> wrote:
> > ahhhhh, that horror in action!
> > There are 8192 pids in a transport stream and what did those bastard
> > idiots do? Use a single pid (a substream in the TS) to carry 2 or more
> > audio streams. Can anyone be more _IDIOT_ , willing or not ?
> >
> > I'm not very inclined to support that shit, but if you upload a sample
> > and if I find some good mood I may give it a look without any promise.
> 
> Is it really any worse than the whole BluRay DRM fiasco?
> 
> I've uploaded the first 32MB of the file as walle_start.m2ts.  I'd appreciate
> anything you can do.  I'd imagine that this affects more than just me.
> 
> Thanks,
> 
> Eric Sharkey

the good news is that all audio streams play well, although ffdca
complains of the presence of invalid DCA frames; the bad news is that
I can't yet find how the second stream is laid out, assuming there *is*
a second audio stream. I asked clarifications to the ffmpeg-devel
Permalink | Reply | 7 comments |
headers
Nico Sabbi | 1 Jan 2009 15:48
Picon
Favicon

Re: missing audio on Wall-E Blu-Ray

Il giorno gio, 01/01/2009 alle 13.22 +0100, Nico Sabbi ha scritto:
> Il giorno mer, 31/12/2008 alle 19.24 -0500, Eric Sharkey ha scritto:
> > On Wed, Dec 31, 2008 at 5:27 AM, Nico Sabbi <nicola.sabbi <at> poste.it> wrote:
> > > ahhhhh, that horror in action!
> > > There are 8192 pids in a transport stream and what did those bastard
> > > idiots do? Use a single pid (a substream in the TS) to carry 2 or more
> > > audio streams. Can anyone be more _IDIOT_ , willing or not ?
> > >
> > > I'm not very inclined to support that shit, but if you upload a sample
> > > and if I find some good mood I may give it a look without any promise.
> > 
> > Is it really any worse than the whole BluRay DRM fiasco?
> > 
> > I've uploaded the first 32MB of the file as walle_start.m2ts.  I'd appreciate
> > anything you can do.  I'd imagine that this affects more than just me.
> > 
> > Thanks,
> > 
> > Eric Sharkey
> 
> the good news is that all audio streams play well, although ffdca
> complains of the presence of invalid DCA frames; the bad news is that
> I can't yet find how the second stream is laid out, assuming there *is*
> a second audio stream. I asked clarifications to the ffmpeg-devel 
> 

well, I found out that the substreams are identified by the first
byte in the pes_extension2 payload.
The best that can be done is to let the user specify the substream_id
he want to play, because the "right one" isn't qualified in the PMT,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eric Sharkey | 1 Jan 2009 17:36

Re: missing audio on Wall-E Blu-Ray

On Thu, Jan 1, 2009 at 9:48 AM, Nico Sabbi <nicola.sabbi <at> poste.it> wrote:
> well, I found out that the substreams are identified by the first
> byte in the pes_extension2 payload.
> The best that can be done is to let the user specify the substream_id
> he want to play, because the "right one" isn't qualified in the PMT,
> and even so the codec assignment can be wrong for the same reason.
>
> Thank those genial designers for this mess.
>
> Try the attached patch specifying -ausid 0x71

Thanks.

I had to modify the patch to get it to compile (you can't initialize an extern
int, you only need to initialize it where it's actually declared in the C file).

I'm still having difficulty with the mplayer versions I've compiled myself
from svn.  I think I have all of the dependencies correct now, but when I use
this version with -demuxer lavf it seems to go into an infinite loop.
(I'll try to
debug this more later.  I'm out of time for today.)

If I skip -demuxer lavf, then the main audio portion of the file seems to play
fine now (2 channel stereo only), but I've got no video at all.  (This is
without specifying -ausid.)

Chritian Marillat's sources, which presumably were used to build the binary
that I had been running, won't even compile for me.

Eric
(Continue reading)

Permalink | Reply | 5 comments |

Gmane