On Fri, Oct 21, 2016 at 6:32 PM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > The design one fist: This approach is fundamentally wrong. Edit lists are > meant to be applied at presentation level, not packet level. The current > implementation will cause problems in a number of cases: > > * Audio packets. Especially audio packets with a large number of samples. > It's extremely likely that edits will not fall on packet boundaries, and > depending on the number of samples per packet, audio sync issues can and > will occur, even with smaller packets of e.g. 1024 samples, if there are > a large number of entries in the edit list. Gradual loss of sync will > occur. > * Edit list entries that are out of order, or repeat. This one is obvious; > simply dropping packets is not sufficient to create a virtual timeline > like edit lists can be used for by various NLEs. I need to look up > if these are actually allowed in the ISOBMFF of QT specs, but I know > Matroska allows it in its virtual timeline feature. > * Returning timestamps that differ from the codec timestamps. I very > much disagree with this approach. It's the responsibility of the > presentation/render/transcode/app/whatever layer to adjust timestamps > based on edits. I absolutely disagree with libavformat changing > timestamps from what is coded in the actual file. avformat provides > demuxers.
Hi Sasi, Derek, As I see people having issues with this implementation, is there an existing structure we can utilize to export the edit list information? (aka "can something like the chapters structure be utilized") If not, what would be the requirements based on qtff and ISOBMFF for virtual timelines? Does the demuxer have such a structure already in place after which the new metadata for virtual timelines could be based on? We will have to take baby steps towards getting this stuff right. The first step IMHO would be to export the edit list from the demuxer so that the presentation layer can utilize its information. Hints on where this information should be gathered from now that (I think) we have the parsing code in the demuxer in place are very welcome as well. After we get the edit list export right, we will have to try and integrate it into the mess that is ffmpeg.c. Best regards, Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
