[FFmpeg-devel] DVB subtitles transcoding
Wim Vander Schelden
lists at fixnum.org
Fri Nov 15 16:36:04 CET 2013
Sorry about the late reply, your message got covered underneath other mails
in my inbox.
The copy created a non-empty ts file (50KB+ for the samples I tested, 64KB
for the dvbsubtest.ts sample), but the subtitle stream doesn't seem to have
any data in its stream afterwards (much like the initial bug report
I've added a patch to the DVB subtitle bug in Track, which seems to solve
the problem of encoding subtitles: when transcoding dvbsub to dvbsub, I get
actual working subtitles from the TS, and the subtitles-only TS is about
Using -scodec copy (or your command) still gives the same results: no
subtitles being present on the new stream. I'm thinking this might have
something to do with the PES headers not being updated. The PID's in the
new stream differ from the PIDs in the old stream, so if the PIDs aren't
translated, that would explain why the subtitles don't show up.
I'm just guessing here. The video *is* working, which means it's PES
header is being correctly translated. I don't see why the subtitle remuxing
would cause any problems.
On Thu, Nov 7, 2013 at 9:26 AM, Clément Bœsch <u at pkh.me> wrote:
> On Wed, Nov 06, 2013 at 05:09:18PM +0100, Wim Vander Schelden wrote:
> > Hi all,
> > I'm trying to solve a bug in DVB subtitle decoding/demuxing, reported
> > http://trac.ffmpeg.org/ticket/2024
> > In case it matters, I'm testing with the following command line:
> > ffmpeg -v debug -i Vogelpark.ts -map 0:#0xfc5 -scodec dvbsub test.ts
> > Where Vogelpark.ts is a MPEG2-TS with one program, containing 1 video
> > stream, 1 audio stream, 1 DVB Teletext subtitle stream and 2 DVB subtitle
> > streams (one of which is on PID 0xfc5).
> > The error message that comes out is:
> > [mpegts @ 0x2648d20] Application provided invalid, non monotonically
> > increasing dts to muxer in stream 0: 551350 >= 309708
> > av_interleaved_write_frame(): Invalid argument
> I wonder if outputing a mpeg-ts stream with subtitles only is really
> appropriate for testing, you might want to remux the video stream as well.
> > I've worked out what the problem is (with the help of nevcariel, ubitux
> > others on #ffmpeg-devel):
> > 1. DVB subtitles are encoded as a series of rectangular bitmaps, and
> > they are *individually* "flushed" to be displayed using a display
> > segment packet.
> > 2. The way the DVB subtitles decoder (avcodec/dvbsubdec.c) currently
> > works, is that it keeps track of all the other segments (which define
> > regions, colour lookup tables, and contain the actual bitmaps) until a
> > display segment is encountered, at which point it renders all these
> > to an AVSubtitle.
> > 3. On the encoding side, DVB subtitles differ from other subtitle
> > because it is currently the only codec that needs to have two packets
> to do
> > its work: one to render the subtitle and one to indicate that it can
> > removed from the screen. These have (obviously) different PTS'es.
> > 4. It's possible that a later AVSubtitle appears before an earlier one
> > dissappears from the screen. In fact, it's quite common for live
> > subtitling, where each word is pushed & displayed as a separate region
> > (have a look at
> > http://samples.ffmpeg.org/MPEG-VOB/transport/dvbsub/dvbsubtest.tsfor an
> > example of this happening).
> > 5. Because the current subtitle encoding happens to write out the
> > display & clear packets for DVB in sequence, a later subtitle can
> > the above error in the muxer.
> You seem to be describing a problem involving the re-encoding process, but
> actually even the remuxing broken. Before going deeper into the subtleties
> of subtitles encoding, maybe you should look at the simpler path first,
> ffmpeg -v debug -i Vogelpark.ts -map 0:v:0 -map 0:#0xfc5 -c:s copy -c:v
> copy test.ts
> should (untested) produce a file where the subtitle stream is almost empty
> (or unreadable somehow).
> Doing this skips various hacks and the whole transcoding chain. If you
> want to fix the transcoding, I think you need to make sure it's actually
> well muxed first.
> Clément B.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel