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

[Baptiste Coudurier]

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.
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.
If user wants to use the same pid in the output ts when transcoding, 
it's fine.

Now, either you say ok to put that in AVFormatContext->metadata or you 
want to introduce a new field in AVFormatContext, using the AVMetadata 
type where I can put this information.

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