[PATCH] dshow: allow for more codecs take 2
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok. Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard. -roger-
On Fri, Jan 25, 2013 at 6:53 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
ok, we'll find out sooner or later if there is any problem
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
ok btw your latest patches affect code that was copied from vfwcap.c. maybe you'd like to factor the code =)
On 1/29/13, Ramiro Polla <ramiro.polla@gmail.com> wrote:
On Fri, Jan 25, 2013 at 6:53 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
ok, we'll find out sooner or later if there is any problem
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
ok
btw your latest patches affect code that was copied from vfwcap.c. maybe you'd like to factor the code =)
Yeah I had thought of it once, but since there's so little interest in vfwcap, my thought had been to "update it in a later commit..." (i.e. only worry if there's ever any interest in it). vfwcap hasn't seen a lot of updates that dshow has... -roger-
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :) -roger-
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you. -roger-
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged
thanks
Thanks! I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better.. -roger-
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote:
Ok after the previous discussion http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html it appears the first patch attached (0001 -- re-attached here and modified to apply cleaning to git master) is ok.
Also attached is a second patch for better error logging messages. Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged
thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits): I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge Thanks * commit c94dbc9ebd4221f7fccd235715ad07621ffc3ea8 |\ Merge: f0eacbc 54d2017 | | Author: Michael Niedermayer <michaelni@gmx.at> | | Date: Tue Feb 5 23:32:38 2013 +0100 | | | | Merge remote-tracking branch 'rdp/combined' | | | | * rdp/combined: | | dshow: remove hopefully unneeded color_range HDYC addition, see http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=10&t=869&p=3724 | | dshow: fix log message | | dshow: better error reporting | | dshow: allow for more codec ID's | | | * commit 54d2017e48eb9f460c899e7fce39c4643e47181e | |\ Merge: 4ab24a6 b0635e2 | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | Date: Tue Jan 15 23:51:46 2013 -0700 | | | | | | Merge remote-tracking branch 'origin/master' into combined | | | | * | commit 4ab24a6712d77141552a46d1fedd8c0ca9daeb82 | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | Date: Tue Jan 15 23:20:43 2013 -0700 | | | | | | dshow: remove hopefully unneeded color_range HDYC addition, see http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=10&t=869&p=3724 | | | | | | Signed-off-by: rogerdpack <rogerpack2005@gmail.com> | | | | * | commit b5eb6d2b1f7ff7be155c9ae11f35dba30d551f3d | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | Date: Tue Jan 15 23:09:54 2013 -0700 | | | | | | dshow: fix log message | | | | | | Signed-off-by: rogerdpack <rogerpack2005@gmail.com> | | | | * | commit f003f4202470f8a14583f9e46cf56b702251dc0d | |\ \ Merge: 114f6b1 f7b7f02 | | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | | Date: Tue Jan 15 23:08:26 2013 -0700 | | | | | | | | Merge remote-tracking branch 'origin/master' into combined | | | | | * | | commit 114f6b1b4fab58306996b3faf11101787c67df95 | |\ \ \ Merge: c540312 55ada3a | | | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | | | Date: Tue Jan 15 23:08:09 2013 -0700 | | | | | | | | | | Merge branch 'better_pix_fmt' into combined | | | | | | | * | | commit 55ada3a9f34fdd05e642c4009aee7ca55293049b | | |\ \ \ Merge: 47e8848 8c3de1a | | | | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | | | | Date: Tue Jan 15 18:57:38 2013 -0700 | | | | | | | | | | | | Merge branch 'better_codec_id_take2' into better_pix_fmt | | | | | | | | | * | | commit 8c3de1abeea9d1f2dedf0e823a9f75840edb3295 | | | | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | | | | Date: Tue Jan 15 15:08:23 2013 -0700 | | | | | | | | | | | | dshow: better error reporting | | | | | | | | | | | | Signed-off-by: rogerdpack <rogerpack2005@gmail.com> | | | | | | | | | * | | commit 8168cbc969e39bf094ed7c5e56be985c4a68d351 | | | | | | Author: rogerdpack <rogerpack2005@gmail.com> | | | | | | Date: Tue Jan 15 15:01:43 2013 -0700 | | | | | | | | | | | | dshow: allow for more codec ID's | | | | | | | | | | | | Signed-off-by: rogerdpack <rogerpack2005@gmail.com> | | | | | | [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer.
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote:
On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > Ok after the previous discussion > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > it appears the first patch attached (0001 -- re-attached here and > modified to apply cleaning to git master) is ok. > > Also attached is a second patch for better error logging > messages. > Thank you for your consideration in their regard.
bump for these 2. Or maybe you could give Ramiro commit rights I'm sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged
thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate. Thanks! -roger-
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: > On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > > Ok after the previous discussion > > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > > it appears the first patch attached (0001 -- re-attached here and > > modified to apply cleaning to git master) is ok. > > > > Also attached is a second patch for better error logging > > messages. > > Thank you for your consideration in their regard. > > bump for these 2. Or maybe you could give Ramiro commit rights I'm > sure he wouldn't abuse :)
ramiro has commit rights, he also has a github repo
you are dshow maintainer, thus if you want me to merge some git repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged
thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote:
On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: >> > Ok after the previous discussion >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html >> > it appears the first patch attached (0001 -- re-attached here and >> > modified to apply cleaning to git master) is ok. >> > >> > Also attached is a second patch for better error logging >> > messages. >> > Thank you for your consideration in their regard. >> >> bump for these 2. Or maybe you could give Ramiro commit rights I'm >> sure he wouldn't abuse :) > > ramiro has commit rights, he also has a github repo > > you are dshow maintainer, thus if you want me to merge some git > repo/branch just say which ...
Ok please merge the https://github.com/rdp/ffmpeg "combined" branch (Ramiro or Michael maybe whoever gets to it first). Thank you.
merged
thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: > On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: > >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > >> > Ok after the previous discussion > >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > >> > it appears the first patch attached (0001 -- re-attached here > >> > and > >> > modified to apply cleaning to git master) is ok. > >> > > >> > Also attached is a second patch for better error logging > >> > messages. > >> > Thank you for your consideration in their regard. > >> > >> bump for these 2. Or maybe you could give Ramiro commit rights > >> I'm > >> sure he wouldn't abuse :) > > > > ramiro has commit rights, he also has a github repo > > > > you are dshow maintainer, thus if you want me to merge some git > > repo/branch just say which ... > > Ok please merge the https://github.com/rdp/ffmpeg "combined" > branch > (Ramiro or Michael maybe whoever gets to it first). > Thank you.
merged
thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience. -roger-
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: >> >> > Ok after the previous discussion >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html >> >> > it appears the first patch attached (0001 -- re-attached here >> >> > and >> >> > modified to apply cleaning to git master) is ok. >> >> > >> >> > Also attached is a second patch for better error logging >> >> > messages. >> >> > Thank you for your consideration in their regard. >> >> >> >> bump for these 2. Or maybe you could give Ramiro commit rights >> >> I'm >> >> sure he wouldn't abuse :) >> > >> > ramiro has commit rights, he also has a github repo >> > >> > you are dshow maintainer, thus if you want me to merge some git >> > repo/branch just say which ... >> >> Ok please merge the https://github.com/rdp/ffmpeg "combined" >> branch >> (Ramiro or Michael maybe whoever gets to it first). >> Thank you. > > merged > > thanks
Thanks!
I am something of a novice to this, and appears I made a small mistake and the "combined" branch was lacking a commit or 2, could you pull and merge it again for me? Sorry for the inconvenience. Hopefully I'll get some experience with this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
On Sat, Feb 09, 2013 at 04:11:09AM +0100, Michael Niedermayer wrote:
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote: > On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: > >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: > >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: > >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > >> >> > Ok after the previous discussion > >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > >> >> > it appears the first patch attached (0001 -- re-attached here > >> >> > and > >> >> > modified to apply cleaning to git master) is ok. > >> >> > > >> >> > Also attached is a second patch for better error logging > >> >> > messages. > >> >> > Thank you for your consideration in their regard. > >> >> > >> >> bump for these 2. Or maybe you could give Ramiro commit rights > >> >> I'm > >> >> sure he wouldn't abuse :) > >> > > >> > ramiro has commit rights, he also has a github repo > >> > > >> > you are dshow maintainer, thus if you want me to merge some git > >> > repo/branch just say which ... > >> > >> Ok please merge the https://github.com/rdp/ffmpeg "combined" > >> branch > >> (Ramiro or Michael maybe whoever gets to it first). > >> Thank you. > > > > merged > > > > thanks > > Thanks! > > I am something of a novice to this, and appears I made a small > mistake and the "combined" branch was lacking a commit or 2, could > you > pull and merge it again for me? > Sorry for the inconvenience. Hopefully I'll get some experience > with > this better..
the combined branch is now in bad shape If i do merge it, it would result in below (more merge commits than non merge commits):
I suggest you start a new branch and make sure you dont add merge commits into that branch, you dont need any ATM simply cherry pick all commits you need, then look at the changes and make sure they are ok and test them to make sure they work then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged
thanks
still seems to not work correctly: <BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
On Wed, Feb 13, 2013 at 11:07 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Feb 09, 2013 at 04:11:09AM +0100, Michael Niedermayer wrote:
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote:
On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote: >> On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: >> >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack wrote: >> >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: >> >> >> > Ok after the previous discussion >> >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html >> >> >> > it appears the first patch attached (0001 -- re-attached here >> >> >> > and >> >> >> > modified to apply cleaning to git master) is ok. >> >> >> > >> >> >> > Also attached is a second patch for better error logging >> >> >> > messages. >> >> >> > Thank you for your consideration in their regard. >> >> >> >> >> >> bump for these 2. Or maybe you could give Ramiro commit rights >> >> >> I'm >> >> >> sure he wouldn't abuse :) >> >> > >> >> > ramiro has commit rights, he also has a github repo >> >> > >> >> > you are dshow maintainer, thus if you want me to merge some git >> >> > repo/branch just say which ... >> >> >> >> Ok please merge the https://github.com/rdp/ffmpeg "combined" >> >> branch >> >> (Ramiro or Michael maybe whoever gets to it first). >> >> Thank you. >> > >> > merged >> > >> > thanks >> >> Thanks! >> >> I am something of a novice to this, and appears I made a small >> mistake and the "combined" branch was lacking a commit or 2, could >> you >> pull and merge it again for me? >> Sorry for the inconvenience. Hopefully I'll get some experience >> with >> this better.. > > the combined branch is now in bad shape > If i do merge it, it would result in below (more merge commits than > non merge commits): > > I suggest you start a new branch and make sure you dont add merge > commits into that branch, you dont need any ATM > simply cherry pick all commits you need, then look at the changes > and make sure they are ok and test them to make sure they work > then tell me to merge
Oops didn't realize git tracks merges as well. Please then check the branch combined2 for appropriateness and merge if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged
thanks
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native Shared tables cannot be used as a constant initializer.
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
It appears there already are functions for what you want: - avformat_get_riff_video_tags gives you ff_codec_bmp_tags - avformat_get_riff_audio_tags gives you ff_codec_wav_tags in case you need this too In general i think its a bad idea to export ff* functions and tables, if something is needed rename it to avpriv* or for data tables a getter function is a good idea, because sharing tables is always a bit of a pain. So, hide ff_codec_bmp_tags again (remove av_export and the .v file entry), and usw the existing getter function. :)
On 2/14/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
It appears there already are functions for what you want: - avformat_get_riff_video_tags gives you ff_codec_bmp_tags - avformat_get_riff_audio_tags gives you ff_codec_wav_tags in case you need this too
In general i think its a bad idea to export ff* functions and tables, if something is needed rename it to avpriv* or for data tables a getter function is a good idea, because sharing tables is always a bit of a pain.
It might be nice if ff_raw_pix_fmt_tags in libavcodec/raw.c were exposed via a method as well, instead of being exported as they are today...
On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
While i was looking at the changes, something else confused me in your commit. You added "ff_raw_pix_fmt_tags" to the avformat .v file, but that symbol lives in avcodec?
On 2/14/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
It appears there already are functions for what you want: - avformat_get_riff_video_tags gives you ff_codec_bmp_tags
Oh perfect. I'll add a comment to the source so this is more clear.
In general i think its a bad idea to export ff* functions and tables, if something is needed rename it to avpriv* or for data tables a getter function is a good idea, because sharing tables is always a bit of a pain.
Yeah agree, it seemed odd to export anything named ff_* (but seems to be fairly common, so I left cleaning these and those like it for later work).
So, hide ff_codec_bmp_tags again (remove av_export and the .v file entry), and use the existing getter function. :)
Ok please somebody look at and merge rdp/dshow_c89 when you get the chance.
While i was looking at the changes, something else confused me in your commit. You added "ff_raw_pix_fmt_tags" to the avformat .v file, but that symbol lives in avcodec?
Oops I thought it was from avformat (since everything else I was using was), and, since absent from the .v file, should have been added. Looks like it is already being exported from avcodec, so we should be good there (removed the export .v line in the rdp/dshow_c89 branch). There also seems to be some confusion in my mind, after reading through https://github.com/libav/c99-to-c89/issues/5 it seemed that just adding ff_codec_bmp_tags to the .v file was enough to export, makes me wonder if av_export is needed or not, in other cases [?] but that's unrelated. Thank you. -roger-
On Thu, Feb 14, 2013 at 01:46:44PM -0700, Roger Pack wrote:
On 2/14/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
so can anyone suggest something here? I want to use ff_codec_bmp_tags shared, but apparently this is a special case where av_export won't work with it, because it is used elsewhere as a constant initializer? If there's no response I suppose I will just add a new (exported) method to riff.c that returns the table, and use that instead of raw access to the table...does that sound good? -roger-
It appears there already are functions for what you want: - avformat_get_riff_video_tags gives you ff_codec_bmp_tags
Oh perfect. I'll add a comment to the source so this is more clear.
In general i think its a bad idea to export ff* functions and tables, if something is needed rename it to avpriv* or for data tables a getter function is a good idea, because sharing tables is always a bit of a pain.
Yeah agree, it seemed odd to export anything named ff_* (but seems to be fairly common, so I left cleaning these and those like it for later work).
So, hide ff_codec_bmp_tags again (remove av_export and the .v file entry), and use the existing getter function. :)
Ok please somebody look at and merge rdp/dshow_c89 when you get the chance.
While i was looking at the changes, something else confused me in your commit. You added "ff_raw_pix_fmt_tags" to the avformat .v file, but that symbol lives in avcodec?
Oops I thought it was from avformat (since everything else I was using was), and, since absent from the .v file, should have been added. Looks like it is already being exported from avcodec, so we should be good there (removed the export .v line in the rdp/dshow_c89 branch).
merged with changed commit message (no c98 mention) thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, February 14, 2013 3:46 PM Subject: Re: [FFmpeg-devel] [PATCH] dshow: allow for more codecs take 2 Thanks roger. I was thinking about this when I saw you started on it. The one main thing for me is to enumerate the devices and formats in a convienent way. We have list_devices and list_formats but this is routed thru av_log which to me is sick. I currently still do the enumeration in my own app because it makes the best sense. There are 2 problems with this. One is I have to tie my code to dshow which means its not as portable as I would like but I could get around this by just doing another library but avdevice is already there. Two is I don't know the option names for the various pixel formats. Like I get mmioFOURCC ('I','4','2','0') as an optional pixel format and I had to lookup that it maps to yuv420p so I could set that option if I needed it. Now that info comes thru with list_formats etc., but looking thru the av_log output is silly. I think there is a desire to have something like: "get_dshow_device_list" which contains the devices and their formats in one call... and also "free_dshow_device_list"
On 2/18/13, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, February 14, 2013 3:46 PM Subject: Re: [FFmpeg-devel] [PATCH] dshow: allow for more codecs take 2
Thanks roger. I was thinking about this when I saw you started on it.
The one main thing for me is to enumerate the devices and formats in a convienent way.
Yeah eventually someone should integrate it with the new enumerate API (which I haven't looked at yet, possibly someday :).
On 2/13/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Wed, Feb 13, 2013 at 11:07 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Feb 09, 2013 at 04:11:09AM +0100, Michael Niedermayer wrote:
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote:
On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote: > On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote: > >> On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > >> > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: > >> >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: > >> >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack > >> >> > wrote: > >> >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > >> >> >> > Ok after the previous discussion > >> >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > >> >> >> > it appears the first patch attached (0001 -- > >> >> >> > re-attached here > >> >> >> > and > >> >> >> > modified to apply cleaning to git master) is ok. > >> >> >> > > >> >> >> > Also attached is a second patch for better error > >> >> >> > logging > >> >> >> > messages. > >> >> >> > Thank you for your consideration in their regard. > >> >> >> > >> >> >> bump for these 2. Or maybe you could give Ramiro commit > >> >> >> rights > >> >> >> I'm > >> >> >> sure he wouldn't abuse :) > >> >> > > >> >> > ramiro has commit rights, he also has a github repo > >> >> > > >> >> > you are dshow maintainer, thus if you want me to merge > >> >> > some git > >> >> > repo/branch just say which ... > >> >> > >> >> Ok please merge the https://github.com/rdp/ffmpeg > >> >> "combined" > >> >> branch > >> >> (Ramiro or Michael maybe whoever gets to it first). > >> >> Thank you. > >> > > >> > merged > >> > > >> > thanks > >> > >> Thanks! > >> > >> I am something of a novice to this, and appears I made a > >> small > >> mistake and the "combined" branch was lacking a commit or 2, > >> could > >> you > >> pull and merge it again for me? > >> Sorry for the inconvenience. Hopefully I'll get some > >> experience > >> with > >> this better.. > > > > the combined branch is now in bad shape > > If i do merge it, it would result in below (more merge commits > > than > > non merge commits): > > > > I suggest you start a new branch and make sure you dont add > > merge > > commits into that branch, you dont need any ATM > > simply cherry pick all commits you need, then look at the > > changes > > and make sure they are ok and test them to make sure they work > > then tell me to merge > > Oops didn't realize git tracks merges as well. > Please then check the branch combined2 for appropriateness and > merge > if appropriate.
merged
thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged
thanks
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
So what I'm understanding is that the following this is a feature of c99: "Shared tables used as a constant initializer" (i.e. a c99-c89 code converter can't overcome it trivially?) so when I made that particular variable shared, it introduced it (by making the table shared). I guess that makes sense. Sorry for introducing the c99 feature accidentally.
On Thu, Feb 14, 2013 at 9:39 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
On 2/13/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Wed, Feb 13, 2013 at 11:07 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Feb 09, 2013 at 04:11:09AM +0100, Michael Niedermayer wrote:
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer wrote: > On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote: > > On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > > On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote: > > >> On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > >> > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack wrote: > > >> >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > >> >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack > > >> >> > wrote: > > >> >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: > > >> >> >> > Ok after the previous discussion > > >> >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html > > >> >> >> > it appears the first patch attached (0001 -- > > >> >> >> > re-attached here > > >> >> >> > and > > >> >> >> > modified to apply cleaning to git master) is ok. > > >> >> >> > > > >> >> >> > Also attached is a second patch for better error > > >> >> >> > logging > > >> >> >> > messages. > > >> >> >> > Thank you for your consideration in their regard. > > >> >> >> > > >> >> >> bump for these 2. Or maybe you could give Ramiro commit > > >> >> >> rights > > >> >> >> I'm > > >> >> >> sure he wouldn't abuse :) > > >> >> > > > >> >> > ramiro has commit rights, he also has a github repo > > >> >> > > > >> >> > you are dshow maintainer, thus if you want me to merge > > >> >> > some git > > >> >> > repo/branch just say which ... > > >> >> > > >> >> Ok please merge the https://github.com/rdp/ffmpeg > > >> >> "combined" > > >> >> branch > > >> >> (Ramiro or Michael maybe whoever gets to it first). > > >> >> Thank you. > > >> > > > >> > merged > > >> > > > >> > thanks > > >> > > >> Thanks! > > >> > > >> I am something of a novice to this, and appears I made a > > >> small > > >> mistake and the "combined" branch was lacking a commit or 2, > > >> could > > >> you > > >> pull and merge it again for me? > > >> Sorry for the inconvenience. Hopefully I'll get some > > >> experience > > >> with > > >> this better.. > > > > > > the combined branch is now in bad shape > > > If i do merge it, it would result in below (more merge commits > > > than > > > non merge commits): > > > > > > I suggest you start a new branch and make sure you dont add > > > merge > > > commits into that branch, you dont need any ATM > > > simply cherry pick all commits you need, then look at the > > > changes > > > and make sure they are ok and test them to make sure they work > > > then tell me to merge > > > > Oops didn't realize git tracks merges as well. > > Please then check the branch combined2 for appropriateness and > > merge > > if appropriate. > > merged > > thanks
this (or possibly another commit) broke msvc10 see: http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged
thanks
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
So what I'm understanding is that the following this is a feature of c99: "Shared tables used as a constant initializer" (i.e. a c99-c89 code converter can't overcome it trivially?) so when I made that particular variable shared, it introduced it (by making the table shared). I guess that makes sense. Sorry for introducing the c99 feature accidentally.
This has nothing to do with C99 or C89. Its just a quirk between how importing data symbols works in MSVC and how av_export is defined. When you want to import a data symbol in MSVC, you have to mark the definition with declspec(dllimport). Doing this, it basically adds another indirection to the struct, which results in it not being able to be used in constant initializers anymore. However, the usual way to mark such symbols in headers is to have a macro which at compile time is "declspec(dllexport)" (or empty if you export it through other means), and when using the header to link against the lib, the macro is defined to "declspec(dllimport)". The problem here is that av_export is too dumb. Its always "declspec(dllimport)", so the symbols get converted into a imported symbol even if they are in the same library, and because the compiler doesn't know where the linker will find the symbol, it'll add the extra indirection, breaking constant initiliazers. av_export was defined this way "on purpose", to keep it simple, because the cross-library deps between different libs in the same project make defining a "correct" macro for this task a bit more complex, so this caveat was an accepted compromise.
On 2/14/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Thu, Feb 14, 2013 at 9:39 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
On 2/13/13, Hendrik Leppkes <h.leppkes@gmail.com> wrote:
On Wed, Feb 13, 2013 at 11:07 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Feb 09, 2013 at 04:11:09AM +0100, Michael Niedermayer wrote:
On Fri, Feb 08, 2013 at 06:18:51PM -0700, Roger Pack wrote:
On 2/7/13, Michael Niedermayer <michaelni@gmx.at> wrote: > On Wed, Feb 06, 2013 at 08:19:01PM +0100, Michael Niedermayer > wrote: >> On Wed, Feb 06, 2013 at 10:55:53AM -0700, Roger Pack wrote: >> > On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> > > On Tue, Feb 05, 2013 at 02:24:42PM -0700, Roger Pack wrote: >> > >> On 2/5/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> > >> > On Tue, Feb 05, 2013 at 10:05:52AM -0700, Roger Pack >> > >> > wrote: >> > >> >> On 2/4/13, Michael Niedermayer <michaelni@gmx.at> wrote: >> > >> >> > On Mon, Feb 04, 2013 at 01:50:11PM -0700, Roger Pack >> > >> >> > wrote: >> > >> >> >> On 1/25/13, Roger Pack <rogerdpack2@gmail.com> wrote: >> > >> >> >> > Ok after the previous discussion >> > >> >> >> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/131942.html >> > >> >> >> > it appears the first patch attached (0001 -- >> > >> >> >> > re-attached here >> > >> >> >> > and >> > >> >> >> > modified to apply cleaning to git master) is ok. >> > >> >> >> > >> > >> >> >> > Also attached is a second patch for better error >> > >> >> >> > logging >> > >> >> >> > messages. >> > >> >> >> > Thank you for your consideration in their regard. >> > >> >> >> >> > >> >> >> bump for these 2. Or maybe you could give Ramiro >> > >> >> >> commit >> > >> >> >> rights >> > >> >> >> I'm >> > >> >> >> sure he wouldn't abuse :) >> > >> >> > >> > >> >> > ramiro has commit rights, he also has a github repo >> > >> >> > >> > >> >> > you are dshow maintainer, thus if you want me to merge >> > >> >> > some git >> > >> >> > repo/branch just say which ... >> > >> >> >> > >> >> Ok please merge the https://github.com/rdp/ffmpeg >> > >> >> "combined" >> > >> >> branch >> > >> >> (Ramiro or Michael maybe whoever gets to it first). >> > >> >> Thank you. >> > >> > >> > >> > merged >> > >> > >> > >> > thanks >> > >> >> > >> Thanks! >> > >> >> > >> I am something of a novice to this, and appears I made a >> > >> small >> > >> mistake and the "combined" branch was lacking a commit or 2, >> > >> could >> > >> you >> > >> pull and merge it again for me? >> > >> Sorry for the inconvenience. Hopefully I'll get some >> > >> experience >> > >> with >> > >> this better.. >> > > >> > > the combined branch is now in bad shape >> > > If i do merge it, it would result in below (more merge >> > > commits >> > > than >> > > non merge commits): >> > > >> > > I suggest you start a new branch and make sure you dont add >> > > merge >> > > commits into that branch, you dont need any ATM >> > > simply cherry pick all commits you need, then look at the >> > > changes >> > > and make sure they are ok and test them to make sure they >> > > work >> > > then tell me to merge >> > >> > Oops didn't realize git tracks merges as well. >> > Please then check the branch combined2 for appropriateness and >> > merge >> > if appropriate. >> >> merged >> >> thanks > > this (or possibly another commit) broke msvc10 > see: > http://fate.ffmpeg.org/report.cgi?time=20130207203228&slot=x86_32-msvc10-dll-windows-native
Inexperience shows its face again. Shared builds were broken (mingw too). I've set up my build system to catch them more easily next time. I believe I've figured them out (at least for mingw cross compile it works now) if you could merge rdp/dshow_shared. Thanks for your patience.
merged
thanks
still seems to not work correctly:
<BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[] with av_export <BBB-work> can whoever did that fix it? <BBB-work> https://github.com/libav/c99-to-c89/issues/5
[...]
This is also covered by a fate instance: http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
Shared tables cannot be used as a constant initializer.
So what I'm understanding is that the following this is a feature of c99: "Shared tables used as a constant initializer" (i.e. a c99-c89 code converter can't overcome it trivially?) so when I made that particular variable shared, it introduced it (by making the table shared). I guess that makes sense. Sorry for introducing the c99 feature accidentally.
This has nothing to do with C99 or C89. Its just a quirk between how importing data symbols works in MSVC and how av_export is defined.
When you want to import a data symbol in MSVC, you have to mark the definition with declspec(dllimport). Doing this, it basically adds another indirection to the struct, which results in it not being able to be used in constant initializers anymore. However, the usual way to mark such symbols in headers is to have a macro which at compile time is "declspec(dllexport)" (or empty if you export it through other means), and when using the header to link against the lib, the macro is defined to "declspec(dllimport)".
The problem here is that av_export is too dumb. Its always "declspec(dllimport)", so the symbols get converted into a imported symbol even if they are in the same library, and because the compiler doesn't know where the linker will find the symbol, it'll add the extra indirection, breaking constant initiliazers. av_export was defined this way "on purpose", to keep it simple, because the cross-library deps between different libs in the same project make defining a "correct" macro for this task a bit more complex, so this caveat was an accepted compromise.
Ok that makes sense now thanks for the clarification.
participants (5)
-
Don Moir -
Hendrik Leppkes -
Michael Niedermayer -
Ramiro Polla -
Roger Pack