[FFmpeg-devel] [patch] export pmt and pcr pids from mpegts demuxer
Michael Niedermayer
michaelni
Sun Jun 20 23:48:00 CEST 2010
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.
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 ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/2ebd0ccf/attachment.pgp>
More information about the ffmpeg-devel
mailing list