[FFmpeg-devel] Question on line 21 data in wtv

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Oct 21 12:21:39 CEST 2012

On Sun, Oct 21, 2012 at 09:39:50AM +0200, Reimar Döffinger wrote:
> On 20 Oct 2012, at 22:15, Carlos Fernandez <cfs at nova.es> wrote:
> > On Sat, Oct 20, 2012 at 6:05 PM, Reimar Döffinger
> > <Reimar.Doeffinger at gmx.de> wrote:
> >> Uh, this is _not_ the data in the wtv file, or more precisely that is not the data that Windows Media Center will use to display the CC data (though it should match for normally created files).
> > 
> >> Instead, that seems to be the data that Media Center left in the video stream (it itself does not use that, it uses the data in the subtitle streams), which you then let the video code mangle (which also means completely pointless processing since the wtv file already contains the reordered data in the subtitle streams).
> > 
> > This is quite interesting info :-) To be honest the reason I didn't
> > want to deal with the wtv in code and preferred the 'let the codecs do
> > it' was I that I had the hope that I would be able to get the CC data
> > from encrypted wtv. This was based on the assumption (proved
> > incorrect) that the standard filters would be able to open an
> > encrypted wtv provided it had been recorded in the same machine (so
> > keys would be present, etc) - so I was willing to sacrifice
> > portability for that benefit.
> I'm wondering: would you happen to have an encrypted sample that would be ok to share?
> I kind of wonder how much really is encrypted in those, if you haven't looked at it in detail there's a small chance the CC data isn't encrypted at all (though I admit that most likely they encrypted the full file).

Just for your info: none of the CC/subtitle data is encrypted, neither
the one in the video stream in the user data packets (though I do not
know if it is possible to reorder it correctly with the video data
itself being encrypted) nor the one in the subtitle streams (which
does not need to be reordered and MPlayer shows it is perfectly

More information about the ffmpeg-devel mailing list