[FFmpeg-devel] [PATCH] fix stream copy

[Baptiste Coudurier]

On 02/01/2010 12:07 PM, Michael Niedermayer wrote:
> On Mon, Feb 01, 2010 at 11:37:57AM -0800, Baptiste Coudurier wrote:
>> On 02/01/2010 11:16 AM, Michael Niedermayer wrote:
>>> On Mon, Feb 01, 2010 at 07:53:54PM +0100, Michael Niedermayer wrote:
>>>> On Fri, Jan 29, 2010 at 03:01:20PM -0800, Baptiste Coudurier wrote:
>>>>> On 01/27/2010 01:47 AM, Maksym Veremeyenko wrote:
>>>>>> Baptiste Coudurier ???????(??):
>>> [...]
>>>>
>>>>>
>>>>> With your patch the definition would become wrong in some cases.
>>>>>
>>>>>>>
>>>>>>> One other possible solution is to use pts.val when stream copy is
>>>>>>> used.
>>>>>>>
>>>>>> it will require changing another part of code where ost->sync_opts used
>>>>>> for stop condition or keep previous packet pts to calc duration of
>>>>>> previous packet....
>>>>>>
>>>>>
>>>>> Hummm, I'm not sure what you mean, but this seems to fix the issue for
>>>>> me.
>>>>> Can you confirm ?
>>>>>
>>>>> The idea is to only use sync_opts if the codec time base of the output
>>>>> looks like a frame rate.
>>>>>
>>>>> Michael what do you think ? I'm not sure why video is treated
>>>>> separately.
>>>>
>>>> i think audio should use sync_opts as well, but this will need some minor
>>>> changes i suspect
>>>
>>> changed my mind, is there a reason why you did not just drop the sync_opts
>>> case for video andmake it use what audio does?
>>> ill probably commit that very soon unless i notice some breakage
>>
>> No, I already suggested that. That's why I asked you why the video case was
>> handled differently.
>
> it breaks the reg tests it seems

It seems there is one frame too much in the output because opts.val is 
the current value while sync_opts is the next value.

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