OGG container broken on 64-bit systems
Ryan Saunders <[email protected]> Fri, 24 Sep 2010 15:22:35 -0700 (PDT)
| Newsgroups | gmane.comp.video.dvdrip.user |
|---|---|
| Message-ID | <[email protected]> |
--0-1907144062-1285366955=:72634
Content-Type: text/plain; charset=us-ascii
Howdy,
I just started messing around with dvd::rip this week, and wanted to do some
file-size comparisons of different combinations of audio/video codecs and
params, and various container formats. My first attempt at encoding a movie into
an OGG container didn't go so well...it gets through both video encoding passes,
and then dies when it tries to stitch in the audio track at the end. The problem
is that the ogmmerge binary dies with a SIGABRT on my 64-bit AMD Mandriva Linux
system.
Being a software geek, I said to myself, "heck, it's open-source, right?" and
downloaded the source code for ogmtools and libvorbis, and started debugging. 4
or 5 hours later, I had a patch fixing the problem, and sent it off to the guy
who wrote ogmtools. I got this back:
Hey,
sorry, but the ogmtools are not developed anymore. There will be no new
releases.
Regards,
Mosu
That seems unfortunate...these tools probably need only minor portability (and
perhaps security) fixes, but there's no longer anyone "upstream" maintaining
them, which means there's no easy way to get such fixes out to all the distros
that ship ogmtools. Perhaps, since dvd::rip depends on ogmtools, somebody on
this list would be motivated to take over maintenance of ogmtools from Mosu? If
this doesn't get fixed, then dvd::rip's OGG export is completely broken on
64-bit systems. I've included the patch fixing the 64-bit portability issues at
the end of this message, so all that would be needed is to apply the patch and
issue a new release of ogmtools.
Also, on an unrelated note, I noticed that, when exporting to an OGG container,
there appears to be a bug with the intermediate .ogm files that are generated by
transcode...they have the .ogm extension, but the "file" utility and ogmmerge
both say that they're AVI files. That seems like a bug...if I didn't do a
two-pass encode, and just did a single pass to create the video, would I end up
with an AVI file masquerading as OGM? I don't know whether it's a bug in
dvd::rip or one in transcode, but it seems like something somebody might want to
look into.
Regards,
Ryan
-- Patch text begins here -----------------------------------------------------
diff ogmtools-1.5//generic.cpp ogmtools-1.5_//generic.cpp
39,46c39
< if (ncomments == NULL) {
< comments = NULL;
< return;
< }
< comments = (vorbis_comment *)malloc(sizeof(vorbis_comment));
< if (comments == NULL)
< die("malloc");
< memcpy(comments, ncomments, sizeof(vorbis_comment));
---
> comments = vorbis_comment_dup(ncomments);
140,147c133
< vc = (vorbis_comment *)malloc(sizeof(vorbis_comment));
< if (vc == NULL)
< die("malloc");
<
< vc->vendor = strdup(VERSIONINFO);
< vc->user_comments = (char **)mmalloc(4);
< vc->comment_lengths = (int *)mmalloc(4);
< vc->comments = 0;
---
> vc = generate_vorbis_comment(NULL);
181,188c167
< nvc = (vorbis_comment *)malloc(sizeof(vorbis_comment));
< if (nvc == NULL)
< die("malloc");
<
< nvc->vendor = strdup(VERSIONINFO);
< nvc->user_comments = (char **)mmalloc(4);
< nvc->comment_lengths = (int *)mmalloc(4);
< nvc->comments = 0;
---
> nvc = generate_vorbis_comment(NULL);
diff ogmtools-1.5//vorbis_header_utils.c ogmtools-1.5_//vorbis_header_utils.c
164c164
< (vc->comments + 1) * sizeof(char *));
---
> (vc->comments + 1) * sizeof(int));
--0-1907144062-1285366955=:72634
Content-Type: text/html; charset=us-ascii
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Howdy,<br><br>I just started messing around with dvd::rip this week, and wanted to do some file-size comparisons of different combinations of audio/video codecs and params, and various container formats. My first attempt at encoding a movie into an OGG container didn't go so well...it gets through both video encoding passes, and then dies when it tries to stitch in the audio track at the end. The problem is that the ogmmerge binary dies with a SIGABRT on my 64-bit AMD Mandriva Linux system.<br><br>Being a software geek, I said to myself, "heck, it's open-source, right?" and downloaded the source code for ogmtools and libvorbis,
and started debugging. 4 or 5 hours later, I had a patch fixing the problem, and sent it off to the guy who wrote ogmtools. I got this back:<br><br>
Hey,<br><br> sorry, but the ogmtools are not developed anymore. There will be no new releases.<br><br> Regards,<br> Mosu<br><br>That seems unfortunate...these tools probably need only minor portability (and perhaps security) fixes, but there's no longer anyone "upstream" maintaining them, which means there's no easy way to get such fixes out to all the distros that ship ogmtools. Perhaps, since dvd::rip depends on ogmtools, somebody on this list would be motivated to take over maintenance of ogmtools from Mosu? If this doesn't get fixed, then dvd::rip's OGG export is completely broken on 64-bit systems. I've included the patch fixing the 64-bit portability issues at the end of this message, so all that would be needed is to apply the p
atch and issue a new release of ogmtools.<br><br>Also, on an unrelated note, I noticed that, when exporting to an OGG container, there appears to be a bug with the
intermediate .ogm files that are generated by transcode...they have the .ogm extension, but the "file" utility and ogmmerge both say that they're AVI files. That seems like a bug...if I didn't do a two-pass encode, and just did a single pass to create the video, would I end up with an AVI file masquerading as OGM? I don't know whether it's a bug in dvd::rip or one in transcode, but it seems like something somebody might want to look into.<br><a rel="nofollow" target="_blank" href="mailto:[email protected]"></a><br>Regards,<br>Ryan<br><br>-- Patch text begins here -----------------------------------------------------<br><br>diff ogmtools-1.5//generic.cpp ogmtools-1.5_//generic.cpp<br>39,46c39<br>< if (ncomments == NULL) {<br>< comments = NULL;<br>&
lt; return;<br>< }<br>< comments = (vorbis_comment *)malloc(sizeof(vorbis_comment));<br>< if
(comments == NULL)<br>< die("malloc");<br>< memcpy(comments, ncomments, sizeof(vorbis_comment));<br>---<br>> comments = vorbis_comment_dup(ncomments);<br>140,147c133<br>< vc = (vorbis_comment
*)malloc(sizeof(vorbis_comment));<br>< if (vc == NULL)<br>< die("malloc");<br>< <br>< vc->vendor = strdup(VERSIONINFO);<br>< vc->user_comments = (char **)mmalloc(4);<br>< vc->comment_lengths = (int *)mmalloc(4);<br>< vc->comments = 0;<br>---<br>> vc = generate_vorbis_comment(NULL);<br>181,188c167<br>< nvc = (vorbis_comment *)malloc(sizeof(vorbis_comment));<br>< if (nvc == NULL)<br>< die("malloc");<br>< <br>< nvc->vendor = strdup(VERSIONINFO);<br>< nvc->user_comments = (char **)mmalloc(4);<br>< nvc->comment_lengths = (int *)mmalloc(4);<br>< 
; nvc->comments = 0;<br>---<br>> nvc = generate_vorbis_comment(NULL);<br>diff ogmtools-1.5//vorbis_header_utils.c
ogmtools-1.5_//vorbis_header_utils.c<br>164c164<br>< (vc->comments + 1) * sizeof(char *));<br>---<br>> (vc->comments + 1) * sizeof(int));<br>
<br></div>
</div><br></body></html>
--0-1907144062-1285366955=:72634--