-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing metadata in BmffImage stumbles over "hdlr" tag in .mp4 file #2418
Comments
@JensZuzu Please provide your test file, and I will investigate. |
I could take a l👀k at the sample file as well. |
We need to test file to make progress. Its hard to believe this bug is true. The value
A box is 8bytes with a 4byte type and a 4byte length, so I wonder why we'd cast type to length. There's a way to have an 8byte length and perhaps we've encountered that. I've found samples here: https://www.dpreview.com/forums/thread/4632208.
Those files don't have a MOOV box which is shown in the ISOBMFF-Dump output above. There are samples here (JPEG and DNG, no HEIF): https://www.photographyblog.com/reviews/sony_xperia_pro_i_review#sample_images
I unsuccessfully searched the raw image stores mentioned in my book: https://exiv2.org/book/index.html#8-6 @1div0. I'm going to close this. Can you email me when @JensZuzu provides a test image and I will reopen the issue and investigate. |
Hang on, this is a video file, no? I don't think it should end up in the bmffimage handler anyway, we should probably discard 'mp42' ftyp just like we used to do the Edit: Unfortunately, on 0.27.x we check isBmffType before isQTimeType, and we don't discard |
You're right @kmilos. It's a video file. I realised that about 10 seconds after closing the bug. I know that work is being done on video/main. It sounds as though you have dealt with this on As it involved video, I'm not getting further involved. The issue can be reopened when a test file is provided. |
Describe the bug
Reading the meta data of a .mp4 file created with a Sony mobile phone fails because of an unexpected hdlr tag that is interpreted as the size of a box.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Metadata should be parsed correctly.
Desktop (please complete the following information):
Additional context
The stack trace to the point where the exception is thrown is:
#0 __cxa_throw() at /lib64/libstdc++.so.6
#1 enforce() at /usr/src/debug/exiv2-0.27.5/src/enforce.hpp:50
#2 Exiv2::BmffImage::boxHandler() at /usr/src/debug/exiv2-0.27.5/src/bmffimage.cpp:244
#3 Exiv2::BmffImage::boxHandler() at /usr/include/c++/12/backward/auto_ptr.h:198
#4 Exiv2::BmffImage::boxHandler() at /usr/include/c++/12/backward/auto_ptr.h:198
#5 Exiv2::BmffImage::readMetadata() at /usr/src/debug/exiv2-0.27.5/src/bmffimage.cpp:673
#6 ... application code
At frame #2 the contents of the hdrbuf, which is of type Exiv2::byte[8] is: "hdlr\000\000\000"
The first four bytes of it are reinterpret_cast-ed to the box_length == 1751411826
Dumping the file with ISOBMFF-Dump results in:
The text was updated successfully, but these errors were encountered: