The SDAppend Project

InsipidMuckyWater

Edit history:

InsipidMuckyWater: 2011-05-07 03:16:10 pm

InsipidMuckyWater: 2011-05-07 03:13:52 pm

2011-05-07 03:13:39 pm

Visit my profile to see my runs!

Only happens when there is desynch (runs whose parts were not encoded under the same settings, such as compilation runs or IL tables)

Poxnor: Because I discovered it. Lol. Don't worry, if I knew anything about programming or what not, I probably wouldn't read the typical IMW post either. Usually it's just an overdose of naivete.

Mystery

2011-05-07 03:16:37 pm

I would have thought it would refuse to append them in such case...

InsipidMuckyWater

2011-05-07 03:17:40 pm

Visit my profile to see my runs!

Yeah you'd think. Instead it likes to pretend it's capable of doing the job and just f*cks it up.

Poxnor

Edit history:

Poxnor: 2011-05-08 12:42:17 am

2011-05-08 12:36:57 am

Moo! Flap! Hug!

Quote from InsipidMuckyWater:

Poxnor: Because I discovered it. Lol. Don't worry, if I knew anything about programming or what not, I probably wouldn't read the typical IMW post either. Usually it's just an overdose of naivete.

Couldn't disagree more. Despite not being a programmer, you've jumped head-first into experimenting with a whole bunch of things, providing valuable feedback, and giving suggestions and reports on what's worked. I'd work on a project with you any day Smiley

I just somehow missed your post on avidemux. I blame rum, or possibly vodka.

Edit: If nothing else, my code is up there for anyone running OS X / *NIX, as a stupidly simple way to merge same-encoding MP4s Smiley

If I ever have the time, I'll see if I can get first MP4v2 ( Sad

) and then my MP4Utils ( Smiley

) to compile under Visual Studio. The only Posix-specific thing I was actually doing in the code (aside from some gcc variadic error-reporting macros and minor printf stuff, like Mystery pointed out) was using access(2) to determine if a file existed, as opposed to the ANSI-standard fopen / !=NULL approach. I replaced that in my local tree, so there are no Posix includes anymore; the rest should be minor.

[quote="InsipidMuckyWater"]Poxnor: Because I discovered it.  Lol.  Don't worry, if I knew anything about programming or what not, I probably wouldn't read the typical IMW post either.  Usually it's just an overdose of naivete.[/quote]
Couldn't disagree more.  Despite not being a programmer, you've jumped head-first into experimenting with a whole bunch of things, providing valuable feedback, and giving suggestions and reports on what's worked.  I'd work on a project with you any day :)  I just somehow missed your post on avidemux.  I blame rum, or possibly vodka.

Edit: If nothing else, my code is up there for anyone running OS X / *NIX, as a stupidly simple way to merge same-encoding MP4s :)  If I ever have the time, I'll see if I can get first MP4v2 ( :( ) and then my MP4Utils ( :) ) to compile under Visual Studio.  The only Posix-specific thing I was actually doing in the code (aside from some gcc variadic error-reporting macros and minor printf stuff, like Mystery pointed out) was using access(2) to determine if a file existed, as opposed to the ANSI-standard fopen / !=NULL approach.  I replaced that in my local tree, so there are no Posix includes anymore; the rest should be minor.

nate

2011-05-08 08:14:59 am

just install mingw, go into cmd.exe, and type gcc -Wall your_program.c -o your_program.exe. since this is gpl you don't have to worry about building or using dlls. the only catch will be mp4v2 which i'd never even heard of and know nothing about. i doubt you need cygwin for anything.

__sdfg

2011-05-08 10:58:55 am

D:

If you want to go the MinGW route, I suggest using MSYS so autotools will be available. It'd (probably) be easier than trying to link your objects & the MP4v2 objects from the command line yourself. I don't recommend using Cygwin because you'd have to either distribute the Cygwin binaries with your app or tell all of your end-users to install Cygwin themselves (it would let you avoid taking out the POSIX calls, though).

Also, I glanced at the MP4v2 utils readme and it looks like a Visual Studio 2008 solution is included, so if you have access to Windows & Visual Studio, porting over there shouldn't be too hard.

Mystery

2011-05-08 12:09:24 pm

Quote from __sdfg:

If you want to go the MinGW route, I suggest using MSYS so autotools will be available. It'd (probably) be easier than trying to link your objects & the MP4v2 objects from the command line yourself. I don't recommend using Cygwin because you'd have to either distribute the Cygwin binaries with your app or tell all of your end-users to install Cygwin themselves (it would let you avoid taking out the POSIX calls, though).

Also, I glanced at the MP4v2 utils readme and it looks like a Visual Studio 2008 solution is included, so if you have access to Windows & Visual Studio, porting over there shouldn't be too hard.

Funny, I didn't notice that when I tried it >_< It would have made things so much easier.
I think the biggest obstacle was the weird paths used by MP4v2, which I could never get to work properly. However I did, it always seemed to miss some bloody header.

Poxnor

Edit history:

Poxnor: 2011-05-08 12:26:07 pm

2011-05-08 12:25:40 pm

Moo! Flap! Hug!

Yeah, I've almost got MP4v2 compiled with MinGW, but I haven't succeeded. Its build system is such a mess that I can barely follow what it's doing. I could try with Visual Studio (I can get a copy through my university).

There was only the single Posix call in my MP4Utils code (using access(2) instead of fopen(3) != NULL to determine if a file exists), and it's gone now, so that's not a concern. I'd just have to change, e.g., the variadic error-reporting macros, if those aren't supported in Visual Studio.

Mystery

2011-05-08 12:27:55 pm

Visual Studio does not support C99 nor GNU-specific extensions. So that might be a bit of a pain.

Poxnor

2011-05-08 12:29:31 pm

Moo! Flap! Hug!

Quote from Mystery:

Visual Studio does not support C99 nor GNU-specific extensions. So that might be a bit of a pain.

*blink* I understand not supporting the GNU extensions, obviously. But C99? It's a twelve-year-old standard! Oye. Maybe I'll take another stab at getting MinGW to compile MP4v2 Wink

Mystery

2011-05-08 12:37:56 pm

Quote from Poxnor:

...But C99? It's a twelve-year-old standard! Oye. Maybe I'll take another stab at getting MinGW to compile MP4v2 Wink

I'm guessing there just hasn't been enough demand from Microsoft's C users.
Microsoft is putting their efforts into their .Net languages and C++ (C++11 is partially supported in the newest version).