On 1/25/2021 7:46 PM, Michael Niedermayer wrote:
On Sun, Jan 24, 2021 at 11:41:13AM -0300, James Almer wrote:
If a decoder is used for probing it may change the dimensions reported by the
demuxer, either by the lowres factor or because of assorted frames reporting
different dimensions, and in a codec copy scenario, the last dimensions
arbitrarily set by it could end up being propagated to the muxer.
Signed-off-by: James Almer <jamr...@gmail.com>
---
libavformat/utils.c | 10 ++++++----
tests/ref/fate/cbs-vp9-vp90-2-05-resize | 2 +-
tests/ref/fate/redcode-demux | 2 +-
tests/ref/fate/wtv-demux | 4 ++--
4 files changed, 10 insertions(+), 8 deletions(-)
breaks:
./ffmpeg -i tickets/2892/MPEG_tbn_test.mov -c:v copy -c:a copy -vtag mx3n
-timecode 10:00:00:00 -vframes 3 file.mov
...
[mov @ 0x558785108e00] D-10/IMX must use 720x608 or 720x512 video resolution
So the source mov is faulty and reports a wrong resolution? And trying
to pass it through instead of letting a decoder change it makes it fail
to mux because the muxer refuses to create non compliant files.
That means if there's no decoder in the build, you'd get the same result
as without this patch.
The mere existence of this code here means that letting decoders set the
resolution in a codec copy scenario is not ideal, as shown by the fact
one can tell it to make up an arbitrary resolution like it's the case of
lowres, or it can just pick up one from an arbitrary frame. Hence
prioritizing what the demuxer reads from the container feels like the
correct thing to do. But of course, broken files are a thing.
I don't know, maybe a new AVFMT_FLAG_ flag to choose between giving
priority to what the container reports or what a decoder sets, if any is
present, could work around this?
Or maybe it's the library user the one that should look at what the
demuxer read from the container and decide if a parser or decoder should
give its opinion about it.
Could not write header for output file #0 (incorrect codec parameters ?):
Invalid argument
Error initializing output stream 0:1 --
[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
