[FFmpeg-user] Export raw (binary) subtitle data
dfnsonfsduifb at gmx.de
Thu Jun 8 22:13:45 EEST 2017
On 05.06.2017 21:31, Moritz Barsnick wrote:
> On Mon, Jun 05, 2017 at 19:35:34 +0200, Johannes Bauer wrote:
>> Oh, I thought it maybe was the actual length of the word that it
>> complained about.
> I'm not sure, I didn't look into the source code generating that
>> Hmmm, yes, unfortunate. I was hoping to get that information as well,
>> but I think that every line corresponds to one occurence -- so I can put
>> everything back together.
>> Thanks so much for your help. I'm really curious to see if I can figure
>> this out.
>> One thing made me wonder, however: What if the binary data contained
>> '\n'? Then it probably would cause me some grief, wouldn't it? Some
>> binary dump format (e.g. timestamp duration base64-encoded) would be
>> ideal to avoid this. But I'm happy with what I have now :-)
> Yes, if you rely on "one line is one geo-position", your logic gets
> borked by additional pseudo-EOL.
Yup, but I figured out so far that the data contains length info, so it
could be parsed properly... but this here:
> Another thing came to mind, since you asked: There was a patch on
> ffmpeg-devel for a "textdata" muxer (and demuxer), which would be able
> to represent arbitrary data in base64, and also support timestamps:
Would be sooooo much nicer! It's pretty much *perfectly* what I wanted!
I'll try to build ffmpeg myself (currently using the Ubuntu one) and
patch this in. Also going to subscribe to ffmpeg-dev in order to ask why
it isn't mainlined. It is *super* useful.
Thank you so much again!
> P.S.: I owe you at least two beers if you figure out from which movie
> that is. ;-) (I mapped that movie's SRT arbitrarily into a MOV file
> with mov_text, for testing.)
Oh man, no chance. Here's my wild guess:
http://www.imdb.com/title/tt3213684/ -- I don't speak any Norwegian, so
I had Google help me :-)
More information about the ffmpeg-user