On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > 2019-02-07 8:18 GMT+01:00, Jan Ekström <jee...@gmail.com>: > > 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. > > Thank you, I forgot about this switch: The original timestamp issue > is not reproducible with -merge_pmt_versions, right? >
Just replicated my tests, and yes you are correct. The change seems to happen because AVPrograms get updated as the programs change, but current wrap reference will not get updated accordingly. The patch seems to help but I am not 100% sure of the logic (given that taking in both very high and low values makes it possible to pick a different reference depending on the order of the streams within the AVProgram). If someone's interested in how I checked (PID 0x121 is the one that pops up first and thus merge_pmt_versions will only export it): 1. vanilla, with AVStream merging: ffprobe pid_switch_sample.ts -select_streams "0#0x121" -show_frames -of json -merge_pmt_versions 1 > 121_track_merged.json 2. vanilla, without AVStream merging: ffprobe pid_switch_sample.ts -select_streams "0#0x121" -show_frames -of json > 121_track.json 3. see the difference with a plotting script located @ http://up-cat.net/p/0f8b428a pts_plotter.py 121_track.json 121_track_merged.json 4. patched, same command as step 2 as 121_track_patched.json or so 5. see the difference with the plotting script pts_plotter.py 121_track.json 121_track_patched.json You can also do the same with PID 111 (the HD PID) with regards to vanilla VS patched. Results are rather similar. > Carl Eugen > (who hopes you can use fieldmatch to watch this...) fieldmatch,decimate should be OK for the show itself, but generally I am lazy and use yadif for non-encoding (viewing) cases. That makes sure that all the useless advertising that often is fully interlaced will also be correctly shown. Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
