On Sat, Aug 27, 2016 at 03:30:24PM -0700, Sasi Inguva wrote: > On Fri, Aug 26, 2016 at 5:55 PM, Michael Niedermayer <mich...@niedermayer.cc > > wrote: > > > On Fri, Aug 26, 2016 at 12:49:19PM -0700, Sasi Inguva wrote: > > > I think there is some bug in mp3 decoder which is making skip > > > samples -1431655766 for ~/tickets/5528/fire.mp3 . For now I have removed > > > the assert from the 3rd commit. > > > For the file one.mov , I think the audio has edit list with start time > > > correspending to the second sample - (which should be media time 1024 if > > I > > > guess correctly). This indicates that the first sample be used for > > encoder > > > delay. > > > Previously without edit list parsing , we used to offset the start_dts > > by > > > -1024 to make the second sample timestamp start from zero. > > > sc->time_offset = start_time - empty_duration; > > > - current_dts = -sc->time_offset; > > > if (sc->ctts_count>0 && sc->stts_count>0 && > > > > > > But now edit list parsing handles the rebasing of timestamps to zero, > > > because it will assign increasing timestamps starting from zero, to > > > samples present in the edit list. > > > > > Because the first sample is not in the > > > edit list, we mark it as DISCARD, which flag av_decode_audio4 will look > > at > > > and decode-and-discard that frame. So it wouldn't matter what the first > > > sample timestamp should be assigned because it is anyway discarded after > > > decode. > > > > current applications using libavformat have no knowledge of the > > discard flag you can add the DISCARD flag, you can set it on packets but > > applications written or built for libavformat 57 dont have to know > > this flag and can treat the packets like any other packet. > > > > Yes. they can treat the packet like any other packet. They don't have to > know about the discard flag. > > Adding this feature without a major version bump requires things to > > still work reasonable with the old semantics that apps are build > > around. That should be possible unless iam missing something > > > As I have pointed out earlier this code will change the timestamps of the > packets. In the case of multiple edit lists, the code will also repeat some > packets, and might make the timestamps non-monotonous. I don't know if the > last behavior is not an acceptable expectation from av_read_frame.
if timestamps repeat then it will not be possible to seek in the file by timestamp (to all positions) and i suspect also not by byte position. How would one seek then ? or do i misunderstand ? > However as I've pointed out, we are already showing the wrong packets for > videos with multiple edit lists by not parsing the edit lists currently, > which will introduce AVSync issues. So this patch wont make things any > worse for those cases in my view. Is it difficult to adjust the timestamps of discarded packets to avoid timestamp discontinuities ? (for the cases where this is possible of course only) the timestamps for discarded packets i would assume are meaningless in the new semenatics but they matter for the old semantics again, please correct me if iam wrong [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
