Opened 7 years ago
Closed 7 years ago
#6761 closed defect (fixed)
Allow huge filenames (datauri) in the concat demuxer
Reported by: | Eli Snow | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | concat |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
Summary of the bug:
I am trying to turn a stream of jpeg's into a video but the concat demuxer is erroring with the data uris. An output video is produced but it only has the top part of the images included with the rest of each frame being green.
(I'm actually programatically generating the concat script and feeding it into ffmpeg's stdin, but for the sake of this repro case attached is a static concat script)
How to reproduce:
ffmpeg -report -f concat -safe 0 -protocol_whitelist file,data -i concat -vf fps=30 -y out.mp4
The main error looks something like:
[mjpeg @ 00000215a6bbd9a0] overread 8
Attached is the output of the -report
option.
As is obvious from the report log I am running on Windows (version 10).
Attachments (5)
Change History (14)
by , 7 years ago
Attachment: | ffmpeg-20171019-125351.log added |
---|
comment:1 by , 7 years ago
Version: | unspecified → git-master |
---|
follow-up: 4 comment:3 by , 7 years ago
ffmpeg outputs the overread 8
error and outputs a mostly green video. If you save the data uri jpegs to files and modify the concat script to use those jpeg files, it works properly. It is only with data uris that ffmpeg is misbehaving.
follow-up: 5 comment:4 by , 7 years ago
Replying to elisnow:
ffmpeg outputs the
overread 8
error and outputs a mostly green video.
Yes.
If you save the data uri jpegs to files and modify the concat script to use those jpeg files, it works properly.
How can I reproduce this?
When I tried to, I saw the same green images and given the many repeated characters in the base64 encoding that you provided, this did not surprise me.
It is only with data uris that ffmpeg is misbehaving.
While this is absolutely possible (and would indicate a bug) I was unable to reproduce this.
by , 7 years ago
by , 7 years ago
comment:5 by , 7 years ago
Replying to cehoyos:
How can I reproduce this?
When I tried to, I saw the same green images and given the many repeated characters in the base64 encoding that you provided, this did not surprise me.
I'm confused. I have attached both images as jpeg files. These are the same images as the base64 data uris in the concat script. There is no green in either image. The first image is all white. The second image is mostly white with the header of a webpage shown.
(These images are browser paints, and the resulting video should show a web page being loaded)
I have also attached a modified concat script which references the jpeg files and properly produces a video.
comment:6 by , 7 years ago
How did you create the jpg files that you attached / how did you create the base64 encoded strings in your original command line?
comment:7 by , 7 years ago
For the attached jpg files I simply pasted the data uris into Firefox's address bar then saved the image to disk. Ordinarily what I do (to workaround this bug) is programatically save the base64 image to file and reference the saved file in the concat script which I feed into ffmpeg's stdin. If I can inject the base64 image directly into the concat script, then I don't have to take the step of first saving all the images to disk and then deleting them all later.
The source of the base64 images come from the Chrome DevTools Protocol screen casting functionality.
comment:8 by , 7 years ago
Component: | undetermined → avformat |
---|---|
Keywords: | concat added |
Reproduced by developer: | set |
Status: | new → open |
Summary: | concat demuxer with data uri jpegs causes "overread 8" → Allow huge filenames (datauri) in the concat demuxer |
There is definitely a bug because no error is shown if the filename in the concat demuxer is bigger than the allowed maximum (currently 4096), I don't know if the maintainer will accept your use-case, patch sent.
comment:9 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Fixed in ffabff1baa0873a2aa9c0c09ec93b2f4191493b5.
report output