[FFmpeg-devel] [patch] export pmt and pcr pids from mpegts demuxer

Michael Niedermayer michaelni
Sun Jul 11 20:53:41 CEST 2010

On Sun, Jun 20, 2010 at 04:11:24PM -0700, Baptiste Coudurier wrote:
> On 6/20/10 2:48 PM, Michael Niedermayer wrote:
>> On Sun, Jun 20, 2010 at 01:24:54PM -0700, Baptiste Coudurier wrote:
>>> On 6/20/10 12:34 PM, Michael Niedermayer wrote:
>>>> On Sun, Jun 20, 2010 at 08:41:11AM -0400, Mike Scheutzow wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> On Sat, Jun 19, 2010 at 09:35:41AM -0400, Mike Scheutzow wrote:
>>>>>>> Baptiste Coudurier wrote:
>>>>>>>> On 06/10/2010 03:45 PM, Michael Niedermayer wrote:
>>>>>>>>> metadata (that is data describing the video and audio content) can 
>>>>>>>>> be
>>>>>>>>> copied
>>>>>>>>> blindly.
>>>>>>>>> The problem is that pcr_pid&    pmt_pid is not data describing the
>>>>>>>>> video/audio
>>>>>>>>> its data describing the mpeg stream
>>>>>>>> It's the same as major brand from mp4.
>>>>>>>> We are turning around here.
>>>>>>>> Polluting AVStream/AVFormatContext with this format specific
>>>>>>>> information
>>>>>>>> seems ugly to me. We are not going to add a field for every value we
>>>>>>>> want to export.
>>>>>>>> So what do you propose ? Another field which is not called metadata 
>>>>>>>> ?
>>>>>>> Michael,
>>>>>>> I agree with Baptiste that adding very format-specific fields to
>>>>>>> AVProgram or AVStream makes the API more difficult to understand.
>>>>>>> Please give me a hint about an implementation that you would find
>>>>>>> acceptable.
>>>>>> Please elaborate on how and for what they would be used:
>>>>>> "iam not saying to put them in AVStream, actually iam not sure myself
>>>>>> where
>>>>>>    to put them, maybe you can elaborate a bit on the use cases of 
>>>>>> these
>>>>>> fields?
>>>>>>    Extending AVOptions to allow accessing demuxer specific contexts 
>>>>>> might
>>>>>> be
>>>>>>    an option maybe but then maybe not iam not sure."
>>>>>> I cant make a suggestion if i dont know exactly what these fields 
>>>>>> would
>>>>>> be
>>>>>> used for. I can read the mpeg spec but that will take time
>>>>> The scenerio is transcoding transport stream to transport stream.
>>>>> I need the output stream to keep the same pid values as the input.
>>>>> The FFmpeg library does not provide enough capability to accomplish 
>>>>> this.
>>>>> So the first step is to make the input side pmt/pcr pid values visible 
>>>>> to
>>>>> the application (i.e. this patch).
>>>>> The next step is to improve the mpegts muxer to use app-supplied 
>>>>> values.
>>>> I still have no idea what you want to do. As said i can surely check the
>>>> mpeg spec and that will likely awnser it but from your description its 
>>>> not
>>>> clear to me, as example if id tell you i want to transcode foo to foo 
>>>> and
>>>> need to keep the bar values that also tells you nothing.
>>>> so why do you need to keep these values?
>>>> are we talking about a mpeg spec requirement that isnt met by ffmpeg?
>>>> are we talking about a specific use case where specific values are 
>>>> needed?
>>>> ffmpeg should just work transcoding fileX to fileY, what am i missing?
>>>> i also should be able to do mpegts->avi->mpegts and no matter what api
>>>> you would loose the extra values that way
>>> Michael, I'm not sure what you are trying to say here, but even myself I
>>> don't understand what you mean.
>>> Keep in mind that we export the mp4 branch type as well.
>> brand IIRC ;)
>> and the brand specifies to which "sub-spec" of mpeg4 a file is compliant 
>> to
>> that is each brand ->  set of rules a file complies to
>> there can be multiple brands if a file complies to multiple specs.
>> So for example if it contains a h264 stream it contains the "avc1"
>> brand indicating that it complies to the specific spec
>> That is the way i understand it.
>> I dont really mind if its exported as:
>> "mp4/major_brand" "3gp2"
>> "mp4/compatible_brand" "isom"
>> "mp4/compatible_brand" "iso2"
>> as long as no better way to export it, is available
>> without the mp4/ though its ambigous if its normal metadata or file
>> details
>>> I don't care if user wants to know the pmt pid or not, if it's useful for
>>> somebody and simple to export, then let's do it.
>> yes but maybe  .... if i better understand it, there would be a cleaner
>> way than just exporting it like that
>> I simply feel i understand this too poorly to make a decission
>> for example highly format specific values in a stream can be made
>> available through AVOptions on the private context.
> Metadata API is way simpler from the user point of view.
>> or if we have a seperate strea, internally in the mpeg ts demuxer
>> that carries a table of some kind, why for example is that stream
>> not exportet like audio and video streams?
>> and pids why are they not in AVStream.id ?
> pids are in AVStream.id for exported streams.
> PMT stream contains Section data which is MPEGTS specific, exporting all 
> data tracks seems really overkill and furthermore it would be hard to 
> distinguish which one is the PMT stream.


anyway if you still think metadata is the right spot, i dont mind though
i dont think it is the semantically correct place. And i think it will
cause problems like when copying metadata.
Even if metadata isnt copied by default, a user can choose to copy it
and then pmt_pid will be copied to and that wont make any sense
in the destination format


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100711/43e320fa/attachment.pgp>

More information about the ffmpeg-devel mailing list