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

[Michael Niedermayer]

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     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100620/cc342404/attachment.pgp>