On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos <ceffm...@gmail.com wrote: > 2019-02-07 0:57 GMT+01:00, Jan Ekström <jee...@gmail.com>: > > From: Masaki Tanaka <maki.r...@gmail.com> > > > > Seems to fix mistaken cases of discontinuity handling in MPEG-TS > > when program structure changes. > > > > Additional changes to patch from its original state by Jan Ekström. > > --- > > > > Had been meaning to post this for comments/discussion for a while, as > > this seems to make timestamps continuously rising in at least one of > > my samples where the program structure changes mid-stream. > > > > The original version of this patch can be found at: > > > https://github.com/jeeb/ffmpeg/commit/6117366eaadbaf48bbd88eb2a353dfc852ff3400 > > > > The sample for which this helped is available at: > > https://kuroko.fushizen.eu/samples/pid_switch_sample.ts > > > > The difference of timestamps received from libavformat can be seen with: > > > https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png > > Am I correct that even with this patch, the sample cannot > be decoded / played correctly with FFmpeg / FFplay? > > No opinion about the patch, just curious, Carl Eugen >
Yes, ffmpeg.c at least is static in its stream selection (and probably so is ffplay.c) so they would ignore the other video stream either before or after the switch depending on how much you probe and if you do manual stream selection. That said, this is a simple sample (no alternatives, just a clear cut switch) so -merge_pmt_versions 1 should work for it to get both the sd and hd parts decoded. This attempts to re-use a previous AVStream when a stream is removed. We do have the mechanism in mpegts.c to signal that a program's structure has changed, but unfortunately it has not been utilized in ffmpeg.c. Jan > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel