Note: Altivec versions cannot be tested on my own machine. Please report if there any issues, although I probably won't be able to fix them. The Altivec version is naturally linked with an altivec version of libx264.
Pretty much everything enabled. ffplay may crash on exit. x264 encoding will require you to use one of the existing preset files. Use -vpre, don't include .ffpreset extension or path name.
This is for you, Kicko. XSUB encoding. I have no idea how to use it, but it's got the support for it!
Thanks Mrodfr for bringing back my attention to this software.
-- Edit --
Kicko, unfortunately ffmpeg can't demux or decode .srt subtitles. So XSUB encoding from .srt won't be possible.
-- End edit --
Edited by MickJT on 2010/7/4 16:00:57 Edited by MickJT on 2010/7/5 9:01:34 Edited by MickJT on 2010/7/5 12:15:13 Edited by MickJT on 2010/7/5 14:40:03 Edited by MickJT on 2010/7/5 14:40:55 Edited by MickJT on 2010/7/8 10:01:35 Edited by MickJT on 2010/7/8 12:58:28 Edited by MickJT on 2010/10/29 12:12:15
MickJT wrote: Need testers. FFmpeg - For now, set high stack
This is great! I've modified ffmpegGUI to recognize this version number. The version number doesn't follow, what at least used to be, the standard version number scheme for ffmpeg. Unfortunatly that causes ffmpegGUI to crash. I've made the version routine a bit more flexible so it doesn't crash and I modified to recognise this version as valid. Other version numbers should produce a warning but allow you to continue.
I did a little playing around and it appears this verison of ffmpeg doesn't know how to handle Amiga paths properly unless I'm missing something.
For example: ffmpeg -i jws.mpeg jws.avi works as expected as long as the videos are in the current directory, but...
ffmpeg -i ram:jws.mpeg jws.avi produces the followiing error message:
"ram:jws.mpeg: No such file or directory"
Did a bit more playing and my suspision was right. It's looking for unix style paths. The following works:
ffmpeg -i /ram/jws.mpeg jws.avi
That makes it a bit tough to use with ffmpegGUI and file requesters. You can type the paths into ffmpegGUI manually though and it will work. ffplay of course has the same issue. What would it take to fix this in ffmpeg?
I built it with -lunix to support unix paths, but that has never stopped it from working with Amiga paths before. I'll try your example and edit this post in the coming minutes.
Edit: It's strange. It's only RAM: with the problem. "RAM Disk:" in quotes is fine, and every other Amiga path is fine too, just not RAM:. I will build it again without -lunix and see what happens, but it's a very large program and takes a couple of hours to build from scratch (and stupid me went and deleted the directory with all the object files because I thought it was ready).
I built it with -lunix to support unix paths, but that has never stopped it from working with Amiga paths before. I'll try your example and edit this post in the coming minutes.
Edit: It's strange. It's only RAM: with the problem. "RAM Disk:" in quotes is fine, and every other Amiga path is fine too, just not RAM:.
Hmm....doesn't appear to just be RAM: here.
For example the following: ffmpeg -i "Data:Movies/jws.mpeg" "Data:Output.avi"
results in: Data:Movies/jws.mpeg: No such file or directory
Thanks for the quick response. I'm heading to bed soon. It's 2:20am here.
It's compiling. I'm going out now and will edit the first post in the thread when I get back.
It doesn't appear ffmpeg needs any high stack anyway, but i'll modify the source to include a stack cookie just incase, and so no-one has to remember to set a stack.
-lunix isn't doing it. Looking in Snoopy and SnoopDos, certain paths and filenames make ffmpeg not even bother to look for it, change the path to something else that doesn't exist, then it'll look for it, fail, and print the exact same message.
Quite peculiar. Looking into it now. If worse comes to worse, you could always make the GUI convert to unix-style paths if absolutely needed.
--- Edit ---
Must be a bug in ffmpeg. A workaround is to assign something with a space or a number, to the partition you want, and then use that assign.
It's really interesting. If Windows allows colons in filenames, i'm going to do some testing and see if the bug exists in the Windows build too. On Windows, it'll see ram:test.mp4 as a filename with a colon, in the current directory. If I can name a file something with a colon, then change to ram2:test.mp4, and 1 works while the other doesn't, then it proves it's a bug in ffmpeg 0.6.
--- End edit ---
Edit2: Tested with ffmpeg windows build from January 2009. I couldn't put a colon in a filename, so I used a tool called "ProcMon" to monitor the system processes. When the input path is something like test:something.avi, it doesn't even try to find the file. Use test2:something.avi or "tes t:something.avi", and it does. Therefore, it's either some feature i'm unaware of, or a bug that Andrea is aware of and fixed in his port.
Edited by MickJT on 2010/7/4 15:25:27 Edited by MickJT on 2010/7/4 15:46:28 Edited by MickJT on 2010/7/4 18:56:01
MickJT wrote: Quite peculiar. Looking into it now. If worse comes to worse, you could always make the GUI convert to unix-style paths if absolutely needed.
If worst comes to worst then this would probably be the best workaround in the GUI. Better than making a bunch of assings on peoples systems. I noticed the most recent version you posted doesn't recognize unix style paths anymore. Of course fixing ffmpeg is the best solution. In looking at your biuld it looks like you might have used different libraries for a couple of things than our current build of ffmpeg so I might have make changes to ffmpegGUI to accomidate the differences. I believe I already have code in place to make it easy to accomidate that though.
I assume the plan is to replace the current ffmpeg when you release the new version?
The goal would be to replace it sometime in the future.
ffmpeg constantly evolves, previously you used -vcodec h264, not -vcodec libx264. There was a time it was something else instead of -acodec libmp3lame too.
I'm re-uploading the versions again linked with libunix, since they don't prevent Amiga style paths from working. (Edit: Done. Same filesize, but it is a different build).
The goal would be to replace it sometime in the future.
Ok, I was asking because I was deciding if I should support the current version in addition to this new version or just modify ffmpegGUI to work with this version. I think I'll support both for now unless it becomes to much work.
Quote:
ffmpeg constantly evolves, previously you used -vcodec h264, not -vcodec libx264. There was a time it was something else instead of -acodec libmp3lame too.
Yes, things do constantly change and that's why I put the provisions in ffmpegGUI to fairly easily accomidate such changes. It's also one of the reasons I only support OS4 and don't try to support other OS's.
Quote:
I'm re-uploading the versions again linked with libunix, since they don't prevent Amiga style paths from working. (Edit: Done. Same filesize, but it is a different build).
Two hints for you: - Fully qualify the URL with file: prefix. For instance, "file:ram:blah.avi" - Implement is_dos_path() in ffmpeg so that it also works for amigaos paths. Originally, it only works for Windows 1-letter drives.
While file: works and is a good solution for a GUI,
I've modified ffmpegGUI to append file: transparently to the paths. Turns out, as I thought, I already had routines to dealing with issuing different commands for different versions of ffmpegGUI so I quickly added support for this version. (Let me know your version number changes.)
Also, I noticed that arm_wb audio encoding is no longer supported by this version so I set it up to use arm_nb encoding instead when selected with this version. It still support arm_wb encoding with the currently released ffmpeg.
What do you mean "currently released"? The latest ffmpeg doesn't have support for AMR wideband encoding anymore; Not since they changed to opencore-amr.
I see where in the code I can fix these path problems up, but i'm struggling to do it properly. I need help. I can think of 3 ways.
1) Does the file path exist? Yes? Then it's a valid amiga path
Problem: Never did it because I assume volume requesters would appear to check the existance of an HTTP or TCP device if you ever fed a URL as input, making you click cancel before it'd continue working.
2) If the protocol string is not http, rtmp, udp, tcp, concat, etc.. then the file path is considered valid.
Problem: Doesn't want to work for me, because I obviously don't know what i'm doing :)
3) Do it properly and check the existance of the volume name / assign or device before the colon in the file path.
in the file libavformat/avio.c add the __AMIGAOS4__ define
int url_open(URLContext **puc, const char *filename, int flags)
{
URLProtocol *up;
const char *p;
char proto_str[128], *q;
p = filename;
q = proto_str;
while (*p != '\0' && *p != ':') {
/* protocols can only contain alphabetic chars */
if (!isalpha(*p))
goto file_proto;
if ((q - proto_str) < sizeof(proto_str) - 1)
*q++ = *p;
p++;
}
/* if the protocol has length 1, we consider it is a dos drive */
if (*p == '\0' || is_dos_path(filename)) {
file_proto:
strcpy(proto_str, "file");
} else {
*q = '\0';
}
up = first_protocol;
while (up != NULL) {
if (!strcmp(proto_str, up->name))
return url_open_protocol (puc, up, filename, flags);
up = up->next;
}
[b]#ifdef __AMIGAOS4__
strcpy(proto_str, "file");
up = first_protocol;
while (up != NULL) {
if (!strcmp(proto_str, up->name))
return url_open_protocol (puc, up, filename, flags);
up = up->next;
}
#endif[/b]
*puc = NULL;
return AVERROR(ENOENT);
}
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
