Thread: [Pspvc-users] New open source project : The Sinthgunt Converter
Brought to you by:
fif1973
From: Kåre H. J. <kar...@gm...> - 2009-06-05 16:03:10
|
This is a one-time post to announce the creation of the Sinthgunt project, an open source graphical user interface for ffmpeg, a computer program that can convert digital audio and video into numerous formats. Sinthgunt is now running code, is under active development, and is looking for both developers and testers. Home page: www.sinthgunt.org Features: * Sinthgunt is an easy to use gui for ffmpeg * It has more than 100 pre-configured conversion settings * It automatically detects which presets are supported by your version of ffmpeg * It is easy to extend, since the conversion settings are stored in a xml file * Sinthgunt is purely open source, written in Python and licensed under GNU GPLv3 Requirements: * Python * ffmpeg For more information, please come to www.sinthgunt.org Thank you, -- Kaare Hartvig Jensen and Thomas R. N. Jansson |
From: Krzysztof B. <kb...@sy...> - 2009-06-06 09:50:38
|
Hello, if you asked me i would say that you waste your time but this is your time of course. according to my experience with ffplay and built-in ffmpeg support for rtsp/rtp i say that ffmpeg is rubbish except codecs. and the perfectly working solution is gstreamer ( http://gstreamer.freedesktop.org/ ) which utilizes ffmpeg but only as library of codecs of course. my tests on x86_64 proved gstreamer design correctness and i'm especially pleased with its realtime response which is even better than i saw using mplayer. furthermore i built gstreamer for armv5te and it works fine too on arm926 @1.2GHz: 25fps @704x576 mpeg4 takes abt 50-60% cpu time. I have not seen any rtsp and mpeg issues anymore. so my conclusion is you chose wrong project to create "mouse-clicking" interface. I would like also to say thank you to all these people who created that rtsp/rtp (and maybe demux) misery. Regards, Krzysztof Blaszkowski On Friday 05 June 2009 18:02, Kåre Hartvig Jensen wrote: > This is a one-time post to announce the creation of the Sinthgunt > project, an open source > graphical user interface for ffmpeg, a computer program that can > convert digital audio and > video into numerous formats. Sinthgunt is now running code, is under > active development, > and is looking for both developers and testers. > > Home page: www.sinthgunt.org > > Features: > > * Sinthgunt is an easy to use gui for ffmpeg > * It has more than 100 pre-configured conversion settings > * It automatically detects which presets are supported by your > version of ffmpeg > * It is easy to extend, since the conversion settings are stored > in a xml file > * Sinthgunt is purely open source, written in Python and licensed > under GNU GPLv3 > > Requirements: > > * Python > * ffmpeg > > For more information, please come to www.sinthgunt.org > > Thank you, > -- Kaare Hartvig Jensen and Thomas R. N. Jansson > _______________________________________________ > ffmpeg-user mailing list > ffm...@mp... > https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user |
From: Baptiste C. <bap...@gm...> - 2009-06-06 19:11:03
|
Hi, Krzysztof Błaszkowski wrote: > Hello, > > if you asked me i would say that you waste your time but this is your time of > course. > > according to my experience with ffplay and built-in ffmpeg support for > rtsp/rtp i say that ffmpeg is rubbish except codecs. May I ask what is not working exactly ? If something is broken it must be fixed. Besides, many projects already leverage ffmpeg and libavformat and while there might be some problems, it seems to working decently. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |
From: Krzysztof B. <kb...@sy...> - 2009-06-07 10:21:31
|
Hi, On Saturday 06 June 2009 21:10, Baptiste Coudurier wrote: > Hi, > > Krzysztof Błaszkowski wrote: > > Hello, > > > > if you asked me i would say that you waste your time but this is your > > time of course. > > > > according to my experience with ffplay and built-in ffmpeg support for > > rtsp/rtp i say that ffmpeg is rubbish except codecs. > > May I ask what is not working exactly ? Sure. furthermore I expected such question a few days ago. Of course i can't tell what exactly is wrong (file, line, function, structure, memory flow, locking, thread) due to many reasons: - i'm not enough familiar with ffmpeg, - i don't want to be because i can't see any need to be, - i would have to grab rfcs regarding rtsp/rtp + some additional docs on mpeg rtp encapsulation possibly (assuming they are available somewhere) to recall all details but i do not have time for this. but i can describe what i have observed already. I test ip cam like nvip-hdn ( http://www.novuscctv.com/en/products/2/1058/1060 ) which utilizes live555 for streaming server. AND with ffplay it starts nicely but after ca 30 secs ffplay outputs lots of errors on console and even worse the mpeg4 codec output is very distorted. I will send to your address some screenshots with examples (jpgs of avg size 200-300k) i noticed also huge latency time just right before 1st errors which is ca 2-3 secs. the latency time may gradually increase since start of ffplay process but i'm not sure of that. altough 2-3 seconds delay may be acceptable for some porn watching but it is definitely not acceptable for real time analysis (e.g road traffic, car @100km/h travels ca 3m in 100ms) as i have noted already there is available brilliant solution thus now i'm not interested in fixing this issue. but i may create some logs (not too many) for someone who has an idea. of course it will not be done immediately because i'm busy with other things. > If something is broken it must > be fixed. yes, this separates professionalists from hobbyists. professionalists do not cowardly pretend they are good while reality is quite different. > > Besides, many projects already leverage ffmpeg and libavformat and while > there might be some problems, it seems to working decently. great. so there is a corner case where it failed. Krzysztof Blaszkowski |
From: Baptiste C. <bap...@gm...> - 2009-06-07 18:45:06
|
Krzysztof Błaszkowski wrote: > Hi, > > On Saturday 06 June 2009 21:10, Baptiste Coudurier wrote: >> Hi, >> >> Krzysztof Błaszkowski wrote: >>> Hello, >>> >>> if you asked me i would say that you waste your time but this is your >>> time of course. >>> >>> according to my experience with ffplay and built-in ffmpeg support for >>> rtsp/rtp i say that ffmpeg is rubbish except codecs. >> May I ask what is not working exactly ? > > [...] > > but i can describe what i have observed already. > > I test ip cam like nvip-hdn ( > http://www.novuscctv.com/en/products/2/1058/1060 ) which utilizes live555 for > streaming server. > AND with ffplay it starts nicely but after ca 30 secs ffplay outputs lots of > errors on console and even worse the mpeg4 codec output is very distorted. Ok, could you please post the output of ffmpeg -i to double check what stream is actually read, to get a chance to find a similar stream to be able to reproduce the problem ? Thanks [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |
From: Krzysztof B. <kb...@sy...> - 2009-06-08 15:49:15
Attachments:
log.log
|
Hi, ffmpeg on its console outputs something like included. Krzysztof Blaszkowski On Sunday 07 June 2009 20:45, Baptiste Coudurier wrote: > Krzysztof Błaszkowski wrote: > > Hi, > > > > On Saturday 06 June 2009 21:10, Baptiste Coudurier wrote: > >> Hi, > >> > >> Krzysztof Błaszkowski wrote: > >>> Hello, > >>> > >>> if you asked me i would say that you waste your time but this is your > >>> time of course. > >>> > >>> according to my experience with ffplay and built-in ffmpeg support for > >>> rtsp/rtp i say that ffmpeg is rubbish except codecs. > >> > >> May I ask what is not working exactly ? > > > > [...] > > > > but i can describe what i have observed already. > > > > I test ip cam like nvip-hdn ( > > http://www.novuscctv.com/en/products/2/1058/1060 ) which utilizes live555 > > for streaming server. > > AND with ffplay it starts nicely but after ca 30 secs ffplay outputs lots > > of errors on console and even worse the mpeg4 codec output is very > > distorted. > > Ok, could you please post the output of ffmpeg -i to double check what > stream is actually read, to get a chance to find a similar stream to be > able to reproduce the problem ? > > Thanks > > [...] |
From: Krzysztof B. <kb...@sy...> - 2009-06-15 18:09:01
|
Hello Mr Coudurier, I think it is pointless to continue this thread because: 1) it is said that someone who wrote rtsp/rtp doesn't understand own work. 2) there are other frameworks which use avcodecs and work well. I do have many objections about ffplay and ffmpeg log quality and thus quality of code. apparently theirs authors miss some good kernel coding experience. also i reckon that console output of ffmpeg is useless. if i were you i would ask rather for some ethernet capture file with that rtsp/rtp session but you revealed rather lack of professional skills. ffmeg distorts the stream different way than ffplay. this raises more questions about quality. I included here also Youri because i saw that similar rtsp/rtp crappines topic use to appear periodically. due to that i am disappointed at your attitude i decided to unsubscribe from this list. (so you are welcome to not reply) Krzysztof Blaszkowski On Monday 08 June 2009 17:49, Krzysztof Błaszkowski wrote: > Hi, > > ffmpeg on its console outputs something like included. > > Krzysztof Blaszkowski > > On Sunday 07 June 2009 20:45, Baptiste Coudurier wrote: > > Krzysztof Błaszkowski wrote: > > > Hi, > > > > > > On Saturday 06 June 2009 21:10, Baptiste Coudurier wrote: > > >> Hi, > > >> > > >> Krzysztof Błaszkowski wrote: > > >>> Hello, > > >>> > > >>> if you asked me i would say that you waste your time but this is your > > >>> time of course. > > >>> > > >>> according to my experience with ffplay and built-in ffmpeg support > > >>> for rtsp/rtp i say that ffmpeg is rubbish except codecs. > > >> > > >> May I ask what is not working exactly ? > > > > > > [...] > > > > > > but i can describe what i have observed already. > > > > > > I test ip cam like nvip-hdn ( > > > http://www.novuscctv.com/en/products/2/1058/1060 ) which utilizes > > > live555 for streaming server. > > > AND with ffplay it starts nicely but after ca 30 secs ffplay outputs > > > lots of errors on console and even worse the mpeg4 codec output is very > > > distorted. > > > > Ok, could you please post the output of ffmpeg -i to double check what > > stream is actually read, to get a chance to find a similar stream to be > > able to reproduce the problem ? > > > > Thanks > > > > [...] |
From: Baptiste C. <bap...@gm...> - 2009-06-15 21:13:49
|
Mr Błaszkowski, Krzysztof Błaszkowski wrote: > Hello Mr Coudurier, > > I think it is pointless to continue this thread because: > 1) it is said that someone who wrote rtsp/rtp doesn't understand own work. I'm not aware of this, but may I ask you what these claims are based on ? > 2) there are other frameworks which use avcodecs and work well. That's possible indeed. > I do have many objections about ffplay and ffmpeg log quality and thus quality > of code. apparently theirs authors miss some good kernel coding experience. FFmpeg is nowhere related to kernel, so I'm confused. Log quality may certainly be improved, however, and patches improving this is welcome as usual. > also i reckon that console output of ffmpeg is useless. if i were you i would > ask rather for some ethernet capture file with that rtsp/rtp session but you > revealed rather lack of professional skills. Console output of FFmpeg is usefull for 2 things: - Knowing what version you are using - Knowing what kind of stream it is I obtained these informations. Now about the ethernet capture file, that may certainly be useful, but in a second step. First I will ask you to reproduce the problem using latest svn. > ffmeg distorts the stream different way than ffplay. this raises more > questions about quality. > > I included here also Youri because i saw that similar rtsp/rtp crappines topic > use to appear periodically. > > due to that i am disappointed at your attitude i decided to unsubscribe from > this list. (so you are welcome to not reply) I've no doubt that you have great professional skills in audio video and network protocols, and I'm really sad to hear that you do not wish to participate in the efforts. Feel free to come back later if you change your mind. I'm a bit sad concerning your communication skills and tone, but this will certainly improve in the future. Best regards. PS: the practice of top-posting is not welcome on this mailing list. Thanks of your understanding. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |
From: Krzysztof B. <kb...@sy...> - 2009-06-16 08:03:14
Attachments:
1.log
|
On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: > Mr Błaszkowski, > > Krzysztof Błaszkowski wrote: > > Hello Mr Coudurier, > > > > I think it is pointless to continue this thread because: > > 1) it is said that someone who wrote rtsp/rtp doesn't understand own > > work. > > I'm not aware of this, but may I ask you what these claims are based on ? because of 2) and ffmpeg and ffplay operation differences. i think it is enough. > > > 2) there are other frameworks which use avcodecs and work well. > > That's possible indeed. > > > I do have many objections about ffplay and ffmpeg log quality and thus > > quality of code. apparently theirs authors miss some good kernel coding > > experience. > > FFmpeg is nowhere related to kernel, so I'm confused. it doesn't matter. good programming practice is always welcome (doesn't matter it was gained on Linux kernel coding, embedded systems or anything else). > Log quality may > certainly be improved, however, and patches improving this is welcome as > usual. so do it yourself. add timestamps, function names, line numbers, thread pids. (design some graceful logging system - it is possible) so everyone outside of ffmpeg will be able to recognize as quick as he can what's going on. i do not have time for cleaning this mess after you. example in attachment. > > > also i reckon that console output of ffmpeg is useless. if i were you i > > would ask rather for some ethernet capture file with that rtsp/rtp > > session but you revealed rather lack of professional skills. > > Console output of FFmpeg is usefull for 2 things: > - Knowing what version you are using > - Knowing what kind of stream it is > > I obtained these informations. i wrote i use ffmpeg-0.5 tarball, didn't i ? > Now about the ethernet capture file, that > may certainly be useful, but in a second step. > you will need to ask someone else. > First I will ask you to reproduce the problem using latest svn. sorry, too late. > > > ffmeg distorts the stream different way than ffplay. this raises more > > questions about quality. > > > > I included here also Youri because i saw that similar rtsp/rtp crappines > > topic use to appear periodically. > > > > due to that i am disappointed at your attitude i decided to unsubscribe > > from this list. (so you are welcome to not reply) > > I've no doubt that you have great professional skills in audio video and > network protocols, i do not have professional skills in audio neither video but mainly networking and Linux storage (scsi) also generic coding. So i treat codecs like a blackboxes, i need to feed right data and receive what i want e.g. yuv420. > and I'm really sad to hear that you do not wish to > participate in the efforts. mainly i need to focus on my work. i think i can't afford for playing with ffmpeg for fun and i'm not going to pretend i know everything. > Feel free to come back later if you change > your mind. it is not going to happen. i made a decision. > I'm a bit sad concerning your communication skills and tone, > but this will certainly improve in the future. > > Best regards. > > PS: the practice of top-posting is not welcome on this mailing list. > Thanks of your understanding. actually my tone is a response to lack of your reply for a week. which i consider simply offensive. I will not reply to any following posts. Krzysztof Blaszkowski |
From: Baptiste C. <bap...@gm...> - 2009-06-16 08:24:18
|
On Tue, Jun 16, 2009 at 10:03:03AM +0200, Krzysztof B??aszkowski wrote: > On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: > > Mr B??aszkowski, > > > > Krzysztof B??aszkowski wrote: > > > Hello Mr Coudurier, > > > > > > I think it is pointless to continue this thread because: > > > 1) it is said that someone who wrote rtsp/rtp doesn't understand own > > > work. > > > > I'm not aware of this, but may I ask you what these claims are based on ? > > because of 2) and ffmpeg and ffplay operation differences. > i think it is enough. FFplay and FFmpeg are operating quite differently, and others applications using libavformat as well. Secondly operational differences are definitely not an argument to claim what you just said. > > > > > 2) there are other frameworks which use avcodecs and work well. > > > > That's possible indeed. > > > > > I do have many objections about ffplay and ffmpeg log quality and thus > > > quality of code. apparently theirs authors miss some good kernel coding > > > experience. > > > > FFmpeg is nowhere related to kernel, so I'm confused. > > it doesn't matter. good programming practice is always welcome (doesn't matter > it was gained on Linux kernel coding, embedded systems or anything else). Exactly my point. > > Log quality may > > certainly be improved, however, and patches improving this is welcome as > > usual. > > so do it yourself. add timestamps, function names, line numbers, thread pids. > (design some graceful logging system - it is possible) so everyone outside of > ffmpeg will be able to recognize as quick as he can what's going on. > > i do not have time for cleaning this mess after you. > > example in attachment. Well, what you pasted is clearly hard to decipher, so I don't consider this good log quality. We disagree on this point, not that I pretend that FFmpeg logs are good quality. > > > > > also i reckon that console output of ffmpeg is useless. if i were you i > > > would ask rather for some ethernet capture file with that rtsp/rtp > > > session but you revealed rather lack of professional skills. > > > > Console output of FFmpeg is usefull for 2 things: > > - Knowing what version you are using > > - Knowing what kind of stream it is > > > > I obtained these informations. > > i wrote i use ffmpeg-0.5 tarball, didn't i ? There were 2 points, didn't you read ? > > > [...] > > > > > > ffmeg distorts the stream different way than ffplay. this raises more > > > questions about quality. > > > > > > I included here also Youri because i saw that similar rtsp/rtp crappines > > > topic use to appear periodically. > > > > > > due to that i am disappointed at your attitude i decided to unsubscribe > > > from this list. (so you are welcome to not reply) > > > > > > mainly i need to focus on my work. i think i can't afford for playing with > ffmpeg for fun and i'm not going to pretend i know everything. Well, consider that I need to focus on my work as well. > [...] > > > I'm a bit sad concerning your communication skills and tone, > > but this will certainly improve in the future. > > > > Best regards. > > > > PS: the practice of top-posting is not welcome on this mailing list. > > Thanks of your understanding. > > actually my tone is a response to lack of your reply for a week. which i > consider simply offensive. > Well your answer was clearly rude and exaggerated IMHO. We are all benevolent on FFmpeg, nobody is paid to develop it full time. Believe that I'm sorry about that. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |
From: Krzysztof B. <kb...@sy...> - 2009-06-16 09:15:17
|
On Tuesday 16 June 2009 10:24, Baptiste Coudurier wrote: > On Tue, Jun 16, 2009 at 10:03:03AM +0200, Krzysztof B??aszkowski wrote: > > On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: > > > Mr B??aszkowski, > > > > > > Krzysztof B??aszkowski wrote: > > > > Hello Mr Coudurier, > > > > > > > > I think it is pointless to continue this thread because: > > > > 1) it is said that someone who wrote rtsp/rtp doesn't understand own > > > > work. > > > > > > I'm not aware of this, but may I ask you what these claims are based on > > > ? > > > > because of 2) and ffmpeg and ffplay operation differences. > > i think it is enough. > > FFplay and FFmpeg are operating quite differently, and others > applications using libavformat as well. > Secondly operational differences are definitely not an argument to > claim what you just said. damn, they should produce same output ? right ? ffplay should not show some distortions after 30 secs of playing rtsp source, isn't it ? ffmpeg should not "degrade resultion" as time goes on in output, right ? the ffmpeg recorded streams were looking like with downsampled resolution at the end but beginning was okay. are you slightly smart different way ? (i want to avoid a word like "idiot" as much as possible) > > > > > 2) there are other frameworks which use avcodecs and work well. > > > > > > That's possible indeed. > > > > > > > I do have many objections about ffplay and ffmpeg log quality and > > > > thus quality of code. apparently theirs authors miss some good kernel > > > > coding experience. > > > > > > FFmpeg is nowhere related to kernel, so I'm confused. > > > > it doesn't matter. good programming practice is always welcome (doesn't > > matter it was gained on Linux kernel coding, embedded systems or anything > > else). > > Exactly my point. no, you didn't catch this. > > > > Log quality may > > > certainly be improved, however, and patches improving this is welcome > > > as usual. > > > > so do it yourself. add timestamps, function names, line numbers, thread > > pids. (design some graceful logging system - it is possible) so everyone > > outside of ffmpeg will be able to recognize as quick as he can what's > > going on. > > > > i do not have time for cleaning this mess after you. > > > > example in attachment. > > Well, what you pasted is clearly hard to decipher, so I don't consider this > good log quality. We disagree on this point, not that I pretend that > FFmpeg logs are good quality. have you ever seen the scst code ? so why do you claim that ENTRY/EXIT function name is less readable than "[stream %p] MV %d errors" produced by ffplay ? now, i'm really upset. I do have very short patience to any kind of silliness. (again i don't want to use more accurate words) > > > > > also i reckon that console output of ffmpeg is useless. if i were you > > > > i would ask rather for some ethernet capture file with that rtsp/rtp > > > > session but you revealed rather lack of professional skills. > > > > > > Console output of FFmpeg is usefull for 2 things: > > > - Knowing what version you are using > > > - Knowing what kind of stream it is > > > > > > I obtained these informations. > > > > i wrote i use ffmpeg-0.5 tarball, didn't i ? > > There were 2 points, didn't you read ? i told already it was mpeg4 > > > > > [...] > > > > > > > > ffmeg distorts the stream different way than ffplay. this raises more > > > > questions about quality. > > > > > > > > I included here also Youri because i saw that similar rtsp/rtp > > > > crappines topic use to appear periodically. > > > > > > > > due to that i am disappointed at your attitude i decided to > > > > unsubscribe from this list. (so you are welcome to not reply) > > > > mainly i need to focus on my work. i think i can't afford for playing > > with ffmpeg for fun and i'm not going to pretend i know everything. > > Well, consider that I need to focus on my work as well. > > > [...] > > > > > I'm a bit sad concerning your communication skills and tone, > > > but this will certainly improve in the future. > > > > > > Best regards. > > > > > > PS: the practice of top-posting is not welcome on this mailing list. > > > Thanks of your understanding. > > > > actually my tone is a response to lack of your reply for a week. which i > > consider simply offensive. > > Well your answer was clearly rude and exaggerated IMHO. surely it is. > > We are all benevolent on FFmpeg, nobody is paid to develop it full > time. Believe that I'm sorry about that. I know why you can't enjoy money from your work. if you looked through whole thread you would know too. and GPL (or LGPL) doesn't mean profitless. > > [...] |
From: Baptiste C. <bap...@gm...> - 2009-06-16 21:38:33
|
On 6/16/2009 2:13 AM, Krzysztof Błaszkowski wrote: > On Tuesday 16 June 2009 10:24, Baptiste Coudurier wrote: >> On Tue, Jun 16, 2009 at 10:03:03AM +0200, Krzysztof B??aszkowski wrote: >>> On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: >>>> Mr B??aszkowski, >>>> >>>> Krzysztof B??aszkowski wrote: >>>>> Hello Mr Coudurier, >>>>> >>>>> I think it is pointless to continue this thread because: >>>>> 1) it is said that someone who wrote rtsp/rtp doesn't understand own >>>>> work. >>>> I'm not aware of this, but may I ask you what these claims are based on >>>> ? >>> because of 2) and ffmpeg and ffplay operation differences. >>> i think it is enough. >> FFplay and FFmpeg are operating quite differently, and others >> applications using libavformat as well. >> Secondly operational differences are definitely not an argument to >> claim what you just said. > > > damn, they should produce same output ? Ideally yes, but there are bugs in FFplay that doesn't occur in FFmpeg. That's true. > ffplay should not show some distortions after 30 secs of playing rtsp source, > isn't it ? No it shouldn't, that's a bug. > ffmpeg should not "degrade resultion" as time goes on in output, right ? > the ffmpeg recorded streams were looking like with downsampled > resolution at the end but beginning was okay. No it shouldn't, that's a bug. You said: 1) it is said that someone who wrote rtsp/rtp doesn't understand own work. Can you please mention on what this are based on ? I think the one who wrote rtsp/rtp code did understand rtp/rtsp a bit at least. It seems to work in some ways too, but it's not working for your case I'm afraid and this must be fixed. >>>>> [...] >>>>> >>>>> 2) there are other frameworks which use avcodecs and work well. >>>> That's possible indeed. >>>> >>>>> I do have many objections about ffplay and ffmpeg log quality and >>>>> thus quality of code. apparently theirs authors miss some good kernel >>>>> coding experience. >>>> FFmpeg is nowhere related to kernel, so I'm confused. >>> it doesn't matter. good programming practice is always welcome (doesn't >>> matter it was gained on Linux kernel coding, embedded systems or anything >>> else). >> Exactly my point. > > no, you didn't catch this. Of course I did, it doesn't matter if it's kernel coding or something else. >>>> Log quality may >>>> certainly be improved, however, and patches improving this is welcome >>>> as usual. >>> so do it yourself. add timestamps, function names, line numbers, thread >>> pids. (design some graceful logging system - it is possible) so everyone >>> outside of ffmpeg will be able to recognize as quick as he can what's >>> going on. >>> >>> i do not have time for cleaning this mess after you. >>> >>> example in attachment. >> Well, what you pasted is clearly hard to decipher, so I don't consider this >> good log quality. We disagree on this point, not that I pretend that >> FFmpeg logs are good quality. > > have you ever seen the scst code ? Are we talking about log quality here or code quality ? > so why do you claim that ENTRY/EXIT function name is less readable than > "[stream %p] MV %d errors" produced by ffplay ? > > now, i'm really upset. I didn't claim this: "not that I pretend that FFmpeg logs are good quality.", anything I can say so it is understood better ? > I do have very short patience to any kind of silliness. (again i don't want to > use more accurate words) Fortunately for me I have a lot of patience when dealing with this. >>>>> also i reckon that console output of ffmpeg is useless. if i were you >>>>> i would ask rather for some ethernet capture file with that rtsp/rtp >>>>> session but you revealed rather lack of professional skills. >>>> Console output of FFmpeg is usefull for 2 things: >>>> - Knowing what version you are using >>>> - Knowing what kind of stream it is >>>> >>>> I obtained these informations. >>> i wrote i use ffmpeg-0.5 tarball, didn't i ? >> There were 2 points, didn't you read ? > > i told already it was mpeg4 You said also: "i do not have professional skills in audio neither video but mainly networking and Linux storage (scsi) also generic coding. So i treat codecs like a blackboxes" Many people tend to refer mpeg4 as different things. FFmpeg output guarantee that what you say is correct. >>>>> [...] >>>>> >>>>> ffmeg distorts the stream different way than ffplay. this raises more >>>>> questions about quality. >>>>> >>>>> I included here also Youri because i saw that similar rtsp/rtp >>>>> crappines topic use to appear periodically. >>>>> >>>>> due to that i am disappointed at your attitude i decided to >>>>> unsubscribe from this list. (so you are welcome to not reply) >>> mainly i need to focus on my work. i think i can't afford for playing >>> with ffmpeg for fun and i'm not going to pretend i know everything. >> Well, consider that I need to focus on my work as well. >> >>> [...] >>> >>>> I'm a bit sad concerning your communication skills and tone, >>>> but this will certainly improve in the future. >>>> >>>> Best regards. >>>> >>>> PS: the practice of top-posting is not welcome on this mailing list. >>>> Thanks of your understanding. >>> actually my tone is a response to lack of your reply for a week. which i >>> consider simply offensive. >> Well your answer was clearly rude and exaggerated IMHO. > > surely it is. > >> We are all benevolent on FFmpeg, nobody is paid to develop it full >> time. Believe that I'm sorry about that. > > I know why you can't enjoy money from your work. if you looked through whole > thread you would know too. I don't think so. OTOH please refrain from making false statement based on hypothesis when you clearly don't have any clue about how things are handled. > and GPL (or LGPL) doesn't mean profitless. That's definitely true, and you don't what's going on around here, do you ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |
From: Krzysztof B. <kb...@sy...> - 2009-06-17 15:11:28
|
On Tuesday 16 June 2009 23:38, Baptiste Coudurier wrote: > On 6/16/2009 2:13 AM, Krzysztof Błaszkowski wrote: > > On Tuesday 16 June 2009 10:24, Baptiste Coudurier wrote: > >> On Tue, Jun 16, 2009 at 10:03:03AM +0200, Krzysztof B??aszkowski wrote: > >>> On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: > >>>> Mr B??aszkowski, > >>>> > >>>> Krzysztof B??aszkowski wrote: > >>>>> Hello Mr Coudurier, > >>>>> > >>>>> I think it is pointless to continue this thread because: > >>>>> 1) it is said that someone who wrote rtsp/rtp doesn't understand own > >>>>> work. > >>>> > >>>> I'm not aware of this, but may I ask you what these claims are based > >>>> on ? > >>> > >>> because of 2) and ffmpeg and ffplay operation differences. > >>> i think it is enough. > >> > >> FFplay and FFmpeg are operating quite differently, and others > >> applications using libavformat as well. > >> Secondly operational differences are definitely not an argument to > >> claim what you just said. > > > > damn, they should produce same output ? > > Ideally yes, but there are bugs in FFplay that doesn't occur in FFmpeg. > That's true. > > > ffplay should not show some distortions after 30 secs of playing rtsp > > source, isn't it ? > > No it shouldn't, that's a bug. > > > ffmpeg should not "degrade resultion" as time goes on in output, right ? > > the ffmpeg recorded streams were looking like with downsampled > > resolution at the end but beginning was okay. > > No it shouldn't, that's a bug. > > You said: > 1) it is said that someone who wrote rtsp/rtp doesn't understand own > work. > > Can you please mention on what this are based on ? > > I think the one who wrote rtsp/rtp code did understand rtp/rtsp a bit at > least. It seems to work in some ways too, but it's not working for your > case I'm afraid and this must be fixed. okay. but i will not help with this. i was thinking that if there are so many bugs in ffplay and ffmpeg then maybe these tools should be rewritten from scratch. further patches may introduce more bugs. i reckon also that there must be general design bug because these tools don't use some common engine and that's why they work different and neither ffplay neither ffmpeg work right. <snip> > > >> > >> Well, what you pasted is clearly hard to decipher, so I don't consider > >> this good log quality. We disagree on this point, not that I pretend > >> that FFmpeg logs are good quality. > > > > have you ever seen the scst code ? > > Are we talking about log quality here or code quality ? code quality means also right logging. anyway i agree that's this is offtopic. > > > so why do you claim that ENTRY/EXIT function name is less readable than > > "[stream %p] MV %d errors" produced by ffplay ? > > > > > > surely it is. > > > >> We are all benevolent on FFmpeg, nobody is paid to develop it full > >> time. Believe that I'm sorry about that. > > > > I know why you can't enjoy money from your work. if you looked through > > whole thread you would know too. > > I don't think so. OTOH please refrain from making false statement based > on hypothesis when you clearly don't have any clue about how things are > handled. better be more sensible and responsive. > > > and GPL (or LGPL) doesn't mean profitless. > > That's definitely true, and you don't what's going on around here, do you ? anyway such issues fixing "strategy" like i saw is not accepted by industry. of course i may be wrong. anyway what you will do or not do it doesn't matter to me again. Regards, Krzysztof Blaszkowski |
From: Baptiste C. <bap...@gm...> - 2009-06-17 20:30:40
|
On 6/17/2009 8:11 AM, Krzysztof Błaszkowski wrote: > On Tuesday 16 June 2009 23:38, Baptiste Coudurier wrote: >> On 6/16/2009 2:13 AM, Krzysztof Błaszkowski wrote: >>> On Tuesday 16 June 2009 10:24, Baptiste Coudurier wrote: >>>> On Tue, Jun 16, 2009 at 10:03:03AM +0200, Krzysztof B??aszkowski wrote: >>>>> On Monday 15 June 2009 23:13, Baptiste Coudurier wrote: >>>>>> Mr B??aszkowski, >>>>>> >>>>>> Krzysztof B??aszkowski wrote: >>>>>>> Hello Mr Coudurier, >>>>>>> >>>>>>> I think it is pointless to continue this thread because: >>>>>>> 1) it is said that someone who wrote rtsp/rtp doesn't understand own >>>>>>> work. >>>>>> I'm not aware of this, but may I ask you what these claims are based >>>>>> on ? >>>>> because of 2) and ffmpeg and ffplay operation differences. >>>>> i think it is enough. >>>> FFplay and FFmpeg are operating quite differently, and others >>>> applications using libavformat as well. >>>> Secondly operational differences are definitely not an argument to >>>> claim what you just said. >>> damn, they should produce same output ? >> Ideally yes, but there are bugs in FFplay that doesn't occur in FFmpeg. >> That's true. >> >>> ffplay should not show some distortions after 30 secs of playing rtsp >>> source, isn't it ? >> No it shouldn't, that's a bug. >> >>> ffmpeg should not "degrade resultion" as time goes on in output, right ? >>> the ffmpeg recorded streams were looking like with downsampled >>> resolution at the end but beginning was okay. >> No it shouldn't, that's a bug. >> >> You said: >> 1) it is said that someone who wrote rtsp/rtp doesn't understand own >> work. >> >> Can you please mention on what this are based on ? >> >> I think the one who wrote rtsp/rtp code did understand rtp/rtsp a bit at >> least. It seems to work in some ways too, but it's not working for your >> case I'm afraid and this must be fixed. > > > okay. but i will not help with this. Again this is your choice, sad, but your choice. > i was thinking that if there are so many bugs in ffplay and ffmpeg then maybe > these tools should be rewritten from scratch. further patches may introduce > more bugs. Well, there are some bugs, definitely. However it seems FFmpeg work quite well for Youtube and Facebook and many more so far, so I really don't think they need to be rewritten. > i reckon also that there must be general design bug because these tools don't > use some common engine and that's why they work different and neither ffplay > neither ffmpeg work right. FFmpeg is a transcoder, FFplay is a player, the requisite are not the same nor the strategy. Furtheremore, FFplay is a very simple video player, nothing advanced nor robust. But I reckon you have very good experience in audio and video domain. >>> [...] >>> >>>> We are all benevolent on FFmpeg, nobody is paid to develop it full >>>> time. Believe that I'm sorry about that. >>> I know why you can't enjoy money from your work. if you looked through >>> whole thread you would know too. >> I don't think so. OTOH please refrain from making false statement based >> on hypothesis when you clearly don't have any clue about how things are >> handled. > > better be more sensible and responsive. Am I not answering to you ? I think I am. Concerning bug reports, well it's done when developpers have time, like I said. We all have full time day jobs also. >>> and GPL (or LGPL) doesn't mean profitless. >> That's definitely true, and you don't what's going on around here, do you ? > > anyway such issues fixing "strategy" like i saw is not accepted by industry. > of course i may be wrong. Yes, you are wrong, and you don't know what's going on around here. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org |