Opened 6 months ago
Closed 2 months ago
#6761 closed defect (fixed)
Allow huge filenames (datauri) in the concat demuxer
Reported by: | elisnow | 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)
Changed 6 months ago by elisnow
comment:1 Changed 6 months ago by elisnow
- Version changed from unspecified to git-master
comment:2 Changed 6 months ago by cehoyos
Why do you believe there is an issue?
comment:3 follow-up: ↓ 4 Changed 6 months ago by elisnow
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.
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 6 months ago by cehoyos
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.
Changed 6 months ago by elisnow
Changed 6 months ago by elisnow
comment:5 in reply to: ↑ 4 Changed 6 months ago by elisnow
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 web page 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 Changed 6 months ago by cehoyos
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 Changed 6 months ago by elisnow
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 Changed 6 months ago by cehoyos
- Component changed from undetermined to avformat
- Keywords concat added
- Reproduced by developer set
- Status changed from new to open
- Summary changed from concat demuxer with data uri jpegs causes "overread 8" to 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 Changed 2 months ago by cus
- Resolution set to fixed
- Status changed from open to closed
Fixed in ffabff1baa0873a2aa9c0c09ec93b2f4191493b5.
report output