[FFmpeg-devel] [PATCH] fix stream copy

[Michael Niedermayer]

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 ???????(??):
>> [...]
>>> Yes, pkt->duration might not be set for some reasons.
>>> Did you test this ?
>> i missed that situation.
>>
>> If pkt->duration is 0 (unknown) i do not know how to handle this
>> situation properly.
>>
>> So alternative patch "fix stream copy for most cases..." could looks like:
>>
>> Index: ffmpeg.c
>> ===================================================================
>> --- ffmpeg.c (revision 21473)
>> +++ ffmpeg.c (working copy)
>> @@ -1484,7 +1484,10 @@
>> audio_size += data_size;
>> else if (ost->st->codec->codec_type == CODEC_TYPE_VIDEO) {
>> video_size += data_size;
>> - ost->sync_opts++;
>> + if(pkt->duration)
>> + ost->sync_opts += av_rescale_q(pkt->duration, ist->st->time_base,
>> ost->st->codec->time_base);
>> + else
>> + ost->sync_opts++;
>> }
>>
>> opkt.stream_index= ost->index;
>>
>
> Well the problem is the definition of sync_opts:
>     int64_t sync_opts;       /* output frame counter, could be changed to 
> some true timestamp */ //FIXME look at frame_number

its already used as timestamp in the code, the comment is outdated


>
> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20100201/ce0a238d/attachment.pgp>