The latest branch of Avidemux is 2.6.x. I tried it (8121 build) on ubuntu and it was stable enough (for simple video cutting). But in gentoo there is only media-video/avidemux-2.5.6 ebuild in portage. Could anyone create the ebuild for new 2.6 :) [url=http://www.avidemux.org/admWiki/doku.php?id=build:install_2.6]Here[/url] is notes about how to built, but I couldn't make it :( Latest source: svn://svn.berlios.de/avidemux/branches/avidemux_2.6_branch_mean Thanks.
The latest official release is still 2.5.6, so you're basically asking to package a snapshot from the 2.6.x branch. That branch is considered experimental according to http://www.avidemux.org/admWiki/doku.php?id=versions:main, and knowing how much troublesome avidemux has been in the past, personally I have no intention to package a 2.6 snapshot, sorry. Other devs may be interested though, so I'm leaving this bug open for a while.
>>> That branch is considered experimental according to http://www.avidemux.org/admWiki/doku.php?id=versions:main, and knowing how much troublesome avidemux has been in the past, Yes, it was, but now is it stable enough for ~ KEYWORD (maybe not the latest snapshot). Also, it's the only open_source application at this moment, that can correctly work with MPEG-TS video (like IPTV streams and similar). Well, sorry, this is not interesting. If so, I will probably have to use another distribution of Linux.
(In reply to comment #2) > >>> That branch is considered experimental according to http://www.avidemux.org/admWiki/doku.php?id=versions:main, and knowing how much troublesome avidemux has been in the past, > > Yes, it was, but now is it stable enough for ~ KEYWORD (maybe not the latest > snapshot). Which one then? Can you point us to a known-good state of the 2.6 branch that is suitable for packaging? Even better, why don't you ask upstream to make a (alpha or beta) release? That would definitely be easier for us to package. > Also, it's the only open_source application at this moment, that can > correctly work with MPEG-TS video (like IPTV streams and similar). Well, > sorry, this is not interesting. If so, I will probably have to use another > distribution of Linux. You're free to use whichever distro you want, but AFAICS no distro has a packaged 2.6 snapshot in its repos yet... The fact that *I* am not interested doesn't mean that *nobody* is interested. In fact, I already said I'm leaving this bug open for other potentially interested devs.
Why do you want to code that is not considered stable for a release? Is 2.5.6 broken for you?
(In reply to comment #4) > Why do you want to code that is not considered stable for a release? Is > 2.5.6 broken for you? Ok, I will explain. Avidemux-2.5.x uses "frame based" audio-video accuracy, and Avidemux-2.6.x uses "time based" one instead. Well, it is more useful for transport streams (and nowadays video codecs like x264, which can use 'Variable Frame Rate'). So, when I use 2.5.x for simple cutting, I always get out of a-v sync. Even in FAQ of Avidemux-2.5.x it is mentioned: http://forum.doom9.org/showthread.php?t=126164 I quote: [quote] >>> Why do my MPEG-2 files get out of sync when I cut/edit them in Avidemux? Captured MPEG files are generally from DVB S/T (in MPEG TS format) or from IVTV based cards or any other card with hardware MPEG-2 encoding (in MPEG PS format). These captures often contain transmission errors which end up as missing or broken frames! A video player (MPC, MPlayer, xine, VLC, etc.) will constantly re-sync the streams using the timing information embedded in the stream. Avidemux will not! Apart from the constant shift, which is easily recoverable using the timeshift filter, it will result in a growing synchronisation issue when encoding or transcoding. Even saving without re-encoding will be async! MythTV recordings are a prime example of this problem: The audio will be offset by approximately -330 ms at the start of the recording and the drift throughout the duration of the recording. ... [/quote] This problem doesn't exists in 2.6.x branch. That's it. ps If you are unsure about ~ keyword, it may be 'hard masked' in the near term.
>>> Which one then? Can you point us to a known-good state of the 2.6 branch that is suitable for packaging? I used the "2.6.0_r8121" > AFAICS no distro has a packaged 2.6 snapshot in its repos yet... There is deb packages (of corse experimental). I tried to use it in Ubuntu on my another computer. And there is available for Fedora ones. Here, for example: http://www.avidemux.org/nightly/fedora14_32/
> Can you point us to a known-good state of the 2.6 branch that is suitable for packaging? Try this one http://www.avidemux.org/nightly/source/
(In reply to comment #6) > > AFAICS no distro has a packaged 2.6 snapshot in its repos yet... > > There is deb packages (of corse experimental). I tried to use it in Ubuntu > on my another computer. And there is available for Fedora ones. > Here, for example: http://www.avidemux.org/nightly/fedora14_32/ Those packages are *NOT* official packages from the distro repository! Please compare apples to apples.
(In reply to comment #7) > > Can you point us to a known-good state of the 2.6 branch that is suitable for packaging? > > Try this one http://www.avidemux.org/nightly/source/ These are daily snapshots. We aint gonna package that. Maybe we could add a live ebuild instead...
(In reply to comment #8) > Those packages are *NOT* official packages from the distro repository! > Please compare apples to apples. That's right. I was doing that on my own risk. (In reply to comment #9) > These are daily snapshots. We aint gonna package that. Maybe we could add a > live ebuild instead... That would be awesome :)
Thanks to 4nykey. The ebuild is here: http://code.google.com/p/4nykey/source/browse/portage/media-video/avidemux/?r=1054 Have not tried yet, but will soon.
Just note that that is a very outdated ebuild (unslotted gtk+ and qt deps, for example).
(In reply to comment #12) > Just note that that is a very outdated ebuild (unslotted gtk+ and qt deps, > for example). Yeah doesn't look ok (QA wise) but maybe we can just copy it and rework it in our overlay?
No reason to package 2.6_pre snapshots anymore as 2.6.0 was released today
Created attachment 323076 [details] ebuild for Avidemux_2.6 from git
4nikey has updated ebuild for avidemux_2.6 (attached). New ebuild uses git instead of svn. I have already tried it. Works without problems (simple cutting and muxing). (In reply to comment #14) > No reason to package 2.6_pre snapshots anymore as 2.6.0 was released today Is there _src package_ ? Or we still have to compile avidemux_2.6 from Git?
(In reply to comment #16) > 4nikey has updated ebuild for avidemux_2.6 (attached). New ebuild uses git > instead of svn. > I have already tried it. Works without problems (simple cutting and muxing). > > > (In reply to comment #14) > > No reason to package 2.6_pre snapshots anymore as 2.6.0 was released today > > Is there _src package_ ? Or we still have to compile avidemux_2.6 from Git? Like I said, there is a 2.6.0 release http://sourceforge.net/projects/avidemux/files/avidemux/2.6.0/avidemux_2.6.0.tar.gz/download
Oh, Cool! Can you rework the ebuild I am just uploaded to this release?
Quoting upstream: "You can keep 2.5 and 2.6 installed at the same time, and it is probably a good idea." So I guess we should put the new release into a different SLOT, if it's not too much work...
(In reply to comment #19) > Quoting upstream: > "You can keep 2.5 and 2.6 installed at the same time, and it is probably a > good idea." > > So I guess we should put the new release into a different SLOT, if it's not > too much work... I think so, especially if you use 'git ebuild' as sample. There is already 'SLOT="3"' variable in that ebuild.
(In reply to comment #18) > Oh, Cool! > Can you rework the ebuild I am just uploaded to this release? Obviously, I will bump this ebuild at some point
(In reply to comment #21) > (In reply to comment #18) > > Oh, Cool! > > Can you rework the ebuild I am just uploaded to this release? > > Obviously, I will bump this ebuild at some point I know this is taking longer than usual but this is because nobody from the Qt team is actually using this software so we could really benefit from a proxy-maintainer here (user or dev). If anyone is interested please let us know
I've added an ebuild for 2.6.0 to the qt overlay, based on the in-tree ebuild for 2.5.6. I have updated the SRC_URI and checked the locales, and made a start on implementing l10n support. Basically everything else needs to be checked and adjusted accordingly. Note upstream documentation: http://www.avidemux.org/admWiki/doku.php?id=build:install_2.6 and this one, which is outdated in places: http://www.avidemux.org/admWiki/doku.php?id=build:compiling_avidemux
(In reply to comment #23) > I've added an ebuild for 2.6.0 to the qt overlay, based on the in-tree > ebuild for 2.5.6. I have updated the SRC_URI and checked the locales, and > made a start on implementing l10n support. Basically everything else needs > to be checked and adjusted accordingly. > > Note upstream documentation: > http://www.avidemux.org/admWiki/doku.php?id=build:install_2.6 > and this one, which is outdated in places: > http://www.avidemux.org/admWiki/doku.php?id=build:compiling_avidemux Something is wrong with your ebuild: * avidemux_2.6.0.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking avidemux_2.6.0.tar.gz to /mnt/media3/portage-tmp/portage/media-video/avidemux-2.6.0/work >>> Source unpacked in /mnt/media3/portage-tmp/portage/media-video/avidemux-2.6.0/work >>> Preparing source in /mnt/media3/portage-tmp/portage/media-video/avidemux-2.6.0/work/avidemux_2.6.0 ... sed: can't read avidemux2-gtk.desktop: No such file or directory
(In reply to comment #24) > Something is wrong with your ebuild: As I said: > > Basically everything else needs to be checked and adjusted accordingly. This is also why it is hard-masked. The locales and (most of) the dependencies should be correct. But everything else (the ebuild phases) need review. But at least there is an ebuild that can be used as a starting point.
(In reply to comment #25) > (In reply to comment #24) > > Something is wrong with your ebuild: > > As I said: > > > > Basically everything else needs to be checked and adjusted accordingly. > > This is also why it is hard-masked. The locales and (most of) the > dependencies should be correct. But everything else (the ebuild phases) need > review. But at least there is an ebuild that can be used as a starting point. There's already ebuild 'for git'. To build 2.6.0 ebuild will be simpler using it than 2.5.x I think.
I had a brief look. The build system is absolutely horrible. Like really really horrible. This will take a while before one of us actually manages to fix it. I will write an email on -dev that we actually looking for a dedicated maintainer.
I pushed an improved ebuild. it compiles and installs for me. Please try it and report any problems here.
Created attachment 325984 [details, diff] fix build with gtk interface Thanks for the ebuild.
(In reply to comment #29) > Created attachment 325984 [details, diff] [details, diff] > fix build with gtk interface > > Thanks for the ebuild. Thanks. The patch looks good. I will merge it tonight
Moved to gx86 for broader testing. Thank you all
