Bug #1033

webm with opus audio. Segmentation fault.

Added by Boris Bogar over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:16 Feb 2015
Priority:NormalDue date:
Assignee:Abhinav Badola% Done:

100%

Category:video
Target version:0.25

Description

I just found a webm video that cause a crash on digikam on my archlinux.
Parsing the file with the command line utility return a segmentation fault. Looks like the cause is the opus audio stream on the video. I tried to create another video with ffmpeg (command line below. Messy but working sorry) and I get the same result.

ffmpeg -i "~/imputvideo.mp4" -map 0:0 -map 0:1 -t 00:00:53.781 -threads 2 -aspect 16:9 -y -f webm -acodec libopus -ab 160k -ar 48000 -ac 2 -vcodec libvpx "~/output.webm"

vp8_opus.webm - Example video file causing the segmentation fault. (1.61 MB) Boris Bogar, 17 Feb 2015 16:52

Associated revisions

Revision 3607
Added by Robin Mills over 2 years ago

#1033. Crash when opening .webm file.

History

#1 Updated by Robin Mills over 2 years ago

  • Category set to video
  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.25

We shouldn't crash, however we do not support webm. I'll have a look at this at the week-end and add something to prevent the segmentation fault.

My good friend Gilles (M DigiKam) Caulier has proposed added WebP | WebM support to the library as a project for GSoC 2015.
https://community.kde.org/GSoC/2015/Ideas#Project:_Add_WebP_and_WebM_support

Thanks for the command-line. I'm not a video guy. I assume you're saying that I can generate a test file with that command. I'll give that a shot. If you have a test file (less than 10mb), please attach it to this issue and that'll save me some time.

#2 Updated by Boris Bogar over 2 years ago

Here a little video. Thanks for the answer. I just posted here from what I read following some hold bug report digikam->libkexiv2->exiv2

#3 Updated by Robin Mills over 2 years ago

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.

#4 Updated by Robin Mills over 2 years ago

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
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.

#5 Updated by Robin Mills over 2 years ago

  • Assignee changed from Robin Mills to Abhinav Badola

#6 Updated by Abhinav Badola over 2 years ago

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.

#7 Updated by Boris Bogar over 2 years ago

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

#8 Updated by Abhinav Badola over 2 years ago

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.

#9 Updated by Abhinav Badola over 2 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Ah... It was an environment problem in my PC.
The file is working perfectly. :)

This case seems resolved.

#10 Updated by Robin Mills over 2 years ago

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 $ 
Most of the metadata reported here is from the filesystem (date, permissions and stuff). However the image size seems OK.

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.

#11 Updated by Robin Mills over 2 years ago

  • Status changed from Resolved to Assigned

Abhinav

Your update overlapped mine. So you've got it "Resolved" and I'm wondering about why exiftool is reporting metadata. We don't support webm and webp at the moment. Gilles has proposed this for GSoC2015. He'll mentor, and I'll be alternate mentor. So this matter will be revisited.

However I'm moved it back to "assigned" so that you can answer the question "why does exiftool report metadata and exiv2 does not?"

#12 Updated by Robin Mills over 2 years ago

  • Status changed from Assigned to Resolved

I've just built the trunk on MacOS-X and, as Abhinav reported, everything seems to be fine. I'm going to mark this "resolved".

This bug will be reviewed during the release process for v0.25 and closed at that time. If anything arises on this before v0.25, it will be assigned once more. After it is closed, a new issue report will be required if more investigation is required.

570 rmills@rmillsmbp:~/Downloads $ exiv2 -pa vp8_opus.webm
Xmp.video.FileName XmpText 13 vp8_opus.webm
Xmp.video.FileSize XmpText 6 1.6074
Xmp.video.MimeType XmpText 14 video/matroska
Xmp.video.EBMLVersion XmpText 1 1
Xmp.video.EBMLReadVersion XmpText 1 1
Xmp.video.DocType XmpText 4 webm
Xmp.video.DocTypeVersion XmpText 1 4
Xmp.video.DocTypeReadVersion XmpText 1 2
Xmp.video.TimecodeScale XmpText 5 0.001
Xmp.video.MuxingApp XmpText 13 Lavf56.15.102
Xmp.video.WritingApp XmpText 13 Lavf56.15.102
Xmp.video.Duration XmpText 5 35008
Xmp.video.TotalStream XmpText 1 2
Xmp.video.FrameRate XmpText 2 24
Xmp.video.Width XmpText 3 640
Xmp.video.Height XmpText 3 360
Xmp.video.TrackLacing XmpText 2 No
Xmp.video.TrackName XmpText 18 AC3 5.1 @ 640 Kbps
Xmp.video.TrackLang XmpText 3 eng
Xmp.video.Codec XmpText 6 A_OPUS
Xmp.video.AspectRatio XmpText 4 16:9
vp8_opus.webm: (No IPTC data found in the file)
571 rmills@rmillsmbp:~/Downloads $ exiv2 -vV -g svn -g time -g compiler -g platform
exiv2 0.24 001800 (64 bit build)
platform=apple
compiler=Clang
time=20:19:05
svn=3607
library=/usr/lib/system/libcompiler_rt.dylib
library=/usr/lib/system/libsystem_platform.dylib
have_gmtime_r=1
have_timegm=1
573 rmills@rmillsmbp:~/Downloads $

#13 Updated by Boris Bogar over 2 years ago

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.

#14 Updated by Robin Mills over 2 years ago

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.

#15 Updated by Andreas Huggel over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux