Le 29/07/2015 22:41, Hendrik Leppkes a écrit :
On Wed, Jul 29, 2015 at 8:15 PM, Sasi Inguva <is...@google.com> wrote:
@Reimar:
True about the stream duration being wrong if stream timestamp does not
start at 0 . I just duplicated the logic to compute the total duration. In
which case, the total duration as it is computed now, is also wrong.
Printing the durations out in the logs, and then parsing the logs to get
the stream durations would require a big architectural change on my side.
It would be far more convenient if I could get the stream durations from
AVStream object.
FFmpeg does write one seek entry for every cluster in the end of the file.
I could possibly seek to all the cluster seek entries, then try to find
the last cluster for each track. But in the worst case, even this would
translate to demuxing of whole file because, suppose the audio is small
enough to totally fit in one cluster , but the start of the cluster is a
video packet to make sure that I have got the end of the audio stream I
have to parse the whole cluster. Also it seems very complicated logic to
determine the durations.
Still writing metadata to every single mkv muxed with ffmpeg to fix
your specific use-case seems rather terrible.
We shouldn't be writing extra metadata to serve one special use-case,
just so you can avoid a bit of code shuffling on your end.
If you can clarify how this could be useful genericall, we might
consider it differently.
Lot of people wish to have duration per stream in order to check that
the transcoding did not change the duration of each stream (each stream
may have different duration) or to get some more precise information
about the file they receive (for example, some people want to reject
files which do not have the same video and audio duration).
I, as the developer of a tool which read such kind of metadata, am often
asked to provide such information per stream for Matroska/WebM files,
from different users, unfortunately I can not provide specific use case,
I can only say it is a common request.
But such request is usually binded with more metadata: data rate, count
of bytes and count of frames. FLV (OP talked about FLV) metadata usually
permits to get bit rate per stream (which is the most requested metadata
on my side, which is not possible to get without additional metadata in
Matroska when there is e.g. AVC and DTS-HD, 2 streams with variable
bitrate).
Additionally, mkvmerge already add such metadata since a couple of
versions, I guess it is also due to a request from different users.
That said, I don't like, as the developer of a tool which will read such
added metadata, to have different methods for embedding such metadata.
Why not using the same method and values (BPS, DURATION,
NUMBER_OF_FRAMES, NUMBER_OF_BYTES, _STATISTICS_WRITING_APP,
_STATISTICS_WRITING_DATE_UTC tags, non binary) as mkvmerge in order to
have something which could be useful more generically?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
