[FFmpeg-devel] [PATCH] lavf/utils: update default wrap-around reference while iterating streams

Jan Ekström jeebjp at gmail.com
Thu Feb 7 21:26:19 EET 2019


On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> 2019-02-07 8:18 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> > On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos <ceffmpeg at gmail.com wrote:
> >
> >> 2019-02-07 0:57 GMT+01:00, Jan Ekström <jeebjp at gmail.com>:
> >> > From: Masaki Tanaka <maki.rxrz at 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


More information about the ffmpeg-devel mailing list