[FFmpeg-user] "ffplay -report" creates text files with mixed line endings
barsnick at gmx.net
Tue Nov 9 15:21:35 EET 2021
On Tue, Nov 09, 2021 at 11:51:18 +0000, Jaime wrote:
> AV_LOG_FORCE_NOCOLOR=1 ffplay -report -rtsp_transport tcp rtsp://camera.lan
> Mailman is showing the report file as being of type: "application/octet-stream":
Is this the actual file you created, or the one you fetched from
> A non-text attachment was scrubbed...
> Name: ffplay-20211109-100211.log
> Type: application/octet-stream
> Size: 32011 bytes
> I've just checked the line endings using "dos2unix -ih":
> $ dos2unix -ih ffplay-20211109-100211.log
> DOS UNIX MAC BOM TXTBIN FILE
> 17 163 301 no_bom text ffplay-20211109-100211.log
> Interesting. Is this "by design", or a bug (or neither)?
If you mean ffmpeg:
I'm pretty sure that part of this is by design. You should check the
actual line endings. ffmpeg uses a pure "CR" (carriage return, often
displayed as '^M') to cyclically overwrite the status line, and also
seems to dump this into the report file. Those would be the "MAC"
endings, I guess, and your mail agent seems to identify the file as
binary, and therefore send it as "application/octet-stream".
I cannot explain the DOS and UNIX discrepancy though. I get pure Unix:
$ dos2unix -ih ffplay-20211109-135854.log
DOS UNIX MAC BOM TXTBIN FILE
0 83 327 no_bom text ffplay-20211109-135854.log
On the other hand, if this was not your local file, it could be
mailman's fault, or by one of the mail servers.
We would need to see your actual file to understand this. Note, I have
mailed myself such a report file, and had the local mail agent(s)
changing it! I noticed the line endings changed when receiving through
Exchange/Outlook, but I don't know who the culprit was.
Again, the "MAC" line endings will probably make the attachment binary
nevertheless(?). You should check whether you can force the MIME type
when sending, if the problem is on your sending side, and not when
receiving though mailman.
More information about the ffmpeg-user