On Sat, Dec 15, 2018 at 3:50 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > 2018-12-15 2:31 GMT+01:00, Jan Ekström <jee...@gmail.com>: > > Fixes issues when a subtitle packet is received before PCR for the > > program has been received, leading to wildly jumping timestamps > > on the lavf client side as well as in the re-ordering logic. > > > > This usually happens in case of multiplexes where the PCR of a > > program is not taken into account with subtitle tracks' DTS/PTS. > > For which sample does this make a difference? > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi, This pops up unfortunately with various broadcast channels, but here's one sample which shows it rather clearly: https://kuroko.fushizen.eu/samples/2018-04-04-funky_teletext_mux.cut.ts Steps to show difference: 1. ffprobe -of json -show_packets -show_programs - > with_skipping.json 2. ffprobe -skip_pes_packets_without_pcr none -of json -show_packets -show_programs - > no_skipping.json 3. git diff --no-index no_skipping.json with_skipping.json This shows that libavformat does receive the initial subtitle packet with a timestamp that is wildly incorrect (due to the PID's mux being bonkers). After PCR is received, the timestamp fixing logic that is enabled by default kicks in, and the subtitle packets are matched against the PCR (which is what many broadcasters just assume receivers will do). Technically I think waiting for PCR is mandatory for all tracks in MPEG-TS, but since I don't generally see such discrepancies outside of subtitle tracks I matched this up with the subtitle timestamp fixing code for now, in order to see people's opinions on this. Best regards, Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
