When using pipe output, wav files are corrupt/only usable by libffmpeg based software.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

When using pipe output, wav files are corrupt/only usable by libffmpeg based software.

Richard Rebel

Hi,

I have a situation where I need to pipe FLV into ffmpeg, have it convert
only the audio to a mono wav format, then pipe that into another program.
The final program does not use libffmpeg to read the wav data.

To give you an example, if you run this command:

 cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
-f wav -s cif - | cat - > converted-a.wav

The resulting wav file can be played by VLC, but no other tools can play
this nor understand it.  Especially not the program I wish to use in place
of the Œcat¹ at the end of the command above.

However, if I create an intermediate file like this:

 cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
-f wav -s cif converted-b.wav

The resulting wav file loads fine in VLC, and all other programs just fine.
Resulting converted-a.wav and converted-b.wav are different, the latter
being about 32kb larger than the one piped to cat.

Does anyone have any concept as to why this might be happening when using
pipe output?  I would think the resulting files should be identical, but
they aren¹t.  

Thanks for any input,

Richard

----------------------------------------------------------------------------------------------
The contents of this message may be privileged and confidential. Therefore, if this message
has been received in error, please delete it without reading it. All contents of the message,
including any attachments, are the copyright property of the sender. This message cannot in
any way bind Dentsu McGarry Bowen, L.L.C. to any contract or other obligation.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: When using pipe output, wav files are corrupt/only usable by libffmpeg based software.

Alexandre Ferrieux
On 27/07/2010 21:29, Richard Rebel wrote:

>
> Hi,
>
> I have a situation where I need to pipe FLV into ffmpeg, have it convert
> only the audio to a mono wav format, then pipe that into another program.
> The final program does not use libffmpeg to read the wav data.
>
> To give you an example, if you run this command:
>
>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
> -f wav -s cif - | cat ->  converted-a.wav
>
> The resulting wav file can be played by VLC, but no other tools can play
> this nor understand it.  Especially not the program I wish to use in place
> of the Œcat¹ at the end of the command above.
>
> However, if I create an intermediate file like this:
>
>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
> -f wav -s cif converted-b.wav
>
> The resulting wav file loads fine in VLC, and all other programs just fine.
> Resulting converted-a.wav and converted-b.wav are different, the latter
> being about 32kb larger than the one piped to cat.
>
> Does anyone have any concept as to why this might be happening when using
> pipe output?  I would think the resulting files should be identical, but
> they aren¹t.

Some formats like WAV and 3GP are intrinsically not well suited for piping/streaming, because they contain whole-file
size indicators or other such information. When ffmpeg writes a WAV file directly, it first writes placeholders for this
size information, and at the end seeks back to the beginning to write the actual value (see function wav_write_trailer
in wav.c). Of course when it writes to a pipe, the seek fails (silently), and:

     - the size in the header is not written, typically left to zero
     - the few bytes of the size are written at the end instead

I assume that this doubly invalid file can nonetheless be read by tolerant implementations of the demuxer: the absence
of total size can be worked around by equating it with infinity (== to the end of the stream), and the extra garbage
just looks like a few extra samples, or an invalid tag.

Another thing to keep in mind is issue 498: even when stdout is a regular file (not a pipe), the wav muxer fails to
flush the last <32k block of data... Of course this doesn't cause problems for continued piping, but I mention it just
in case you switch to regular files ;-)

-Alex

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: When using pipe output, wav files are corrupt/only usable by libffmpeg based software.

Richard Rebel

Thank you Alexandre,

That is exactly what I see when I vbindiff the two files.  There are
suspicious 00's in the beginning of the file captured from pipe output that
are populated in the file that was written directly to disk.

The program I am trying to feed data to can also accept "RAW(BE)".  I don't
see this as a potential format or codec in ffmpeg's list of these.  There is
one for RAW video, but I'm not sure that is the same thing.

Is there a way to get ffmpeg to generate this type of stream?

FYI I am trying to feed the audio to julian, a voice to text translator that
has a minimal dictionary.  My only other recourse is to change it's handling
of wav data and I'd rather not for an OSS project for what would amount to a
kludge.

Thanks,

Richard


On 7/28/10 3:25 AM, "Alexandre Ferrieux"
<[hidden email]> wrote:

> On 27/07/2010 21:29, Richard Rebel wrote:
>>
>> Hi,
>>
>> I have a situation where I need to pipe FLV into ffmpeg, have it convert
>> only the audio to a mono wav format, then pipe that into another program.
>> The final program does not use libffmpeg to read the wav data.
>>
>> To give you an example, if you run this command:
>>
>>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
>> -f wav -s cif - | cat ->  converted-a.wav
>>
>> The resulting wav file can be played by VLC, but no other tools can play
>> this nor understand it.  Especially not the program I wish to use in place
>> of the Œcat¹ at the end of the command above.
>>
>> However, if I create an intermediate file like this:
>>
>>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
>> -f wav -s cif converted-b.wav
>>
>> The resulting wav file loads fine in VLC, and all other programs just fine.
>> Resulting converted-a.wav and converted-b.wav are different, the latter
>> being about 32kb larger than the one piped to cat.
>>
>> Does anyone have any concept as to why this might be happening when using
>> pipe output?  I would think the resulting files should be identical, but
>> they aren¹t.
>
> Some formats like WAV and 3GP are intrinsically not well suited for
> piping/streaming, because they contain whole-file
> size indicators or other such information. When ffmpeg writes a WAV file
> directly, it first writes placeholders for this
> size information, and at the end seeks back to the beginning to write the
> actual value (see function wav_write_trailer
> in wav.c). Of course when it writes to a pipe, the seek fails (silently), and:
>
>      - the size in the header is not written, typically left to zero
>      - the few bytes of the size are written at the end instead
>
> I assume that this doubly invalid file can nonetheless be read by tolerant
> implementations of the demuxer: the absence
> of total size can be worked around by equating it with infinity (== to the end
> of the stream), and the extra garbage
> just looks like a few extra samples, or an invalid tag.
>
> Another thing to keep in mind is issue 498: even when stdout is a regular file
> (not a pipe), the wav muxer fails to
> flush the last <32k block of data... Of course this doesn't cause problems for
> continued piping, but I mention it just
> in case you switch to regular files ;-)
>
> -Alex
>

----------------------------------------------------------------------------------------------
The contents of this message may be privileged and confidential. Therefore, if this message
has been received in error, please delete it without reading it. All contents of the message,
including any attachments, are the copyright property of the sender. This message cannot in
any way bind Dentsu McGarry Bowen, L.L.C. to any contract or other obligation.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: When using pipe output, wav files are corrupt/only usable by libffmpeg based software.

Víctor Paesa
Hi,

Please avoid top-posting to this list.
And this list is public: it does not make sense that your signature
asks for confidentiality.


On Wed, Jul 28, 2010 at 18:09, Richard Rebel wrote:

>
> Thank you Alexandre,
>
> That is exactly what I see when I vbindiff the two files.  There are
> suspicious 00's in the beginning of the file captured from pipe output that
> are populated in the file that was written directly to disk.
>
> The program I am trying to feed data to can also accept "RAW(BE)".  I don't
> see this as a potential format or codec in ffmpeg's list of these.  There is
> one for RAW video, but I'm not sure that is the same thing.
>
> Is there a way to get ffmpeg to generate this type of stream?

 "RAW(BE)" might be "-f s16be" for ffmpeg

You may check the full list of raw audio formats with
ffmpeg -formats | grep -i pcm

> FYI I am trying to feed the audio to julian, a voice to text translator that
> has a minimal dictionary.  My only other recourse is to change it's handling
> of wav data and I'd rather not for an OSS project for what would amount to a
> kludge.
>
> Thanks,
>
> Richard
>
>
> On 7/28/10 3:25 AM, "Alexandre Ferrieux" wrote:
>
>> On 27/07/2010 21:29, Richard Rebel wrote:
>>>
>>> Hi,
>>>
>>> I have a situation where I need to pipe FLV into ffmpeg, have it convert
>>> only the audio to a mono wav format, then pipe that into another program.
>>> The final program does not use libffmpeg to read the wav data.
>>>
>>> To give you an example, if you run this command:
>>>
>>>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
>>> -f wav -s cif - | cat ->  converted-a.wav
>>>
>>> The resulting wav file can be played by VLC, but no other tools can play
>>> this nor understand it.  Especially not the program I wish to use in place
>>> of the Œcat¹ at the end of the command above.
>>>
>>> However, if I create an intermediate file like this:
>>>
>>>   cat  foo.1267568433.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1
>>> -f wav -s cif converted-b.wav
>>>
>>> The resulting wav file loads fine in VLC, and all other programs just fine.
>>> Resulting converted-a.wav and converted-b.wav are different, the latter
>>> being about 32kb larger than the one piped to cat.
>>>
>>> Does anyone have any concept as to why this might be happening when using
>>> pipe output?  I would think the resulting files should be identical, but
>>> they aren¹t.
>>
>> Some formats like WAV and 3GP are intrinsically not well suited for
>> piping/streaming, because they contain whole-file
>> size indicators or other such information. When ffmpeg writes a WAV file
>> directly, it first writes placeholders for this
>> size information, and at the end seeks back to the beginning to write the
>> actual value (see function wav_write_trailer
>> in wav.c). Of course when it writes to a pipe, the seek fails (silently), and:
>>
>>      - the size in the header is not written, typically left to zero
>>      - the few bytes of the size are written at the end instead
>>
>> I assume that this doubly invalid file can nonetheless be read by tolerant
>> implementations of the demuxer: the absence
>> of total size can be worked around by equating it with infinity (== to the end
>> of the stream), and the extra garbage
>> just looks like a few extra samples, or an invalid tag.
>>
>> Another thing to keep in mind is issue 498: even when stdout is a regular file
>> (not a pipe), the wav muxer fails to
>> flush the last <32k block of data... Of course this doesn't cause problems for
>> continued piping, but I mention it just
>> in case you switch to regular files ;-)
>>
>> -Alex

Regards,
Víctor
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user