> -----Original Message-----
> From: [email protected] [mailto:libav-user-
> [email protected]] On Behalf Of Stephan Aßmus
> Sent: 17 September 2009 16:09
> To: Libav* user questions and discussions
> Subject: Re: [libav-user] Concatenating movie files - duration not updated
>
> Smart, Gary schrieb:
> >> -----Original Message-----
> >> From: [email protected] [mailto:libav-user-
> >> [email protected]] On Behalf Of Vladimir Eremeev
> >> Sent: 17 September 2009 11:48
> >> To: [email protected]
> >> Subject: Re: [libav-user] Concatenating movie files - duration not
> > updated
> >>
> >>
> >> Smart, Gary wrote:
> >>> and dumping them into the output file. It then repeats this,
> > dumping
> >>> the packets out with pts values adjusted such that they continue on
> > from
> >>> the first block. The output file is then closed normally using the
> >>> ffmpeg libav functions.
> >>>
> >> You also should adjust DTS.
> >> Do you use av_write_frame or av_interleaved_write_frame?
> >> I'd use the first one, with correct adjusting DTS and PTS.
> >>
> >>
> >> Smart, Gary wrote:
> >>> 1) The resultant file, while clearly twice the size, seems to
> > contain
> >>> the same 'duration' as the original file!
> >>>
> >> How did you check this?
> >>
> >>
> >> Smart, Gary wrote:
> >>> What do I need to do to ensure that
> >>> ffmpeg writes the new duration (twice as long) into the new file?
> >>>
> >> In case of MPEGTS the duration is not stored in the file. This is a
> >> 'headless' format, it is designed to make it possible for the client
> > to
> >> connect to it from any point.
> >> FFmpeg calculates the duration. It looks at the timestamps in the
> >> beginning
> >> and in the end, and subtracts one from another.
> >>
> >>
> >> Smart, Gary wrote:
> >>> 2) I notice that closing the avFormat seems to take an awful long
> > while?
> >>> Is ffmpeg scanning the whole file in order to write the trailer or
> >>> something?
> >>>
> >> This is the first sign that something is wrong.
> >> In your case, most probably, this means that libav* has stored a lot
> > of
> >> packets in memory and now interpolates their timestamps and writes to
> >> disk.
> >>
> >>
> >> Smart, Gary wrote:
> >>> p.s. if anyone thinks they can help, I will happily send them the
> > source
> >>> code (not very long at all).
> >>>
> >> You could post it here.
> >
> >
> > OK - thanks for that. The problem did indeed appear to be dodgy dts
> > values.
> >
> > However - now that I can create a file twice the size and play it from
> > one end to another successfully, I am still wondering why it takes
> > nearly 2 minutes to close the file (a 10 minute long ts file). i.e. the
> > url_fclose call takes nearly 2 minutes!
>
> Do you use av_write_frame() or av_write_interleaved_frame()?
>
> The second form would buffer packets as it sees fit.
>
> Best regards,
> -Stephan
>
> _______________________________________________
> libav-user mailing list
> [email protected]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Sorry - I forgot to say. I'm not using write frame OR interleaved frame. This
is because I don't actually want to decode the data if I can help it. Instead,
I am doing...
Av_open this and that...
while(av_read_frame(ipFormatCtx, &ipPacket)>=0)
{
// Update the packet dts/pts
ipPacket.pts += (ipLastTs[VIL_f-1] - ipFirstTs[VIL_f-1]);
ipPacket.dts = ipPacket.pts;
opFormatCtx->oformat->write_packet(opFormatCtx, &ipPacket);
// Free the ipPacket that was allocated by av_read_frame
av_free_packet(&ipPacket);
} // end while reading frames
av_write_trailer(opFormatCtx);
url_fclose(opFormatCtx->pb);
av_free(opFormatCtx);
Perhaps there is some way to flush the packets to the file after each
'write_packet'?
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
