Exiv2

Thanks for posting the file. Yup, I have reproduced your segmentation fault. I'll have a crawl through this with the debugger at the weekend.

Fix submitted: r3607.

I'm assigning this to Abhinav, who wrote this code, to review my fix.

Abhinav, can you also consider if this fault could occur in other locations in the video code. If you run this command:

546 rmills@rmillsmbp:~/gnu/exiv2/trunk $ grep find src/*video.cpp

Thank you Robin for submitting the fix.

I will review it, this coming weekend.

As such, Exiv2 should support webm type of files.
This is because the metadata container of WebM is same as that of Matroska class.

Since we do support Matroska via Exiv2, it should also, by default, support WebM.

I didn't have substantial samples of WebM to test upon, so this issue might not have been discovered earlier.

Thanks a lot, Boris, for reporting this issue. :)

Robin Mills wrote:

Fix submitted: r3607.

I'm assigning this to Abhinav, who wrote this code, to review my fix.

Abhinav, can you also consider if this fault could occur in other locations in the video code. If you run this command:[...]you'll see that function find is called in 63 locations. It'd be good to know that the other 62 locations are safe when NULL is returned. If you're happy, please mark this issue as "resolved". If you don't have time to investigate this, please reassign this issue back to me.

I tried to compile the trunk and is working like a charm. Thanks you all for the work and for the quick fix.

Hi Robin and Boris,

I feel happy that the problem is solved for Boris.
It is not crashing, and that is great. :)

But I am surprised as to why exiv2 is not able to extract any video related metadata from the file.
I tried to look into the metadata of the file while debugging this problem and spent some time on it.

As of now, I have not been able to solve the problem properly.
So I am not putting this problem as resolved.

I will work on it soon, some time later.
If I feel that there is some specific case of code deficiency, which may need some proper implementation, then I will put the bug as resolved or as a feature request for future.
But I hope that by adding a small patch, it might get solved easily.
I will get back on this thread once I have more information on it.

Boris Bogar wrote:

I tried to compile the trunk and is working like a charm. Thanks you all for the work and for the quick fix.

Thanks for looking at this, Abhinav. You're right. There is metadata hiding in the file. At least we don't crash and that's better, however not the solution. I ran the file in exiftool:

549 rmills@rmillsmbp:~/Downloads $ exiftool vp8_opus.webm 
ExifTool Version Number         : 9.35
File Name                       : vp8_opus.webm
Directory                       : .
File Size                       : 1646 kB
File Modification Date/Time     : 2015:02:17 18:47:36+00:00
File Access Date/Time           : 2015:02:18 19:28:54+00:00
File Inode Change Date/Time     : 2015:02:17 18:47:36+00:00
File Permissions                : rw-r--r--
File Type                       : WEBM
MIME Type                       : video/webm
EBML Version                    : 1
EBML Read Version               : 1
Doc Type                        : webm
Doc Type Version                : 4
Doc Type Read Version           : 2
Timecode Scale                  : 1 ms
Muxing App                      : Lavf56.15.102
Writing App                     : Lavf56.15.102
Duration                        : 0:00:35
Codec ID                        : V_VP8
Video Frame Rate                : 24
Image Width                     : 640
Image Height                    : 360
Display Width                   : 640
Display Height                  : 360
Track Number                    : 2
Track Name                      : AC3 5.1 @ 640 Kbps
Track Language                  : eng
Video Codec ID                  : A_OPUS
Track Type                      : Audio
Audio Channels                  : 2
Audio Sample Rate               : 48000
Audio Bits Per Sample           : 32
Image Size                      : 640x360
550 rmills@rmillsmbp:~/Downloads $ 

In the original report, Boris suspected the audio data was involved in the conspiracy!

On a totally different note. I believe there was something wrong with the Digicam -> Exiv2 wrapper that allowed Exiv2 to throw and exception and crash Digicam. I believe Gilles fixed that some time ago. Boris, if your copy of Digicam is more than a year old, you might want to consider updating to a more recent edition that won't crash when Exiv2 throws an exception.

I dig around the various report about the trouble between digikam and exiv2. I ended up being a bit 'confused in understanding if the version of digikam I used solve the problem mentioned in bug reports. But i'm running arch so the package should be up to date (4.7.0-1). Before I also tried to recompile the svn(git?) version of the package libkexiv2 but the problem persist so I come here.

Robin Mills wrote:

On a totally different note. I believe there was something wrong with the Digicam -> Exiv2 wrapper that allowed Exiv2 to throw and exception and crash Digicam. I believe Gilles fixed that some time ago. Boris, if your copy of Digicam is more than a year old, you might want to consider updating to a more recent edition that won't crash when Exiv2 throws an exception.

My understanding of the Digikam <-> Exiv2 crash was something wrong with the exception handler in libkexiv2. If Exiv2 threw an exception, it wasn't caught by libkexiv2 and ended up in DigiKam. Digikam assumed that libkexiv2 would never throw.

If you've rebuild libkexiv2 and Exiv2 and you are still in trouble, I think you'll have to wait for a new release of DigiKam with everything fixed. I don't participate in the DigiKam project - so I can't say when this will be resolved.

I've never liked exception handling. It may be current practice, however it's a source of leaks and asynchronous flow. It's a kind of goto and you neither know where you are going, nor how you got there. I dislike the early return almost as much. One day the world will understand that a zero/non-zero return code at the end of every function is a better model. Every function should have one way in and one way out. Nobody agrees with me.