[FFmpeg-user] Problem with using pipe:1 when creating webm audio

[Cley Faye]

2016-06-27 19:11 GMT+02:00 Mike Speciner <ms at alum.mit.edu>:

> I'm attempting to create a webm audio on the fly within my website, with a
> command like
>
> ffmpeg -i one2twenty.wav -aq 6 -dash 1 -f webm pipe:1 > foo.d1p
>
> although the piped output is actually being sent out over the web; I just
> redirected it to file in the above so I could investigate it. If instead I
> do
>
> ffmpeg -i one2twenty.wav -aq 6 -dash 1 -f webm foo.d1f
>
> I get a similar file, but slightly shorter. The problem is that the piped
> version (foo.d1p) doesn't work properly in firefox--apparently there is
> something wrong with the cues and firefox (using the <audio> element)
> claims the audio is not seekable and won't seek into it, although it will
> play it from the beginning. There is no such problem with the directly
> written version (foo.d1f).
>
> Do I have to do something special to get the piping to work, or do I have
> to fall back to writing the file and then reading it back in to serve it? I
> discovered this problem using ffmpeg 2.7.2, but I've now tried it with
> ffmpeg 3.1, and it still fails the same way.
>
> By the way, I tried to submit a bug report (assuming this problem is
> actually an ffmpeg bug), but when I attempted to register, the system
> claimed my registration was spam without giving me any clue as to why.
>

​I don't think it is really a bug in ffmpeg: the output using a pipe can't
obviously move back to update the header when the transcoding operation is
complete​ to create a seek table. Seeking in such a stream should (IMO)
rely on the player's abilities to build such seeking index.

If it's really a header problem, I don't think using a pipe to produce such
file can ever work; if I remember correctly, in a webm the seeking entries
are located before the actual streams and are updated after said streams
are written.