Multiple substreams in mpeg-ts pids? (blueray)

Hi,
some time ago someone (maybe Ian Collins?) posted a table describing
the correspondance between stream_id and stream types in blueray,
adding (IIRC) that there can be more than one stream in the same pid.
Can anyone clarify a bit, please?
How are those streams supposed to be laid out?
Do they have at least different substream ids such as 0x80, 0x81 and so
on? If so, is the substream_id always the first byte of the payload
with the same syntax as for AC3?
Are substreams embedded in separate TS packets? 

I have a sample (walle in incoming) with pid 4352 containing
stream_id==0xfd just like for VC-1) that ffdca doesn't like:
the decoder complains of invalid DCA frames, maybe because
my demuxer is sending it some data belonging to a second substream
(maybe ac3).

Re: Multiple substreams in mpeg-ts pids? (blueray)

Hi,

2009/1/1 Nico Sabbi <nicola.sabbi <at> poste.it>:
> Hi,
> some time ago someone (maybe Ian Collins?) posted a table describing
> the correspondance between stream_id and stream types in blueray,
> adding (IIRC) that there can be more than one stream in the same pid.
> Can anyone clarify a bit, please?
> How are those streams supposed to be laid out?
> Do they have at least different substream ids such as 0x80, 0x81 and so
> on? If so, is the substream_id always the first byte of the payload
> with the same syntax as for AC3?
> Are substreams embedded in separate TS packets? 

I found that for TrueHD streams, two PES streams were interleaved on
the same PID - both had stream id of 0xfd, but could be distinguished
by their substream id.

Ian

Re: Multiple substreams in mpeg-ts pids? (blueray)

Il giorno gio, 01/01/2009 alle 12.47 +0000, Ian Caulfield ha scritto:
> Hi,
> 
> 2009/1/1 Nico Sabbi <nicola.sabbi <at> poste.it>:
> > Hi,
> > some time ago someone (maybe Ian Collins?) posted a table describing
> > the correspondance between stream_id and stream types in blueray,
> > adding (IIRC) that there can be more than one stream in the same pid.
> > Can anyone clarify a bit, please?
> > How are those streams supposed to be laid out?
> > Do they have at least different substream ids such as 0x80, 0x81 and so
> > on? If so, is the substream_id always the first byte of the payload
> > with the same syntax as for AC3?
> > Are substreams embedded in separate TS packets? 
> 
> I found that for TrueHD streams, two PES streams were interleaved on
> the same PID - both had stream id of 0xfd, but could be distinguished
> by their substream id.
> 
> Ian

ah, that stuff in the pes_extension2. Thanks and sorry for the wrong
surname :)

Re: [PATCH] rmdec.c: support for multirate files

On Wed, Dec 31, 2008 at 06:56:47PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Dec 31, 2008 at 4:22 PM, Ronald S. Bultje <rsbultje <at> gmail.com> wrote:
> > New patch attached.
> 
> As a side-note and a question: I've noticed the lack of a seek
> implementation in the RM demuxer.

considering that our seek regression test works this does not seem so

> url_fseek() has a default
> implementation that uses url_fseek().

huh?

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Re: [PATCH] rmdec.c: support for multirate files

On Wed, Dec 31, 2008 at 06:56:47PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Dec 31, 2008 at 4:22 PM, Ronald S. Bultje <rsbultje <at> gmail.com> wrote:
> > New patch attached.

[...]

> My patch adds a "cur_offset" variable that we seek to every next call
> to read_packet(). This obviously makes any sort of default seeking
> impossible, since we seek to one of the cur_offsets+framesizes
> whenever getting a new packet, thus making the previous call in the
> default av_seek() to url_seek() undone.

so your patch break the demuxer ...

> 
> My questions:

> - is it bad practice to have a cur_offset variable and seek to it?

not as such, but it can be bad practice when there is code not expecting
this in the demuxer that is not updated

> - what if I would seek to it *before* returning from av_read_packet()?
> That way, I could get rid of the cur_offset and just cache the last
> timestamp and seek to the next predicted (or forward-read) timestamp.

Iam not sure what you are trying to do ...

Re: FFMPEG fails to convert .mov - "Cannot allocate temp picture"

Hi,

fcassia wrote:
> On Sun, Dec 28, 2008 at 7:03 PM, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
>> Baptiste Coudurier <baptiste.coudurier <at> gmail.com> writes:
>>
>>>>> http://the13thfloor.org/4friends/tigani-mide2.mov
>>>>>
>>>>> No matter what I try or the target format I choose, it always fails
>>>>> with the same error:
>>>>>
>>>  >> [...]
>>>  >>
>>>>> [mov,mp4,m4a,3gp,3g2,mj2  <at>  0x177a110]stream 0, error opening file
>> //tigani-mide.
>>>>> mov: Invalid argument
>>> Your file is a reference file pointing to external file, however an
>>> error occurs when opening external file. You should check the path and
>>> access to '//tigani-mide.mov'.
>> I'm not totally convinced that this is a complete analysis, but I rather think
>> ffmpeg is missing something when reading this file (at least sound, but maybe
>> also video).
>> Did you test mplayer tigani-mide2.mov -demuxer mov ?
>>
>> Carl Eugen
> 
> Thanks Carl,
> 
> Im not encouraged to continue testing after the obvious disregard for
> bug reports by the managers of this project. The "Working fine,

Re: Internal handling of subtitles in ffmpeg

On Fri, Dec 19, 2008 at 03:49:16PM +0100, Reimar Döffinger wrote:
> On Fri, Dec 19, 2008 at 02:40:57PM +0100, Michael Niedermayer wrote:
> > I dont see the problem. Let me be more concrete
> > 
> > typedef struct AVSubtitleRect {
> >     int postype;///< 0->position encoded in data (only allowed when format is text-ASS), 
> >                      1->video (0x0..1x1) relative, 
> >                      2->screen (0x0..1x1) relative, 
> >                      3->pixel relative
> >     int format; ///< Describes what is in data, 0-> bitmap, 1->ASS based text
> >     PixelFmt pix_fmt;
> >     int x;      ///< horizontal pos in 16.16 fixed point
> >     int y;      ///<   vertical pos in 16.16 fixed point
> >     int w;      ///< horizontal size in 16.16 fixed point
> >     int h;      ///<   vertical size in 16.16 fixed point
> >     uint8_t *data[4];
> >     int linesize[4]
> > } AVSubtitleRect;
> 
> Well, obviously it can be made to work (if you insist you can use
> MPlayer as a text editor...), but to me this feels like a horribly
> complex way to pass around of strings without much of an advantage.

To come back to this thread because i belive the design of subtitle
support is important, and it would be sad if a poor design was choosen
and we would just find this out once it is fully implemented or even worse
mplayer & ffmpeg would end up going seperate pathes duplicating work ...

Let me summarize what i remember from your standpoint, please correct
me if i misremember something

Re: Internal handling of subtitles in ffmpeg

On Thu, Jan 01, 2009 at 04:19:49PM +0100, Michael Niedermayer wrote:
> Let me summarize what i remember from your standpoint, please correct
> me if i misremember something
> 1. decoders should output bitmaps 
> 2. bitstream filters should convert betweem X->ASS and ASS->X

Actually, I think bitstream filters, at least how they are done
currently are horrible for usability.
I was just thinking in terms of "quick solution that looks like a
sensible template for a future good solution"

> My suggestion
> 1. decoders output vector based AVSubtitleRects containing ASS or bitmaps
> 1b. encoders take vector based AVSubtitleRects containing ASS or bitmaps
> 2.  A renderer can converts ASS AVSubtitleRects to bitmaps
> 
> You say "this feels like a horribly complex way to pass around of strings
> without much of an advantage", can you please elaborate on this?

The "horribly complex way" passing around AVSubtitleRects with text and
coordinates.
I think I'd already be mostly okay if the char * argument was in
AVSubtitle and not AVSubtitleRects (because I do not even remotely see
a rectangular position as an inherent property of some text - though
actually that would be true also of any non-trivial bitmap subtitle
format if such a thing existed).

> The concrete problems i see with your design are
> 1. The current architecture is demuxer->decoder->encoder->muxer
>    considering that your decoders return bitmaps its no longer possible to

Re: [PATCH] rdt.c: ASM rulebook parsing and AVStream creation

On Sun, Dec 28, 2008 at 06:30:06PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> attached patch adds adding of multiple AVStreams for RTSP sessions
> containing multiple streams of identical content (but possibly
> different bitrates and/or codecs). It does so by parsing the ASM
> rulebook m= line, which is given in the SDP description. This is one
> of the prerequisites for bitrate/codec selection during playback of
> RTSP sessions.

[...]
> Index: ffmpeg-svn/libavformat/rtsp.c
> ===================================================================
> --- ffmpeg-svn.orig/libavformat/rtsp.c	2008-12-28 11:16:45.000000000 -0500
> +++ ffmpeg-svn/libavformat/rtsp.c	2008-12-28 11:17:23.000000000 -0500

iam not rtsp maintainer

besides this the patch may be ok

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

_______________________________________________
ffmpeg-devel mailing list

Re: Internal handling of subtitles in ffmpeg

On Thu, Jan 01, 2009 at 06:16:07PM +0100, Reimar Döffinger wrote:
> On Thu, Jan 01, 2009 at 04:19:49PM +0100, Michael Niedermayer wrote:
> > Let me summarize what i remember from your standpoint, please correct
> > me if i misremember something
> > 1. decoders should output bitmaps 
> > 2. bitstream filters should convert betweem X->ASS and ASS->X
>  
> Actually, I think bitstream filters, at least how they are done
> currently are horrible for usability.

Iam well aware of this, but iam not aware of any suggestions let alone
patches to improve the situation. Only that occasionally people, me
included refer to some mysterious automatic addition of bsfs that should
be implemented ...
So if you have any suggestions or patches for this, they are surely welcome

> I was just thinking in terms of "quick solution that looks like a
> sensible template for a future good solution"
> 
> > My suggestion
> > 1. decoders output vector based AVSubtitleRects containing ASS or bitmaps
> > 1b. encoders take vector based AVSubtitleRects containing ASS or bitmaps
> > 2.  A renderer can converts ASS AVSubtitleRects to bitmaps
> > 
> > You say "this feels like a horribly complex way to pass around of strings
> > without much of an advantage", can you please elaborate on this?
> 
> The "horribly complex way" passing around AVSubtitleRects with text and
> coordinates.
> I think I'd already be mostly okay if the char * argument was in