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

[Baptiste Coudurier]

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.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org