Re: [FFmpeg-soc] ac3enc merge
Hi Justin, On 12/14/2010 07:20 AM, Justin Ruggles wrote: On 12/11/2010 11:40 AM, Justin Ruggles wrote: Hi, I'm going to go ahead and start merging some of the AC3 encoder changes I've been working on in my git tree. For larger changes that might be controversial, I'll post patches on ffmpeg-devel. For example, the per-codec options for metadata and how the floating-point/fixed-point split was handled. Both of those could be done in different ways; I just went with what I thought was the best approach. It would be good to get some input though before committing them to SVN. Plus there are some regression test and configure changes in there that need review. The huge set of commits I just made were mostly cosmetic-ish (cosmetics, moving code around, etc...). Next round will be more focused on speed improvements, memory usage improvements, and other optimizations. Very nice, keep up the good work. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5841 - libavfilter/vf_overlay.c
On 6/20/10 4:52 PM, Stefano Sabatini wrote: On date Sunday 2010-06-20 16:31:19 -0700, Baptiste Coudurier encoded: On 6/20/10 4:27 PM, stefano wrote: Author: stefano Date: Mon Jun 21 01:27:14 2010 New Revision: 5841 Log: Revert commit: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Fix movie in movie and ffplay overlaying with static images, ffplay movie in movie filtering is still borken. This is false, ffplay works here with static images, _your_ setup is broken. I could have expressed it better, what is not working is overlay with a dynamic movie: ffplay -vf "movie=0:flv:slow.flv, scale=100:-1 [overlay]; [in][overlay] overlay" slow.flv A black rectangle is overlayed. Yes, the first frame is overlayed, read the code... -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5841 - libavfilter/vf_overlay.c
On 6/20/10 4:27 PM, stefano wrote: Author: stefano Date: Mon Jun 21 01:27:14 2010 New Revision: 5841 Log: Revert commit: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Fix movie in movie and ffplay overlaying with static images, ffplay movie in movie filtering is still borken. This is false, ffplay works here with static images, _your_ setup is broken. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/9/10 4:49 PM, Baptiste Coudurier wrote: On 06/09/2010 03:22 PM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. This broke movie in movie. Yes, I mentioned this in the commit log :) Again, please *don't* make massive changes and introduce regressions without not even posting and discussing the changes before, testing with ffplay is a bonus. Consider to fix the regression or revert the patch if you can't do it in a reasonable amount of time, or at least try to justify because this change should be an improvement over the previous behaviour. Besides, I believe you are overreacting here. If you can't realize why direct rendering is way better that what was in before, I can't help you. And if you had reviewed the filter you would have seen that there is a commented test about pts which would fetch the next frame from the overlayed source. My comment about loop input is pretty clear, if you actually read the code... If you overlay a logo, you want the input to loop, if you are overlayed a video, you don't want the last frame to loop. Besides the previous code with pts was weird, the output pts should always be the main video pts AFAIU. I'd appreciate if people could actually review the changes and make constructive comments. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 06/09/2010 03:22 PM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. This broke movie in movie. Yes, I mentioned this in the commit log :) Again, please *don't* make massive changes and introduce regressions without not even posting and discussing the changes before, testing with ffplay is a bonus. Consider to fix the regression or revert the patch if you can't do it in a reasonable amount of time, or at least try to justify because this change should be an improvement over the previous behaviour. Feel free to revert the commit, that's fine with me. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file
On 06/09/2010 02:35 PM, Víctor Paesa wrote: Hi, On 2010-06-09, Stefano Sabatini wrote: On date Wednesday 2010-06-09 03:00:05 -0700, Baptiste Coudurier encoded: On 5/11/10 3:39 PM, Baptiste Coudurier wrote: On 05/11/2010 03:18 PM, Stefano Sabatini wrote: On date Wednesday 2010-05-12 00:10:28 +0200, Vitor Sessak encoded: Víctor Paesa wrote: Hi On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote: Baptiste Coudurier wrote: Guys, What do you think about it ? Looks a good idea to me, unless someone comes up with an even better name. Well, strictly speaking, not only files are supported. But for me "file" is still the least misleading. For example, in "ffmpeg -h": -i filename input file name We already call [file|URL|video4windows device number] a "file"... Exactly. What we're really taking in input is a lavf resource/source/stream. Maybe vsrc_stream, but I continue to prefer "lavf" as it is using the lavf syntax/capabilities. I think users don't really know about lavf, it won't be obvious for them at all... So, victor, stefano ? Do we agree on a name or ? Michael what do you think ? My preferences (in order) are: * vsrc_movie -> keeping the original name saves some effort * vsrc_media -> "multimedia" is more descriptive, but too long. "media" is an acceptable (for me) compromise. All right, then I guess we keep the same name. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file
On 5/11/10 3:39 PM, Baptiste Coudurier wrote: On 05/11/2010 03:18 PM, Stefano Sabatini wrote: On date Wednesday 2010-05-12 00:10:28 +0200, Vitor Sessak encoded: Víctor Paesa wrote: Hi On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote: Baptiste Coudurier wrote: Guys, What do you think about it ? Looks a good idea to me, unless someone comes up with an even better name. Well, strictly speaking, not only files are supported. But for me "file" is still the least misleading. For example, in "ffmpeg -h": -i filename input file name We already call [file|URL|video4windows device number] a "file"... Exactly. What we're really taking in input is a lavf resource/source/stream. Maybe vsrc_stream, but I continue to prefer "lavf" as it is using the lavf syntax/capabilities. I think users don't really know about lavf, it won't be obvious for them at all... So, victor, stefano ? Do we agree on a name or ? Michael what do you think ? Can you guys please review vsrc_movie.c ? It would be nice to have overlay in svn. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/8/10 4:00 PM, Stefano Sabatini wrote: On date Tuesday 2010-06-08 15:21:07 -0700, Baptiste Coudurier encoded: On 6/5/10 4:19 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded: On 6/5/10 2:33 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded: Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] overlay=10:main_h-overlay_h-10:1 [out]" slow.flv and sorry for the rude reply, now I see that you test only with ffmpeg and not with ffplay (also the fade filter has serious problems when used with ffplay). That's ok, it seems you improperly translated to the new API. 100l to me. It works fine here now. Anyway the problem is another one, try with a MPEG video based codec and you should see. What I'm observing is that the overlay is applied to the source filter *before* the motion compensation, the (weird|funny) result is that the logo tends to stain the image sort-alike ink as the video scrolls. Stefano, do you still have the issue ? I believe the overlay filter should be commited to svn. Michael, could you please review it ? Or do you want me to send it to ffmpeg-devel ? Yes, the problem depends on the ffplay implementation (which doesn't rely on av_vsrc_buffer), I still didn't looked at it, that for sure should be addressed before to commit it to SVN. Hummm, did you make sure you applied the 2 modifications I applied to vsrc_movie ? Also please post the patch anyway, there are some points I want to address in the review (mainly trivial stuff). Can you please address them here ? :) Besides, overlay is useless without vsrc_movie. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/5/10 4:19 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded: On 6/5/10 2:33 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded: Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] overlay=10:main_h-overlay_h-10:1 [out]" slow.flv and sorry for the rude reply, now I see that you test only with ffmpeg and not with ffplay (also the fade filter has serious problems when used with ffplay). That's ok, it seems you improperly translated to the new API. 100l to me. It works fine here now. Anyway the problem is another one, try with a MPEG video based codec and you should see. What I'm observing is that the overlay is applied to the source filter *before* the motion compensation, the (weird|funny) result is that the logo tends to stain the image sort-alike ink as the video scrolls. Stefano, do you still have the issue ? I believe the overlay filter should be commited to svn. Michael, could you please review it ? Or do you want me to send it to ffmpeg-devel ? -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/5/10 4:30 PM, Baptiste Coudurier wrote: On 6/5/10 4:19 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded: On 6/5/10 2:33 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded: Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] overlay=10:main_h-overlay_h-10:1 [out]" slow.flv and sorry for the rude reply, now I see that you test only with ffmpeg and not with ffplay (also the fade filter has serious problems when used with ffplay). That's ok, it seems you improperly translated to the new API. 100l to me. It works fine here now. Anyway the problem is another one, try with a MPEG video based codec and you should see. What I'm observing is that the overlay is applied to the source filter *before* the motion compensation, the (weird|funny) result is that the logo tends to stain the image sort-alike ink as the video scrolls. It's work here, I bet you don't have the fixes to vsrc_buffer, it's broken currently. vsrc_movie as well. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/5/10 4:19 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded: On 6/5/10 2:33 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded: Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] overlay=10:main_h-overlay_h-10:1 [out]" slow.flv and sorry for the rude reply, now I see that you test only with ffmpeg and not with ffplay (also the fade filter has serious problems when used with ffplay). That's ok, it seems you improperly translated to the new API. 100l to me. It works fine here now. Anyway the problem is another one, try with a MPEG video based codec and you should see. What I'm observing is that the overlay is applied to the source filter *before* the motion compensation, the (weird|funny) result is that the logo tends to stain the image sort-alike ink as the video scrolls. It's work here, I bet you don't have the fixes to vsrc_buffer, it's broken currently. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On 6/5/10 2:33 PM, Stefano Sabatini wrote: On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded: Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] overlay=10:main_h-overlay_h-10:1 [out]" slow.flv and sorry for the rude reply, now I see that you test only with ffmpeg and not with ffplay (also the fade filter has serious problems when used with ffplay). That's ok, it seems you improperly translated to the new API. It works fine here now. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
Hi Stefano, On 6/5/10 6:38 AM, Stefano Sabatini wrote: On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded: Author: bcoudurier Date: Fri Jun 4 22:15:35 2010 New Revision: 5821 Log: Direct rendering in overlay filter. RGB24 support. Doesn't work with movie in movie yet, needs loop input feature for logos either in movie filter or here. Overlay filter is now badly broken in a weird funny way. May I ask you to avoid to commit features which cause regressions? What's broken exactly ? -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5804 - libavfilter/vsrc_movie.c
On 5/19/10 5:02 AM, Vitor Sessak wrote: On 05/19/2010 05:15 AM, bcoudurier wrote: Author: bcoudurier Date: Wed May 19 05:15:27 2010 New Revision: 5804 Log: actually copy the picture in vsrc movie, it cannot be taken from decode_video like this Can you elaborate? I tried very hard to avoid any picture copying because Michael consider them a no-go in main SVN... You cannot request a buffer from the next filter using get_video_buffer and changing it before sending it to that filter. This is broken for the pad filter at least. If you want to avoid any picture copying you have to override AVCodecContext->get_buffer and reget_buffer by new functions that use get_video_buffer. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On 5/17/10 4:59 AM, S.N. Hemanth Meenakshisundaram wrote: On 05/16/2010 09:10 AM, Stefano Sabatini wrote: On date Tuesday 2010-05-11 01:12:37 +0200, Stefano Sabatini encoded: On date Monday 2010-05-10 15:52:18 -0700, S.N. Hemanth Meenakshisundaram encoded: On 05/10/2010 03:14 PM, Stefano Sabatini wrote: On date Sunday 2010-05-09 20:42:30 -0700, S.N. Hemanth Meenakshisundaram encoded: On 05/03/2010 01:32 PM, Stefano Sabatini wrote: On date Monday 2010-05-03 01:11:07 -0700, S.N. Hemanth Meenakshisundaram encoded: On 04/23/2010 05:03 PM, Stefano Sabatini wrote: On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth Meenakshisundaram encoded: [...] + /* FIXME: av_parse_color currently sets alpha to 0 if no alpha is specified. + * So we force alpha = 0xFF (opaque), here in such a case. + */ + if (rgba[3] != 0) + color[3] = rgba[3]; + else + color[3] = 0xFF; I suppose this was to be skipped. If I skip this without the parseutils patch, then text specified will be invisible (alpha 0) by default when user specifies foreground color as an english string. So I left it in for the time being. Will remove it along with parseutils patch. Hope that's ok. Fine. Did you already thought about a syntax? My idea was: color/0xXX color/DDD maybe someone which works with web/design can suggest a more familiar/natural syntax though. Apart those nits patch looks fine to me (but missing configure and documentation parts), I assume it has been tested and works. Done. Other nits fixed and the redundant fixme removed. Tested and works. Please provide the complete patch. vf_drawtext.c, allfilter.c and libavfilter Makefile changes are all part of drawtext.diff which is a patch against soc/libavfilter (svn diff ./ in soc/libavfilter directory) There's no configure in soc/libavfilter, so config.diff is a patch against ffmpeg trunk. Should this be in some other form? drawtext_doc.diff is a diff with libavfilter.texi of ffmpeg trunk after it has been patched by the checkout.sh script in soc/libavfilter. I can make this a patch to the 03_libavfilter_doc.diff file in soc/libavfilter if required. No patch is OK, I think that I'll add a configure patch to soc too. If no one else has other comments I'll apply the patch to soc in few days. I had to edit the patch before to apply, there were different warnings and a problem with the strftime() expansion rendering (only the characters in the provided string where loaded in init(), that couldn't work when the string was expanded), please test more accurately the next time and never ignore warnings. I saw the changes you made. I will keep those in mind when submitting my next patch and run more tests. Also I changed the way the filter is configured, with the applied patch the --enable-libfreetype switch is required to compile the drawtext filter. That looks simpler and consistent with the way configure deals with external libraries. As for what regards the filter: the outline quality is honestly quite bad especially at small font sizes, while I really appreciate the font/box transparency feature :-). Also maybe we should try to add anti-aliasing support. For anti-aliasing, I will set the freetype2 anti-aliasing flags on. As for outline, I guess the algorithm needs to be changed. I will work on these once I have gotten some of the audio filter framework done this week. I plan to work on this as well. Btw, wouldn't it look better if you render in GRAY8 ? Then you use it as alpha to blend the foreground. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
Hi, On 05/12/2010 02:33 PM, Michael Niedermayer wrote: On Wed, May 12, 2010 at 09:00:46AM +0200, Vitor Sessak wrote: Baptiste Coudurier wrote: On 12/06/2009 08:12 AM, Vitor Sessak wrote: Hi and sorry for the delay. Artur Bodera wrote: On Tue, Dec 1, 2009 at 12:50 AM, Vitor Sessak wrote: While I normally oppose making non-committed code more complex, I think this feature is so often requested that it is worth the extra work in the future. Stefano, Michael, any strong opinion about this? I think the vf_overlay should be modified altogether. Although mathematically alpha-blending is more expensive than opaque pixel replacement, I think that it should be automatically decided by analyzing the overlay format. So the alpha-blending should be a "built-in" functionality (not a switchable parameter) and should be implicitly functional with any overlay stream/image that has alpha channel (i.e. rgba). If there is no alpha channel, then pixel overriding would be used. This makes much more sense. I agree that this would be nice, but there is no way to make it work with the current format negotiation in libavfilter. For example, there is no way to have a filter that accepts either "input: rgb, output rgba" or "input: yuv, output: yuva", so I suggest you just do as your present patch for the time been. How much harm does doing yuv -> yuva or rgb -> rgba in all cases ? To my knowledge it would only be a matter of adding one component and memset it to 0xff. This wouldn't do much harm, but there is no way of asking for such kind of inputs in lavfi (i.e., either "rgb,rgba" or "yuv,yuva"). And changing lavfi to accept such constraints would probably make colospace negotiation a NP problem. finding a solution with a minimum of convertion could become NP, finding any solution wont heres a quick option (i do not know how good / bad this suggestion is, if someone like loren could look at this before its implemented this would probably be a good idea) 1. we extend query_format to query_format(int alternative) where alternative selects which of several (small number normally and for most filters just 1) alternative colorspace lists each link supports. Euch such alternative is like the current case that is 2 links either must have the same list of possible pixelformats/colorspaces or they are independant. 2. we run the current avfiltergraph.c query_formats() over the graph skiping all filters that have alternatives. 3. we go over all filters that have alternatives for each such filter we find the 2 best alterantives, best based on score= (A<<32) + B; A= the number of scale filters the specific alterantive would require B= the number of degrees of freedom lost (aka fewer colorspaces) we then calculate a score2 that is the difference of the scores of the best 2 alterantives. And last lock in filter alterantives iteratively based on best score2 The idea here is that we lock in the filter with the most clearly supperior alterantive first. That is if we have a filter that has 2 alterantives and neither on its own would require an additional convertion filter and another filter that also has 2 alternatives and one of these would require 1 convertion and the other case would require 2 convertions then the 1 convertion alternative would be locked in and we would restart from the begin This is not optimal, not even for a simple linear filter chain with 2 filters. But it might be an acceptable heuristic for real filter graphs. For a single linear chain its possible to find the optimal case with viterbi Another method would be to only use avfiltergraph.c query_formats() and consider all the alternative values inputs to it and the number of convertions and degrees of freedom left over the whole graph its score. And then use some generic optimization technique that minimizes this score. btw, off topic a little but simply favoring the first colorspace in each list like its done in svn is not a good idea, it likely would make more sense to favor a colorspace that preserves all information that is there and is simple. that is if either upstream or downstream is greyscale we shouldnt select yuv similar issues exist with 16/8 bit and rgb/yuv and alpha Question, why not using a pull paradigm from the output filter ? That certainly gives an hint on what the user want at the end. This would allow the overlay filter to request RGBA as input when output is RGB, same for YUVA/YUV -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
[FFmpeg-soc] [PATCH] align overlay picture w, h, x, y to pixel format
Hi, $subject. Round up w/h of the overlay logo. I'm not 100% sure of this. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org Index: vf_overlay.c === --- vf_overlay.c (revision 5798) +++ vf_overlay.c (working copy) @@ -348,6 +348,12 @@ y = FFMIN(over->y, link->h-1); w = FFMIN(link->w-x, over->pics[1][0]->w); h = FFMIN(link->h-y, over->pics[1][0]->h); + +x &= ~((1 << over->hsub) - 1); +y &= ~((1 << over->vsub) - 1); +w = (w+((1<hsub)-1))>>over->hsub; +h = (h+((1<vsub)-1))>>over->vsub; + if(over->pics[1][0]) copy_image(pic, x, y, over->pics[1][0], w, h, over->bpp, over->hsub, over->vsub); ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5795 - libavfilter/vf_overlay.c
On 5/11/10 11:55 PM, Vitor Sessak wrote: bcoudurier wrote: Author: bcoudurier Date: Wed May 12 02:10:58 2010 New Revision: 5795 Log: remove blend parameter, request yuva as input for the overlayed file That means that now if we want to overlay two RGB pictures to get a RGB output we will do two RGB->YUV and one YUV->RGB needless conversions. I have a patch for a RGB path. Now I still need to figure how to insert a filter to rescale. The problem is the autonegociation, the input pixel formats depends on the requested output pixel format. Was it considered that the pixel format could be requested by the output ? -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
Hi Vitor,
On 12/08/2009 10:37 AM, Vitor Sessak wrote:
Stefano Sabatini wrote:
On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded:
On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
[...]
I'm fine with committing the patch to soc if tested, even better would
be to try to push the filter to the main repo. Does someone want to
volunteer for this?
A somehow tinied-up version which can be used as a base for SVN
inclusion,
Nice work!
I believe we should get rid of the blend parameter, also
the expression evaluation may stay in a successive commit.
Do you have any idea of how to get rid of it? Are you planning to
implement Michael's suggestion of calling swscale to convert one of the
inputs to the right pixel format?
A few comments...
> static int query_formats(AVFilterContext *ctx)
> {
> OverlayContext *over = ctx->priv;
>
> if (over->blend) {
> enum PixelFormat pix_fmts1[] = { PIX_FMT_YUV420P, PIX_FMT_NONE };
> enum PixelFormat pix_fmts2[] = { PIX_FMT_YUVA420P, PIX_FMT_NONE };
these can be const.
> } else {
> avfilter_default_query_formats(ctx);
Are all lavfi formats supported?
>
> static void copy_blended( uint8_t *out, int out_linesize,
> const uint8_t *in, int in_linesize,
> const uint8_t *alpha, int alpha_linesize,
> int w, int h, int hsub, int vsub)
> {
> int x, y;
>
> for (y = 0; y < h; y++) {
> uint8_t *outp = out + y * out_linesize;
> const uint8_t *inp = in + y * in_linesize;
> const uint8_t *alphap = alpha + (y<
> for (x = 0; x < w; x++) {
> *outp = (*outp * (0xff - *alphap) + *inp * *alphap) >> 8;
Looks like some rounding could be useful.
Like:
outp = (*outp * (0xff - *alphap) + *inp * *alphap + 128) >> 8;
?
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
On 12/06/2009 08:12 AM, Vitor Sessak wrote: Hi and sorry for the delay. Artur Bodera wrote: On Tue, Dec 1, 2009 at 12:50 AM, Vitor Sessak wrote: While I normally oppose making non-committed code more complex, I think this feature is so often requested that it is worth the extra work in the future. Stefano, Michael, any strong opinion about this? I think the vf_overlay should be modified altogether. Although mathematically alpha-blending is more expensive than opaque pixel replacement, I think that it should be automatically decided by analyzing the overlay format. So the alpha-blending should be a "built-in" functionality (not a switchable parameter) and should be implicitly functional with any overlay stream/image that has alpha channel (i.e. rgba). If there is no alpha channel, then pixel overriding would be used. This makes much more sense. I agree that this would be nice, but there is no way to make it work with the current format negotiation in libavfilter. For example, there is no way to have a filter that accepts either "input: rgb, output rgba" or "input: yuv, output: yuva", so I suggest you just do as your present patch for the time been. How much harm does doing yuv -> yuva or rgb -> rgba in all cases ? To my knowledge it would only be a matter of adding one component and memset it to 0xff. Libswscale should be pretty fast at doing this. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5782 - libavfilter/vf_overlay.c
On 05/01/2010 03:44 PM, stefano wrote:
Author: stefano
Date: Sun May 2 00:44:49 2010
New Revision: 5782
Log:
Make config_input_main() use pixdesc.h for computing chroma offsets
and bits per pixel, simplify.
Modified:
libavfilter/vf_overlay.c
Modified: libavfilter/vf_overlay.c
==
--- libavfilter/vf_overlay.cSun May 2 00:17:55 2010(r5781)
+++ libavfilter/vf_overlay.cSun May 2 00:44:49 2010(r5782)
@@ -26,6 +26,7 @@
#include
#include "avfilter.h"
+#include "libavutil/pixdesc.h"
#include "libavcodec/eval.h"
#include "libavutil/avstring.h"
@@ -108,28 +109,9 @@ static int config_input_main(AVFilterLin
{
OverlayContext *over = link->dst->priv;
-switch(link->format) {
-case PIX_FMT_RGB32:
-case PIX_FMT_BGR32:
-over->bpp = 4;
-break;
-case PIX_FMT_RGB24:
-case PIX_FMT_BGR24:
-over->bpp = 3;
-break;
-case PIX_FMT_RGB565:
-case PIX_FMT_RGB555:
-case PIX_FMT_BGR565:
-case PIX_FMT_BGR555:
-case PIX_FMT_GRAY16BE:
-case PIX_FMT_GRAY16LE:
-over->bpp = 2;
-break;
-default:
-over->bpp = 1;
-}
-
-avcodec_get_chroma_sub_sample(link->format,&over->hsub,&over->vsub);
+over->bpp = (av_get_bits_per_pixel(&av_pix_fmt_descriptors[link->format]) +
7)>> 3;
+over->hsub = av_pix_fmt_descriptors[link->format].log2_chroma_w;
+over->vsub = av_pix_fmt_descriptors[link->format].log2_chroma_h;
Humm this seems to break the filter.
bpp was 1 for yuv before this change, now it is 2.
bpp is used to offset x from pic->data per component, which seems not
related to the value av_get_bits_per_pixel returns.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5782 - libavfilter/vf_overlay.c
On 05/01/2010 03:44 PM, stefano wrote:
Author: stefano
Date: Sun May 2 00:44:49 2010
New Revision: 5782
Log:
Make config_input_main() use pixdesc.h for computing chroma offsets
and bits per pixel, simplify.
Modified:
libavfilter/vf_overlay.c
Modified: libavfilter/vf_overlay.c
==
--- libavfilter/vf_overlay.cSun May 2 00:17:55 2010(r5781)
+++ libavfilter/vf_overlay.cSun May 2 00:44:49 2010(r5782)
@@ -26,6 +26,7 @@
#include
#include "avfilter.h"
+#include "libavutil/pixdesc.h"
#include "libavcodec/eval.h"
#include "libavutil/avstring.h"
@@ -108,28 +109,9 @@ static int config_input_main(AVFilterLin
{
OverlayContext *over = link->dst->priv;
-switch(link->format) {
-case PIX_FMT_RGB32:
-case PIX_FMT_BGR32:
-over->bpp = 4;
-break;
-case PIX_FMT_RGB24:
-case PIX_FMT_BGR24:
-over->bpp = 3;
-break;
-case PIX_FMT_RGB565:
-case PIX_FMT_RGB555:
-case PIX_FMT_BGR565:
-case PIX_FMT_BGR555:
-case PIX_FMT_GRAY16BE:
-case PIX_FMT_GRAY16LE:
-over->bpp = 2;
-break;
-default:
-over->bpp = 1;
-}
-
-avcodec_get_chroma_sub_sample(link->format,&over->hsub,&over->vsub);
+over->bpp = (av_get_bits_per_pixel(&av_pix_fmt_descriptors[link->format]) +
7)>> 3;
+over->hsub = av_pix_fmt_descriptors[link->format].log2_chroma_w;
+over->vsub = av_pix_fmt_descriptors[link->format].log2_chroma_h;
Humm this seems to break the filter.
bpp was 1 for yuv before this change, now it is 2.
bpp is used to offset x from pic->data per component, which seems not
related to the value av_get_bits_per_pixel returns.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file
On 05/11/2010 03:18 PM, Stefano Sabatini wrote: On date Wednesday 2010-05-12 00:10:28 +0200, Vitor Sessak encoded: Víctor Paesa wrote: Hi On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote: Baptiste Coudurier wrote: Guys, What do you think about it ? Looks a good idea to me, unless someone comes up with an even better name. Well, strictly speaking, not only files are supported. But for me "file" is still the least misleading. For example, in "ffmpeg -h": -i filename input file name We already call [file|URL|video4windows device number] a "file"... Exactly. What we're really taking in input is a lavf resource/source/stream. Maybe vsrc_stream, but I continue to prefer "lavf" as it is using the lavf syntax/capabilities. I think users don't really know about lavf, it won't be obvious for them at all... -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5792 - libavfilter/vf_overlay.c
On 05/11/2010 02:55 PM, Stefano Sabatini wrote:
On date Tuesday 2010-05-11 20:41:13 +0200, bcoudurier encoded:
Author: bcoudurier
Date: Tue May 11 20:41:12 2010
New Revision: 5792
Log:
rename parameters name in vf_overlay
Modified:
libavfilter/vf_overlay.c
Modified: libavfilter/vf_overlay.c
==
--- libavfilter/vf_overlay.cTue May 11 18:02:29 2010(r5791)
+++ libavfilter/vf_overlay.cTue May 11 20:41:12 2010(r5792)
@@ -29,10 +29,10 @@
#include "libavutil/avstring.h"
static const char *var_names[] = {
-"mainW",///< width of the main video
-"mainH",///< height of the main video
-"overlayW", ///< width of the overlay video
-"overlayH", ///< height of the overlay video
+"main_w",///< width of the main video
+"main_h",///< height of the main video
+"overlay_w", ///< width of the overlay video
+"overlay_h", ///< height of the overlay video
NULL
};
Uhm please update docs.
Sorry, updated.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file
On 05/11/2010 02:55 PM, Stefano Sabatini wrote: On date Tuesday 2010-05-11 23:34:34 +0200, Víctor Paesa encoded: Hi On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote: Baptiste Coudurier wrote: Guys, What do you think about it ? Looks a good idea to me, unless someone comes up with an even better name. Well, strictly speaking, not only files are supported. Maybe "media". What about vsrc_lavf? And I posted at some point in the past a vsrc_file source, but that was doing quite a different thing. IMHO vsrc_lavf does not reflect the usage of the filter. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
[FFmpeg-soc] [RFC] rename vsrc movie to vsrc file
Guys, What do you think about it ? -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
On 2/3/10 4:55 PM, Stefano Sabatini wrote: On date Wednesday 2010-02-03 19:56:12 +0100, Stefano Sabatini encoded: On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded: On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded: Artur Bodera wrote: [...] This should save you a lot of time and you can continue to use your favorite transcoder for web video publishing! While I normally oppose making non-committed code more complex, I think this feature is so often requested that it is worth the extra work in the future. Stefano, Michael, any strong opinion about this? I'm fine with committing the patch to soc if tested, even better would be to try to push the filter to the main repo. Does someone want to volunteer for this? I'll apply the patch soon as this feature is probably the most requested for lavfi, then I'll work on a proper filter integration when the lavfi test system will be ready (I hope within a month). Applied, hope this will raise the interest of some wanna-bee contributor ;-)! Stefano, can you please apply your cleanup patch in soc svn ? I intend to work on this. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On 04/08/2010 09:09 AM, Michael Niedermayer wrote: On Thu, Apr 08, 2010 at 03:19:34PM +, Carl Eugen Hoyos wrote: Michael Niedermayer writes: If somebody works on a de-interlace filter, please use yadif as source. seconded Michael forgot to add that he agrees to re-license his (C-) code to the LGPL, concerning the MMX optimisations, Loren Merritt has to be asked. maybe we should leave it as gpl and if someone wants to use it in non FOSS he can pay me+loren+our foundation once some agreed sum for relicensing to lgpl? Good idea. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On 04/06/2010 10:29 AM, Michael Niedermayer wrote: On Tue, Apr 06, 2010 at 08:50:26AM +, Carl Eugen Hoyos wrote: S.N. Hemanth Meenakshisundaram writes: For the deinterlace filter, do we want just a vf_* wrapper for imgconvert functions or should the code be ported to the vf_deinterlace filter? If somebody works on a de-interlace filter, please use yadif as source. seconded Arf, I replied before seen this, and I agree as well. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On 04/05/2010 12:19 PM, Reimar Döffinger wrote: On Mon, Apr 05, 2010 at 08:11:26PM +0200, Stefano Sabatini wrote: On date Monday 2010-04-05 19:32:59 +0200, Reimar Döffinger encoded: On Mon, Apr 05, 2010 at 07:11:50PM +0200, Stefano Sabatini wrote: For the deinterlace filter, do we want just a vf_* wrapper for imgconvert functions or should the code be ported to the vf_deinterlace filter? It should be ported, lavfi should not depend on lavc (that is it should be usable without any libavcodec installed). Uh, any of the advanced deinterlace filters and some more of MPlayer's filters depend on lavc. I don't think Michael will accept if you propose to duplicate half the snow encoder in lavfi. So except for basic functionality I don't see that much point in avoid a dependency on lavc if it duplicates more than just a few lines of code. Yes of course some filter may depend on lavc. As for what regards the deinterlacing implemented in imgconvert.c it looked to me simple enough to not require to add a dependancy just for that, also I think that feature (as well as cropping/padding in lavc) is going to be deprecated. Sure, I don't object to your "conclusion", just the reasoning you gave seemed not quite right to me, the above seems like a better one to me. Well, yadif should be ported :) -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
[FFmpeg-soc] [PATCH] cosmetics, rename variable, parenthese placement
Hi guys
$subject.
What was the decision for passing options to scaler ?
Btw, people might want to hook another scaler and use it to "auto
scale", so it seems needed to choose a generic and simple way.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
--- ../diffs/02_ffmpeg_filters.diff 2010-04-01 12:12:01.023337425 -0700
+++ ../diffs/02_ffmpeg_filters_2.diff 2010-04-01 12:38:43.053299288 -0700
@@ -22,7 +22,7 @@ Index: ffmpeg.c
static int qp_hist = 0;
+#if CONFIG_AVFILTER
+static char *vfilters = NULL;
-+AVFilterGraph *filt_graph_all = NULL;
++AVFilterGraph *graph = NULL;
+#endif
static int intra_only = 0;
@@ -41,7 +41,7 @@ Index: ffmpeg.c
} AVInputStream;
typedef struct AVInputFile {
-@@ -320,6 +338,184 @@
+@@ -320,6 +338,180 @@
static struct termios oldtty;
#endif
@@ -115,72 +115,68 @@ Index: ffmpeg.c
+
+static int configure_filters(AVInputStream *ist, AVOutputStream *ost)
+{
-+AVFilterContext *curr_filter;
++AVFilterContext *last_filter, filter;
+/** filter graph containing all filters including input & output */
+AVCodecContext *codec = ost->st->codec;
+AVCodecContext *icodec = ist->st->codec;
+char args[255];
+
-+filt_graph_all = av_mallocz(sizeof(AVFilterGraph));
++graph = av_mallocz(sizeof(AVFilterGraph));
+
-+if(!(ist->input_video_filter = avfilter_open(avfilter_get_by_name("buffer"), "src")))
++if (!(ist->input_video_filter = avfilter_open(avfilter_get_by_name("buffer"), "src")))
+return -1;
-+if(!(ist->out_video_filter = avfilter_open(&output_filter, "out")))
++if (!(ist->out_video_filter = avfilter_open(&output_filter, "out")))
+return -1;
+
+snprintf(args, 255, "%d:%d:%d", ist->st->codec->width,
+ ist->st->codec->height, ist->st->codec->pix_fmt);
-+if(avfilter_init_filter(ist->input_video_filter, args, NULL))
++if (avfilter_init_filter(ist->input_video_filter, args, NULL))
+return -1;
-+if(avfilter_init_filter(ist->out_video_filter, NULL, &codec->pix_fmt))
++if (avfilter_init_filter(ist->out_video_filter, NULL, &codec->pix_fmt))
+return -1;
+
+/* add input and output filters to the overall graph */
-+avfilter_graph_add_filter(filt_graph_all, ist->input_video_filter);
-+avfilter_graph_add_filter(filt_graph_all, ist->out_video_filter);
++avfilter_graph_add_filter(graph, ist->input_video_filter);
++avfilter_graph_add_filter(graph, ist->out_video_filter);
+
-+curr_filter = ist->input_video_filter;
++last_filter = ist->input_video_filter;
+
-+if(ost->video_crop) {
-+char crop_args[255];
-+AVFilterContext *filt_crop;
-+snprintf(crop_args, 255, "%d:%d:%d:%d", ost->leftBand, ost->topBand,
++if (ost->video_crop) {
++snprintf(args, 255, "%d:%d:%d:%d", ost->leftBand, ost->topBand,
+ codec->width - (frame_padleft + frame_padright),
+ codec->height - (frame_padtop + frame_padbottom));
-+filt_crop = avfilter_open(avfilter_get_by_name("crop"), NULL);
-+if (!filt_crop)
++filter = avfilter_open(avfilter_get_by_name("crop"), NULL);
++if (!filter)
+return -1;
-+if (avfilter_init_filter(filt_crop, crop_args, NULL))
++if (avfilter_init_filter(filter, args, NULL))
+return -1;
-+if (avfilter_link(curr_filter, 0, filt_crop, 0))
++if (avfilter_link(last_filter, 0, filter, 0))
+return -1;
-+curr_filter = filt_crop;
-+avfilter_graph_add_filter(filt_graph_all, curr_filter);
++last_filter = filter;
++avfilter_graph_add_filter(graph, filter);
+}
+
-+if((codec->width !=
-+icodec->width - (frame_leftBand + frame_rightBand) +
-+(frame_padleft + frame_padright)) ||
-+ (codec->height != icodec->height - (frame_topBand + frame_bottomBand) +
-+(frame_padtop + frame_padbottom))) {
-+char crop_args[255];
-+AVFilterContext *filt_scale;
-+snprintf(crop_args, 255, "%d:%d:sws_flags=%d",
++if ((codec->width !=
++ icodec->width - (frame_leftBand + frame_rightBand) +
++ (frame_padleft + frame_padright)) ||
++(codec->height != icodec->height - (frame_topBand + frame_bottomBand) +
++ (frame_padtop + frame_padbottom))) {
++snprintf(args, 255, "%d:%d:sws_flags=%d",
+ codec->width - (frame_padleft + frame_padright),
+ codec->height - (frame_padtop + frame_padbottom),
+ (
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On 03/31/2010 10:44 PM, S.N. Hemanth Meenakshisundaram wrote: Hi All, Based on the posts above, here's what I was thinking of doing as a qualification task : 1. Fix the configure_filters function in ffmpeg.c to work for both video and audio filters. 2. Bring the af_null and af_vol filters from soc/afilters to soc/avfilter and generalize avfilter framework to work with the af_* filters. This should involve a minimal design for the avfilter audio changes. 3. af_vol currently just scales input by two. Modify af_vol to have some basic volume filter functionality. Please let me know if I have understood the tasks right and if this will work as a qualification task. A qualification task could be to add AVCodecContext get_buffer functionality to audio decoders. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] Add fade filter to libavfilter
Hi Brandon, first thanks a lot for your work. On 03/31/2010 08:22 AM, Brandon Mintern wrote: On Wed, Mar 31, 2010 at 5:47 AM, Benoit Fouet wrote: Hi, On Wed, 31 Mar 2010 00:43:50 -0400 Brandon Mintern wrote: I am happy to present my first-ever open source code contribution, a "fade" filter for libavfilter! Here is some example usage: # Fade in first 30 frames of video ffmpeg -i input.avi -vfilters fade=in:1:30 output.avi # Fade out last 45 frames of a 200-frame video ffmpeg -i input.avi -vfilters fade=out:156:45 output.avi # Fade in first 25 frames and fade out last 25 frames of a 1000-frame video ffmpeg -i input.avi -vfilters "fade=in:1:25, fade=out:976:25" output.avi Would it be possible to (also ?) make it work as follow ? ffmpeg -i input -vfilters "fade=in:25, fade=out:25" That's to say: begin fade in at frame 0 and finish fade out at last frame. Ben The fade=in:25 is something I could do. Unfortunately the filter has no information regarding total number of frames until it reaches the end of the input stream (at least to my knowledge), so the fade=out:25 would not work without buffering frames. It should be somewhat-trivial, however, to use ffprobe or something similar beforehand in order to get the total duration and multiply that by the FPS in order to get the total frames in the video. That's the way I plan to do it. > Hmm... I just thought of an idea that should work. For fade=out we could buffer frame_length frames until we hit the end of the video, then start outputting the fading frames. Unfortunately, this is beyond my knowledge of libavfilter at the moment, and I would rather get this initial version accepted before adding more functionality to it. This is definitely something I will keep in mind though, because this seems to be how most people would like to use fade. Indeed, I thought about that as well, that could be an idea, and would help getting "buffering" mechanism implemented :) -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4719 - in concat/libavformat: m3u.c playlist.c playlist.h pls.c xspf.c
On 07/15/2009 04:39 PM, gkovacs wrote:
Author: gkovacs
Date: Thu Jul 16 01:39:02 2009
New Revision: 4719
Log:
made ff_playlist_relative_paths check list length
Modified:
concat/libavformat/m3u.c
concat/libavformat/playlist.c
concat/libavformat/playlist.h
concat/libavformat/pls.c
concat/libavformat/xspf.c
Modified: concat/libavformat/m3u.c
==
--- concat/libavformat/m3u.cThu Jul 16 01:30:37 2009(r4718)
+++ concat/libavformat/m3u.cThu Jul 16 01:39:02 2009(r4719)
@@ -39,8 +39,6 @@ static int ff_concatgen_read_play(AVForm
static int ff_concatgen_read_pause(AVFormatContext *s);
-static void ff_playlist_relative_paths(char **flist, const char *workingdir);
-
/* The ffmpeg codecs we support, and the IDs they have in the file */
static const AVCodecTag codec_m3u_tags[] = {
{ 0, 0 },
@@ -83,7 +81,7 @@ static int m3u_list_files(ByteIOContext
flist[i++][q-linebuf] = 0;
}
flist[i] = 0;
-ff_playlist_relative_paths(flist, dirname(filename));
+ff_playlist_relative_paths(flist, i, dirname(filename));
ff_playlist_add_stringlist(ctx, flist, i);
av_free(flist);
return 0;
Modified: concat/libavformat/playlist.c
==
--- concat/libavformat/playlist.c Thu Jul 16 01:30:37 2009(r4718)
+++ concat/libavformat/playlist.c Thu Jul 16 01:39:02 2009(r4719)
@@ -154,7 +154,7 @@ PlaylistContext *ff_playlist_from_encode
return NULL;
}
ctx = ff_playlist_alloc_context();
-ff_playlist_relative_paths(flist, workingdir);
+ff_playlist_relative_paths(flist, len, workingdir);
ff_playlist_add_stringlist(ctx, flist, len);
return ctx;
}
@@ -174,22 +174,22 @@ void ff_playlist_add_stringlist(Playlist
}
// converts list of mixed absolute and relative paths into all absolute paths
-void ff_playlist_relative_paths(char **flist, const char *workingdir)
+void ff_playlist_relative_paths(char **flist, int len, const char *workingdir)
{
-while (*flist != 0) { // determine if relative paths
+int i;
+for (i = 0; i< len; ++i) { // determine if relative paths
FILE *file;
char *fullfpath;
int wdslen = strlen(workingdir);
-int flslen = strlen(*flist);
+int flslen = strlen(flist[i]);
fullfpath = av_malloc(sizeof(char) * (wdslen+flslen+2));
av_strlcpy(fullfpath, workingdir, wdslen+1);
fullfpath[wdslen] = '/';
fullfpath[wdslen+1] = 0;
-av_strlcat(fullfpath, *flist, wdslen+flslen+2);
+av_strlcat(fullfpath, flist[i], wdslen+flslen+2);
if ((file = fopen(fullfpath, "r"))) {
fclose(file);
-*flist = fullfpath;
+flist[i] = fullfpath;
I'm not sure fopen is adequate here. Can playlist be using any url ?
If so I think url_fopen should be used.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left
On 07/08/2009 02:06 PM, Michael Niedermayer wrote: On Wed, Jul 08, 2009 at 01:41:52PM -0700, Baptiste Coudurier wrote: Hi Michael, On 07/08/2009 12:28 PM, Michael Niedermayer wrote: On Wed, Jul 08, 2009 at 01:12:20AM -0400, Alex Converse wrote: [...] Also if you need (per codec) options as you said, tell me which, ill add them Do you have a per codec option system ready ? :) no, i need a list of requirements/goals/use cases first once i know what the system should do that AVCodecContext fields cannot, iam sure it shouldnt be that hard ... What's needed: is custom options for encoders/decoders/muxers/demuxers which are only needed for one element. The idea of using AVCodecContext/AVFormatContext doesn't please some devs it seems (including Justin, Alex, and me). Of course global values used by all must be put in the global context. I think _devs_ would like to be able to have custom options not fitting everywhere else without poluting global context. This would also permit to have x264 and lame mapped commandlines options. Can this request be considered ? [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left
Hi Michael, On 07/08/2009 12:28 PM, Michael Niedermayer wrote: On Wed, Jul 08, 2009 at 01:12:20AM -0400, Alex Converse wrote: > [...] Also if you need (per codec) options as you said, tell me which, ill add them Do you have a per codec option system ready ? :) -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left
On 07/07/2009 11:20 PM, Jai Menon wrote: On Wed, Jul 8, 2009 at 11:40 AM, Baptiste Coudurier wrote: On 07/07/2009 10:57 PM, Jai Menon wrote: On Wed, Jul 8, 2009 at 11:16 AM, Baptiste Coudurierwrote: On 07/07/2009 10:12 PM, Alex Converse wrote: [...] One other big thing: Improvements to faac helps many people right now. People do (sadly) use faac for things. Improving the lavc encoder really only helps you and me until it's fit to merge, and who knows when that could be. That's true. On the other end, lavc encoder helps all users of lavc. Well, there is that libfaac wrapper so... Well, isn't the purpose of the encoder to drop it ? Well, I was under the assumption that this was about the bigger question of having a free aac encoder, and if Alex chooses to improve libfaac and remove non free parts, then FFmpeg would still benefit. The project was started before the problem of license arised. The goal of the project is to have an internal aac encoder. Should we stop having internal decoders/encoders ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left
On 07/07/2009 10:57 PM, Jai Menon wrote: On Wed, Jul 8, 2009 at 11:16 AM, Baptiste Coudurier wrote: On 07/07/2009 10:12 PM, Alex Converse wrote: [...] One other big thing: Improvements to faac helps many people right now. People do (sadly) use faac for things. Improving the lavc encoder really only helps you and me until it's fit to merge, and who knows when that could be. That's true. On the other end, lavc encoder helps all users of lavc. Well, there is that libfaac wrapper so... Well, isn't the purpose of the encoder to drop it ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left
On 07/07/2009 10:12 PM, Alex Converse wrote: [...] One other big thing: Improvements to faac helps many people right now. People do (sadly) use faac for things. Improving the lavc encoder really only helps you and me until it's fit to merge, and who knows when that could be. That's true. On the other end, lavc encoder helps all users of lavc. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4641 - concat/libavformat/m3u.c
Hi,
On 07/06/2009 01:08 PM, gkovacs wrote:
Author: gkovacs
Date: Mon Jul 6 22:08:38 2009
New Revision: 4641
Log:
switched to av_fast_realloc in m3u_list_files
Modified:
concat/libavformat/m3u.c
Modified: concat/libavformat/m3u.c
==
--- concat/libavformat/m3u.cMon Jul 6 21:25:34 2009(r4640)
+++ concat/libavformat/m3u.cMon Jul 6 22:08:38 2009(r4641)
@@ -41,13 +41,10 @@ static int m3u_probe(AVProbeData *p)
}
static int m3u_list_files(ByteIOContext *s, PlaylistContext *ctx)
-// char ***flist_ptr,
-// unsigned int *lfx_ptr,
-// char *workingdir)
{
char **flist;
int i, j;
-int bufsize = 16;
+int bufsize = 0;
i = 0;
flist = av_malloc(sizeof(char*) * bufsize);
while (1) {
@@ -56,11 +53,8 @@ static int m3u_list_files(ByteIOContext
break;
if (*c == 0) // hashed out
continue;
-flist[i] = c;
-if (++i == bufsize) {
-bufsize += 16;
-flist = av_realloc(flist, sizeof(char*) * bufsize);
-}
+flist = av_fast_realloc(flist,&bufsize, i+2);
+flist[i++] = c;
Missing null return check and beware of memleak.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4603 - in concat/libavformat: concatgen.c playlist.c playlist.h
On 07/04/2009 02:38 PM, gkovacs wrote:
Author: gkovacs
Date: Sat Jul 4 23:38:07 2009
New Revision: 4603
Log:
removed stream time conversion convenience functions
Modified:
concat/libavformat/concatgen.c
concat/libavformat/playlist.c
concat/libavformat/playlist.h
Modified: concat/libavformat/concatgen.c
==
--- concat/libavformat/concatgen.c Sat Jul 4 23:24:40 2009(r4602)
+++ concat/libavformat/concatgen.c Sat Jul 4 23:38:07 2009(r4603)
@@ -40,7 +40,11 @@ int concatgen_read_packet(AVFormatContex
}
if (ret>= 0) {
if (pkt) {
-int64_t time_offset = ff_conv_stream_time(ic, pkt->stream_index,
ctx->time_offsets[pkt->stream_index]);
+int64_t time_offset;
+AVRational avbasetime = {1, AV_TIME_BASE};
AV_TIME_BASE_Q
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4556 - in concat/libavformat: m3u.c playlist.c playlist.h
Geza Kovacs wrote: > On Sat, Jul 4, 2009 at 1:12 PM, Baptiste > Coudurier wrote: >> Hi, >> >> gkovacs wrote: >>> Author: gkovacs >>> Date: Wed Jul 1 03:45:05 2009 >>> New Revision: 4556 >>> >>> [...] >>> >>> PlaylistD *playld = ff_make_playlistd(s->filename); >> For what does the D stand ? It doesn't seem obvious to me. >> > > Playlist Data, I added the "D" since plain "Playlist" is often used in > other libraries as well and don't want to inconvenience libavformat > users with naming conflicts since C doesn't support namespaces. Maybe _C_ontext would be better in this case, what do you think ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4556 - in concat/libavformat: m3u.c playlist.c playlist.h
Hi, gkovacs wrote: > Author: gkovacs > Date: Wed Jul 1 03:45:05 2009 > New Revision: 4556 > > [...] > > PlaylistD *playld = ff_make_playlistd(s->filename); For what does the D stand ? It doesn't seem obvious to me. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4581 - concat/libavformat/m3u.c
Hi,
gkovacs wrote:
> Author: gkovacs
> Date: Sat Jul 4 09:43:31 2009
> New Revision: 4581
>
> Log:
> make pts equal dts + 1 to avoid invalid dts/pts combination error with
> mpeg1video in avi when dts equals pts
>
> Modified:
>concat/libavformat/m3u.c
>
> Modified: concat/libavformat/m3u.c
> ==
> --- concat/libavformat/m3u.c Sat Jul 4 09:35:24 2009(r4580)
> +++ concat/libavformat/m3u.c Sat Jul 4 09:43:31 2009(r4581)
> @@ -122,7 +122,7 @@ static int m3u_read_packet(AVFormatConte
> if (pkt) {
> int64_t time_offset = ff_conv_stream_time(ic, pkt->stream_index,
> playld->time_offsets[pkt->stream_index]);
> pkt->dts += time_offset;
> -pkt->pts = pkt->dts;
> +pkt->pts = pkt->dts + 1;
pts might not be set, ie AV_NOPTS_VALUE, and this depends on has_b_frames,
since stream might be low delay for other codecs than mpeg1.
Also you have av_rescale/av_rescale_q to rescale times.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4533 - seek_api/parser.c
Hi Zhentan, zhentan feng wrote: > Hi > > 2009/6/29 Baptiste Coudurier > >> spyfeng wrote: >>> Author: spyfeng >>> Date: Sat Jun 27 15:35:59 2009 >>> New Revision: 4533 >>> >>> Log: >>> set correct pos when cannot get pos from ff_fetch_timestamp(). >>> >>> Modified: >>>seek_api/parser.c >>> >>> Modified: seek_api/parser.c >>> >> == >>> --- seek_api/parser.c Sat Jun 27 15:28:08 2009(r4532) >>> +++ seek_api/parser.c Sat Jun 27 15:35:59 2009(r4533) >>> @@ -188,6 +188,8 @@ int av_parser_parse2(AVCodecParserContex >>> if (index < 0) >>> index = 0; >>> s->cur_offset += index; >>> +if (s->pos == -1) >>> +s->pos = s->last_pos + index; >>> return index; >>> } >> Can you explain why this change is needed ? It seems wrong to me. >> >> The goal is for getting the correct pkt->pos when call av_read_frame(). > > consider the attached two log files below. I added some log info when > av_parser_parse2() is called in libavformait/utils.c > logpf2.txt is the original outputs and logpf3.txt is the new outputs. > > I select some lines from logf2.txt. > for example, the first frame of stream index = 1 is: > [mpeg @ 0x9c43440]av_read_frame_internal stream=1, pts=45000, dts=45000, > size=208, flags=1, pos=2048 > > then the second frame is > [mpeg @ 0x9c43440]av_read_frame_internal stream=1, pts=47351, dts=47351, > size=209, flags=1, pos=-1 > > actually, we can calculate the second frame pos by the last_pos. > If keep the frame as -1, when find the keyframe by index entries, the index > entries pos is -1, we cannot seek there. Yes, pos must be set to the PES packet pos to be able to seek there and retrieve correct pts/dts for the frame. Example below: > > > > > Input #0, mpeg, from 'tests/data/b-lavf.mpg': > Duration: 00:00:01.01, start: 0.50, bitrate: 2975 kb/s > Stream #0.0[0x1e0], 1/9: Video: mpeg1video, yuv420p, 352x288 [PAR 1:1 > DAR 11:9], 1/25, 104857 kb/s, 25 tbr, 90k tbn, 25 tbc > Stream #0.1[0x1c0], 1/9: Audio: mp2, 44100 Hz, mono, s16, 64 kb/s > Output #0, null, to '/dev/null': > Stream #0.0, 1/9: Video: rawvideo, yuv420p, 352x288 [PAR 1:1 DAR > 11:9], 1/25, q=2-31, 200 kb/s, 90k tbn, 25 tbc > Stream #0.1, 1/9: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s > Stream mapping: > Stream #0.0 -> #0.0 > Stream #0.1 -> #0.1 > Press [q] to stop encoding > [mpeg @ 0x9c43440]mpeg add index stream_index=0, pos = 30, dts = 41400 > [mpeg @ 0x9c43440]av_read_packet stream=0, pts=45000, dts=41400, size=2002, > flags=0, pos = 30 > [mpeg @ 0x9c43440]mpeg add index stream_index=1, pos = 2048, dts = 45000 > [mpeg @ 0x9c43440]av_read_packet stream=1, pts=45000, dts=45000, size=2037, > flags=0, pos = 2048 pos is set here. > [mpeg @ 0x9c43440]pkt pos:2048, st->parser->pos:2048 > [mpeg @ 0x9c43440]stream_index 1, the frame_offset = 2048 > [mpeg @ 0x9c43440]av_read_frame_internal stream=1, pts=45000, dts=45000, > size=208, flags=1, pos=2048 > [mpeg @ 0x9c43440]pkt pos:-1, st->parser->pos:-1 > [mpeg @ 0x9c43440]stream_index 1, the frame_offset = 2256 > [mpeg @ 0x9c43440]av_read_frame_internal stream=1, pts=47351, dts=47351, > size=209, flags=1, pos=-1 > [mpeg @ 0x9c43440]pkt pos:-1, st->parser->pos:-1 > [mpeg @ 0x9c43440]stream_index 1, the frame_offset = 2465 Pos must be 2048 as well. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4541 - seek_api/seektest/seek_test2.c
spyfeng wrote:
> Author: spyfeng
> Date: Sun Jun 28 05:53:45 2009
> New Revision: 4541
>
> Log:
> modify the seek range as default value.
>
> Modified:
>seek_api/seektest/seek_test2.c
>
> Modified: seek_api/seektest/seek_test2.c
> ==
> --- seek_api/seektest/seek_test2.cSun Jun 28 05:37:40 2009(r4540)
> +++ seek_api/seektest/seek_test2.cSun Jun 28 05:53:45 2009(r4541)
> @@ -96,8 +96,8 @@ int main(int argc, char **argv)
> timestamp= av_rescale_q(timestamp, AV_TIME_BASE_Q,
> st->time_base);
> }
> //FIXME fully test the new seek API
> -if(i&1) ret = avformat_seek_file(ic, stream_id, INT64_MIN,
> timestamp, timestamp, 0);
> -elseret = avformat_seek_file(ic, stream_id, timestamp,
> timestamp, INT64_MAX, 0);
> +if(i&1) ret = avformat_seek_file(ic, stream_id, INT64_MIN,
> timestamp, INT64_MAX, 0);
> +elseret = avformat_seek_file(ic, stream_id, INT64_MIN,
> timestamp, INT64_MAX, 0);
> printf("ret:%2d st:%2d ts:%.2f flags:%d\n", ret, stream_id,
> timestamp*(stream_id<0 ? 0.09:1/*1.0/AV_TIME_BASE :
> av_q2d(st->time_base*9)*/), i&1);
> }
Remember that values must be mixed to ensure all cases are tested and
works. Does seek test differ now ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4540 - seek_api/mpeg.c
spyfeng wrote:
> Author: spyfeng
> Date: Sun Jun 28 05:37:40 2009
> New Revision: 4540
>
> Log:
> check the returned pts value with given range.
>
> Modified:
>seek_api/mpeg.c
>
> Modified: seek_api/mpeg.c
> ==
> --- seek_api/mpeg.c Sun Jun 28 04:13:13 2009(r4539)
> +++ seek_api/mpeg.c Sun Jun 28 05:37:40 2009(r4540)
> @@ -706,7 +706,12 @@ static int mpegps_read_seek(struct AVFor
> }
> success:
> av_update_cur_dts(s, st, pts);
> -return 0;
> +if (pts <= max_ts && pts >= min_ts)
> +return 0;
> +else {
> +av_log(s, AV_LOG_ERROR,"The target pts = %"PRId64" is out of range.
> min_ts = %"PRId64", max_ts = %"PRId64"\n", pts, min_ts, max_ts);
> +return -1;
> +}
> }
I don't think av_update_cur_dts must be done if seek has failed.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4542 - seek_api/seektest/test_dothack2.sh
spyfeng wrote: > Author: spyfeng > Date: Sun Jun 28 06:08:18 2009 > New Revision: 4542 > > Log: > add test case script. > > Added: >seek_api/seektest/test_dothack2.sh > > Added: seek_api/seektest/test_dothack2.sh > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ seek_api/seektest/test_dothack2.shSun Jun 28 06:08:18 2009 > (r4542) > @@ -0,0 +1,6 @@ > +#!/bin/sh > +echo "Test dothack.mpg from http://samples.mplayerhq.hu/MPEG2/"; > + > +./seektest2 dothack2.mpg > + > +echo "Done, please check the returned value according to the outputs." The script must check values against expected output. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4533 - seek_api/parser.c
spyfeng wrote: > Author: spyfeng > Date: Sat Jun 27 15:35:59 2009 > New Revision: 4533 > > Log: > set correct pos when cannot get pos from ff_fetch_timestamp(). > > Modified: >seek_api/parser.c > > Modified: seek_api/parser.c > == > --- seek_api/parser.c Sat Jun 27 15:28:08 2009(r4532) > +++ seek_api/parser.c Sat Jun 27 15:35:59 2009(r4533) > @@ -188,6 +188,8 @@ int av_parser_parse2(AVCodecParserContex > if (index < 0) > index = 0; > s->cur_offset += index; > +if (s->pos == -1) > +s->pos = s->last_pos + index; > return index; > } Can you explain why this change is needed ? It seems wrong to me. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4532 - seek_api/parser.c
spyfeng wrote: > Author: spyfeng > Date: Sat Jun 27 15:28:08 2009 > New Revision: 4532 > > Log: > add libavcodec/parser.c into svn. > > Added: >seek_api/parser.c That's an old version. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4443 - concat/libavformat/playlist.c
On 6/12/2009 9:26 PM, Baptiste Coudurier wrote:
> On 6/12/2009 8:53 PM, gkovacs wrote:
>> Author: gkovacs
>> Date: Sat Jun 13 05:53:49 2009
>> New Revision: 4443
>>
>> Log:
>> corrected indentation which was messed up during auto-refactoring
>>
>> Modified:
>>concat/libavformat/playlist.c
>>
>> Modified: concat/libavformat/playlist.c
>> ==
>> --- concat/libavformat/playlist.cSat Jun 13 05:50:26 2009(r4442)
>> +++ concat/libavformat/playlist.cSat Jun 13 05:53:49 2009(r4443)
>> @@ -89,7 +89,9 @@ PlaylistD* ff_make_playlistd(unsigned ch
>> return playld;
>> }
>>
>> -char* ff_conc_strings(char *string1, char *string2) {
>> +char* ff_conc_strings(char *string1,
>> + char *string2)
> strncat ?
>
sorry, av_strlcat, see libavutil/avstring.h
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4443 - concat/libavformat/playlist.c
On 6/12/2009 8:53 PM, gkovacs wrote:
> Author: gkovacs
> Date: Sat Jun 13 05:53:49 2009
> New Revision: 4443
>
> Log:
> corrected indentation which was messed up during auto-refactoring
>
> Modified:
>concat/libavformat/playlist.c
>
> Modified: concat/libavformat/playlist.c
> ==
> --- concat/libavformat/playlist.c Sat Jun 13 05:50:26 2009(r4442)
> +++ concat/libavformat/playlist.c Sat Jun 13 05:53:49 2009(r4443)
> @@ -89,7 +89,9 @@ PlaylistD* ff_make_playlistd(unsigned ch
> return playld;
> }
>
> -char* ff_conc_strings(char *string1, char *string2) {
> +char* ff_conc_strings(char *string1,
> + char *string2)
strncat ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4440 - in concat/libavformat: m3u.c playlist.c playlist.h
On 6/12/2009 6:54 PM, Geza Kovacs wrote: > On 06/12/2009 06:21 PM, Baptiste Coudurier wrote: >> Hi, >> >> On 6/12/2009 5:53 PM, gkovacs wrote: >>> Author: gkovacs >>> Date: Sat Jun 13 02:53:22 2009 >>> New Revision: 4440 >>> >>> Log: >>> removed unnecessary code, should work with same-codec different-format >>> combinations as-is, requires an (in-progress) patch to ffmpeg.c and >>> ffplay.c to handle changing streams during decoding >>> >> Please avoid suck huge commits which are just impossible to review. >> Split changes, keeping them related, and do small but frequent commits. >> >> Quick review: >> >>> [...] >>> >>> +char* buf_getline(ByteIOContext *s) >> This should be static. >> > > I will be using that function, as well as all the others declared in > playlist.h, in the PLS playlist demuxer as well, which is in a separate > file. Isn't declaring it as static going to restrict it to a single > playlist demuxer? > In this case functions should be in a common file, and must use a ff_ prefix. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4440 - in concat/libavformat: m3u.c playlist.c playlist.h
Hi, On 6/12/2009 5:53 PM, gkovacs wrote: > Author: gkovacs > Date: Sat Jun 13 02:53:22 2009 > New Revision: 4440 > > Log: > removed unnecessary code, should work with same-codec different-format > combinations as-is, requires an (in-progress) patch to ffmpeg.c and ffplay.c > to handle changing streams during decoding > Please avoid suck huge commits which are just impossible to review. Split changes, keeping them related, and do small but frequent commits. Quick review: > [...] > > +char* buf_getline(ByteIOContext *s) This should be static. > [...] > > Modified: concat/libavformat/playlist.h > == > --- concat/libavformat/playlist.h Fri Jun 12 21:24:59 2009(r4439) > +++ concat/libavformat/playlist.h Sat Jun 13 02:53:22 2009(r4440) > > [...] > > @@ -46,5 +51,14 @@ PlaylistD* av_make_playlistd(unsigned ch > > int check_file_extn(char *cch, char *extn); > > +int compare_bufs(unsigned char *buf, unsigned char *rbuf); > + > int playlist_populate_context(PlaylistD *playld, AVFormatContext *s); > > +char* conc_strings(char *string1, char *string2); > + > +char* buf_getline(ByteIOContext *s); > + > +void split_wd_fn(char *filepath, char **workingdir, char **filename); > + > +unsigned int get_stream_offset(AVFormatContext *s); And should therefore and ideally not need to be declared in a header. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Preferred XML library for XSPF playlist parsing (or write one from scratch)?
On 6/12/2009 1:14 AM, Geza Kovacs wrote: > Hi all, > > I'm starting work on an XSPF playlist parser, and since XSPF (as well as > SMIL and ASX) is an XML format, and FFmpeg doesn't seem to have its own > XML parser nor does it link against any existing ones, I'd like to know > whether there's any preferred existing XML parser I could use and link > against (Expat, libxml2?), or whether I should write my own rudimentary > parser from scratch to avoid external dependencies. If it's the latter, > should it be put at libavutil/xml.c or libavformat/xml.c? > If you are motivated, native parser is good to avoid dependencies. I think libavformat/xml.c is fine for now. Though I think ffmpeg supporting the concatenation/playlist feature should really be working before working on this :) -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Safe to use AVPacket::priv for pointing to AVFormatContext when using playlist?
On 6/12/2009 12:52 AM, Geza Kovacs wrote: > Hi all, > > Since (in ffplay) the decode_thread for audio and video lags the packet > buffering thread, in the case when different packets were read by > different demuxers and need to be decoded using different decoders (ie > h264/aac in mp4 followed by theora/vorbis in ogg in a playlist), it > appears it's necessary to keep track of the AVFormatContext which read > that packet in order to determine the decoder to use for that particular > packet. Thus I'd like to store said pointer somewhere accessible to the > decoder thread, and associated with each packet. > > Since AVPacket::priv appears to be used only by mmap_read_frame() and > mmap_release_buffer(), which is only used by Video4Linux, is it safe to > use that variable for storing the pointer to AVFormatContext or should I > create a new variable in AVPacket for this (which to my understanding > would break ABI compatibility with older versions)? It seems AVPacket->priv is private to the demuxer so I guess it must not be altered by something else nor accessed outside the demuxer. Maybe a new stream should be added in this case and the finished one should be closed. pkt->stream_index will then point to the correct stream. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4403 - seek_api/mpeg.c
On 6/10/2009 10:40 AM, spyfeng wrote: > Author: spyfeng > Date: Wed Jun 10 19:40:15 2009 > New Revision: 4403 > > Log: > set pkt->pos value when reading packet > > Modified: >seek_api/mpeg.c > > Modified: seek_api/mpeg.c > == > --- seek_api/mpeg.c Tue Jun 9 20:37:10 2009(r4402) > +++ seek_api/mpeg.c Wed Jun 10 19:40:15 2009(r4403) > @@ -541,6 +541,7 @@ static int mpegps_read_packet(AVFormatCo > return AVERROR(EINVAL); > } > av_new_packet(pkt, len); > +pkt->pos = url_ftell(s->pb); > get_buffer(s->pb, pkt->data, pkt->size); > pkt->pts = pts; > pkt->dts = dts; pkt->pos must be set to the start of the PES packet, like it was by the old av_add_index_entry. Seeking here will not work. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4391 - seek_api/mpeg.c
Hi,
On 6/8/2009 6:23 AM, spyfeng wrote:
> Author: spyfeng
> Date: Mon Jun 8 15:23:40 2009
> New Revision: 4391
>
> Log:
> fix the wrong usage for AVFMT_GENERIC_INDEX
>
> Modified:
>seek_api/mpeg.c
>
> Modified: seek_api/mpeg.c
> ==
> --- seek_api/mpeg.c Mon Jun 8 06:02:12 2009(r4390)
> +++ seek_api/mpeg.c Mon Jun 8 15:23:40 2009(r4391)
> @@ -391,7 +391,7 @@ static int mpegps_read_pes_header(AVForm
> if(startcode == s->streams[i]->id &&
> !url_is_streamed(s->pb) /* index useless on streams anyway
> */) {
> ff_reduce_index(s, i);
> -av_add_index_entry(s->streams[i], *ppos, dts, 0, 0,
> AVFMT_GENERIC_INDEX /* FIXME keyframe? */);
> +av_add_index_entry(s->streams[i], *ppos, dts, 0, 0, 0 /*
> FIXME keyframe? */);
I think you can remove this, index will be populated later in
libavformat/utils.c
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4321 - in concat/libavformat: . m3u.c playlist.c playlist.h
we need a clean implementation,
and forget about AVFormatParameters for now.
> +PlayElem* av_make_playelem(unsigned char *filename)
> +{
> +int err;
> +PlayElem *pe = av_malloc(sizeof(PlayElem));
> +err = av_alloc_playelem(filename, pe);
> +if (err < 0)
> +print_error("during-av_alloc_playelem", err);
> +err = av_open_input_playelem(pe);
> +if (err < 0)
> +print_error("during-open_input_playelem", err);
> +pe->fmt = pe->ic->iformat;
> +if (!pe->fmt)
> +{
> +fprintf(stderr, "pefmt not set\n");
> + fflush(stderr);
Why fflush ?
> +}
> +err = av_find_stream_info(pe->ic);
> +if (err < 0)
> +{
> +fprintf(stderr, "failed codec probe av_find_stream_info");
> +fflush(stderr);
Missing \n ?
> +}
> +if(pe->ic->pb)
> +{
> +pe->ic->pb->eof_reached = 0;
> +}
> +else
> +{
> +fprintf(stderr, "failed pe ic pb not set");
> +fflush(stderr);
> +}
Why do you need to reset eof_reached ?
Overall comment: do you feel confident everything will fit in a demuxer ?
I think some API calls will be useful like play 5th element in the
playlist, play next element, play prev, shuffle, etc...
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4279 - seek_api/mpeg.c
Hi,
On 5/18/2009 10:10 AM, spyfeng wrote:
> Author: spyfeng
> Date: Mon May 18 19:10:33 2009
> New Revision: 4279
>
> Log:
> Implement new seek api for mpeg.c, just compile passed, need more test.
Please test your code before comitting. Non working code is really
interesting IMHO.
> Modified:
>seek_api/mpeg.c
>
> Modified: seek_api/mpeg.c
> ==
> --- seek_api/mpeg.c Sun May 17 15:15:04 2009(r4278)
> +++ seek_api/mpeg.c Mon May 18 19:10:33 2009(r4279)
> @@ -597,6 +597,62 @@ static int64_t mpegps_read_dts(AVFormatC
> return dts;
> }
>
> +static int mpegps_read_seek(struct AVFormatContext *s, int stream_index,
> +int64_t min_ts, int64_t ts, int64_t max_ts, int
> flags)
> +{
> +AVStream *st = s->streams[stream_index];
> +int ret, index;
> +AVPacket pkt1, *pkt = &pkt1;
> +AVIndexEntry *ie = st->index_entries;
> +int64_t pos, pts, left_keyframe_ts, left_keyframe_pos;
> +
> +if (ts max_ts) {
> +av_log(s, AV_LOG_ERROR, "Wrong range set for target timestamp!\n");
> +return -1;
> +}
> +if (ts < 0 || ts >= s->duration) {
> +av_log(s, AV_LOG_ERROR, "Timestamp is out of bounds!
> timestamp=0x%"PRIx64" duration=0x%"PRIx64"\n", ts, s->duration);
> +return -1;
> +}
s->duration might not be set reliably.
> +if (st->discard >= AVDISCARD_ALL) {
> +av_log(s, AV_LOG_ERROR, "Not active stream!\n");
> +return -1;
> +}
> +
> +index = av_index_search_timestamp(st, ts, flags);
> +if (index > 0) {
> +if (ie[index].timestamp >= min_ts && ie[index].timestamp <= max_ts){
> +url_fseek(s->pb, ie[index].pos, SEEK_SET);
> +return 0;
> +}
> +}
> +
> +pos = url_ftell(s->pb);
> +for(;;){
> +ret = av_read_frame(s, pkt);
> +if (ret < 0) {
> +url_fseek(s->pb, pos, SEEK_SET);
> +return -1;
> +}
> +
> +pts = pkt->pts;
> +av_free_packet(pkt);
> +
> +if (pkt->flags&PKT_FLAG_KEY) {
> + if (pts < ts) {
> +left_keyframe_ts = pts;
> +left_keyframe_pos = pkt->pos;
> +}
> +else
> +break;
> +}
This process seems very slow, have a look at av_gen_search in
libavformat/utils.c
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4179 - in libavfilter: checkout.sh diffs/01_ffplay_filters.diff diffs/02_ffmpeg_filters.diff
On 3/22/2009 11:32 AM, Vitor Sessak wrote: > Stefano Sabatini wrote: >> On date Sunday 2009-03-22 19:10:34 +0100, Michael Niedermayer encoded: >>> On Sun, Mar 22, 2009 at 09:11:58AM +0100, Stefano Sabatini wrote: >>>> On date Sunday 2009-03-22 02:49:12 +0100, Michael Niedermayer encoded: >>>>> On Sun, Mar 22, 2009 at 01:08:24AM +0100, Stefano Sabatini wrote: >>>>>> On date Sunday 2009-03-22 01:05:42 +0100, stefano encoded: >>>>>>> Author: stefano >>>>>>> Date: Sun Mar 22 01:05:42 2009 >>>>>>> New Revision: 4179 >>>>>>> >>>>>>> Log: >>>>>>> Update to FFmpeg r18133. >>>>>>> >>>>>>> Modified: >>>>>>>libavfilter/checkout.sh >>>>>>>libavfilter/diffs/01_ffplay_filters.diff >>>>>>>libavfilter/diffs/02_ffmpeg_filters.diff >>>>>> This breaks regression for mxf_d10. >>>>>> >>>>>> It is expected, since that test uses -padtop, which works differently >>>>>> from the one in FFmpeg (also the soc one looks broken). >>>>> he?! >>>>> there should be no -pad* in libavfilter svn because that should be >>>>> done >>>>> by filters. >>>> Do you mean that the various -padXXX options should be removed from >>>> ffmpeg.c right now? >>> from soc libavfilter ffmpeg yes thats an option > > I think ours users might hate that the command-line options they use is > all of a sudden broken. I think it is reasonable having "-padxxx" > supported and printing "Warning, parameter -padtop is deprecated, use > instead -vfilters pad" during quite some time before removing that... > >>>> Only problem is that regression test then will fail, so I suggest to >>>> wait up to when will have a pad filter. >>> id suggest to drop all pad options from the regression tests >> >> So the question is why the mxf_d10 test uses -padtop in the first >> place. > > It looks useful to me to detect if there is some regression on the > padding code and it will be useful to test lavfi if the -padtop > command-line switch is not removed... I definitely agree :) Besides, you loose -padtop you loose d10 :/ -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA checking for life_signs in -lkenny... no FFmpeg maintainer http://www.ffmpeg.org ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r3964 - in wmapro: wma3.h wma3data.h wma3dec.c
Hi Sascha,
faust3 wrote:
> [...]
>
> if ( idx == 126 )
> {
>while(i < 4){
You may need to uniformize '{' placement, also get rid of these spaces
before and after parentheses.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r3957 - wmapro/wma3dec.c
Hi,
faust3 wrote:
> Author: faust3
> Date: Thu Jan 15 19:47:58 2009
> New Revision: 3957
>
> Log:
> name the decoder wmapro
>
> Modified:
>wmapro/wma3dec.c
>
> Modified: wmapro/wma3dec.c
> ==
> --- wmapro/wma3dec.c Thu Jan 15 19:45:48 2009(r3956)
> +++ wmapro/wma3dec.c Thu Jan 15 19:47:58 2009(r3957)
> @@ -1616,7 +1616,7 @@ static int wma3_decode_packet(AVCodecCon
> */
> AVCodec wmapro_decoder =
> {
> -"wmav3pro",
> +"wmapro",
> CODEC_TYPE_AUDIO,
> CODEC_ID_WMAPRO,
> sizeof(WMA3DecodeContext),
Considering we have wmav1 and wmav2, I think wmav3pro was a better name,
what do other think ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r3937 - dvbmuxer/mpegtsenc.c
Tomer Barletz wrote: > On Sun, Jan 11, 2009 at 11:51 AM, Baptiste Coudurier > wrote: >>>> [...] > > But a section might spread on more than one packet. Yes, that's why there is a += in a while loop. What's the problem exactly ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA checking for life_signs in -lkenny... no ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r3937 - dvbmuxer/mpegtsenc.c
Tomer Barletz wrote: >> [...] >> >> @@ -81,6 +106,7 @@ static void mpegts_write_section(MpegTSS >> >> buf_ptr += len1; >> len -= len1; >> +ts->cur_pcr += TS_PACKET_SIZE*8*9LL/ts->mux_rate; > > Why 8? > Because ts->mux_rate is in bits/s not bytes. >> [...] >> >> @@ -580,7 +582,7 @@ static void mpegts_write_pes(AVFormatCon >> payload += len; >> payload_size -= len; >> put_buffer(s->pb, buf, TS_PACKET_SIZE); >> -ts->cur_pcr += (TS_PACKET_SIZE+write_pcr)*8*9LL / ts->mux_rate; >> +ts->cur_pcr += TS_PACKET_SIZE*8*9LL/ts->mux_rate; > > And again... See above. > > It seems like you assume each SI section duration is 8 packets long. > Am I correct? Nope. > Anyway, this does not seem too accurate to me. Have we abandoned the > former method of calculating each written SI packet? This method is correct, I think. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA checking for life_signs in -lkenny... no ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] ALAC Benchmarks
Hi Guys, Mike Melanson wrote: > Jai Menon wrote: >> Also, if the Touch with a fairly recent firmware upgrade has problems, I'm >> not >> really sure if the iPhone will be able to grok the files either. Anybody out >> there with free time and an iPhone willing to try this out? > > It didn't work in the iPhone at first. But after adding some metadata > using iTunes, the file did play. I am going to experiment with this idea > using my iPod Touch and figure out what the connection is. > Just did test 2 files alac.mov and alac.m4a on mplayerhq on my iphone 3g 2.0.2, and everything works great ! -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
Hi,
zhentan feng wrote:
> Hi
>
> 2008/8/27 Baptiste Coudurier <[EMAIL PROTECTED]>
>
>> Hi,
>>
>> zhentan feng wrote:
>>> [...]
>>>
>>> +
>>> +if (!(s->streams[0]->codec->flags & CODEC_FLAG_BITEXACT)) {
>>> +mxf_write_local_tag(pb, version_string_len, 0x3C04);
>>> +put_buffer(pb, LIBAVFORMAT_IDENT, version_string_len);
>>> +}
>> According to 377M, Version String is "req", so you have to put something
>> here when bitexact is enabled. IMHO "0.0.0" should be fine.
>>
>
> here is the new patch version 0.0.9.
> 1) fix this bug
> 2) write company name, product name, version string as utf 16
> 3) modify version string and track number uls.
>
> please review.
> thanks
>
>
>
>
> Index: libavformat/mxfenc.c
> ===
> --- libavformat/mxfenc.c (revision 15018)
> +++ libavformat/mxfenc.c (working copy)
> @@ -32,7 +32,10 @@
> //#define DEBUG
>
> #include "mxf.h"
> +#include
>
> +typedef wchar_t MXFUTF16String;
> +
You don't need that, you need to transform char * to utf-16.
> typedef struct {
> int local_tag;
> UID uid;
> @@ -96,7 +99,7 @@
> { 0x3C09,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x01,0x00,0x00,0x00}},
> /* This Generation UID */
> { 0x3C01,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x02,0x01,0x00,0x00}},
> /* Company Name */
> { 0x3C02,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x03,0x01,0x00,0x00}},
> /* Product Name */
> -{ 0x3C04,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x04,0x00,0x00,0x00}},
> /* Version String */
> +{ 0x3C04,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x05,0x01,0x00,0x00}},
> /* Version String */
> { 0x3C05,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x07,0x00,0x00,0x00}},
> /* Product ID */
> { 0x3C06,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x07,0x02,0x01,0x10,0x02,0x03,0x00,0x00}},
> /* Modification Date */
> // Content Storage
ok.
> @@ -112,7 +115,7 @@
> { 0x4701,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x02,0x03,0x00,0x00}},
> /* Descriptor */
> // Track
> { 0x4801,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x01,0x07,0x01,0x01,0x00,0x00,0x00,0x00}},
> /* Track ID */
> -{ 0x4804,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x01,0x03,0x00,0x00}},
> /* Track Numberr */
> +{ 0x4804,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x01,0x04,0x01,0x03,0x00,0x00,0x00,0x00}},
> /* Track Numberr */
One 'r' too much.
> [...]
>
> @@ -331,14 +344,16 @@
>
> mxf_write_metadata_key(pb, 0x013000);
> PRINT_KEY(s, "identification key", pb->buf_ptr - 16);
> -company_name_len = sizeof("FFmpeg");
> -product_name_len = sizeof("OP1a Muxer");
> +company_name_len = (wcslen(L"FFmpeg") + 1) * 2;
> +product_name_len = (wcslen(L"OP1a Muxer") + 1) * 2;
>
> length = 80 + company_name_len + product_name_len;
> -if (!(s->streams[0]->codec->flags & CODEC_FLAG_BITEXACT)) {
> -version_string_len = sizeof(LIBAVFORMAT_IDENT);
> -length += 4 + version_string_len;
> -}
> +if (!(s->streams[0]->codec->flags & CODEC_FLAG_BITEXACT))
> +version_string_len = (wcslen(WCS_LIBAVFORMAT_IDENT) + 1) * 2;
> +else
> +version_string_len = (wcslen(L"0.0.0") + 1) * 2;
> +
> +length += 4 + version_string_len;
> klv_encode_ber_length(pb, length);
Something like:
If (bitexact) version_string = LIBAVFORMAT_VERSION
else version_string = "0.0.0"
This is version btw, not ident.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
Hi Reimar, Reimar Döffinger wrote: > On Tue, Aug 26, 2008 at 09:59:12AM -0700, Baptiste Coudurier wrote: >> zhentan feng wrote: >>> [...] >>> >>> + >>> +mxf_write_local_tag(pb, company_name_len, 0x3C01); >>> +put_buffer(pb, "FFmpeg", company_name_len); >> Sorry for noticing it so late, but this is wrong, all strings in MXF are >> in UTF-16. > > Ok, so I finally decided to look at it myself (should have done it the > first time - nobody else seems to have bothered to check it during the > discussion). > First, more precisely it is UTF-16BE. > Secondly, there (expectedly) is no need to 0-terminate the strings, so > strlen would have been better than sizeof (saving a few bytes). > Not that I think UTF-16 is even remotely a good choice they made there, > and then not even making it compatible to the only other big user of it > (Windows, which uses UTF-16LE). > I also have to ask: Are you sure all strings are UTF-16? The way they > express themselves in section 3.3 of 377m is extremely unclear to me: > " > Strings Strings are created from individual characters defined either as ISO > 7-bit characters (as > used in SMPTE RP210) requiring 1 byte per character, or as Unicode > UTF-16 characters > requiring 2 bytes per character. In the case of UTF-16 characters > expressing ISO 7-bit > characters, an inspection of every byte will show each 2-byte pair as > a null byte and a > character byte. Byte order is specified as fixed big endian. The > number of bytes allocated > to this string is given by the KLV encoding. There is no requirement > to terminate each > string with a zero value. However, if the length of the String > information is less than the > space allocated, the string shall be terminated with a zero value > " > > Which sounds as if they could be either - though the tables all seem to > say UTF16... > Yes, this is ok I think, all string fields in 377M are specified as UTF-16 String though, but other specs can choose ISO 7 bit, I don't know any spec doing so however. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
zhentan feng wrote: > [...] > > + > +mxf_write_local_tag(pb, company_name_len, 0x3C01); > +put_buffer(pb, "FFmpeg", company_name_len); Sorry for noticing it so late, but this is wrong, all strings in MXF are in UTF-16. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
Hi,
zhentan feng wrote:
> [...]
>
> +
> +if (!(s->streams[0]->codec->flags & CODEC_FLAG_BITEXACT)) {
> +mxf_write_local_tag(pb, version_string_len, 0x3C04);
> +put_buffer(pb, LIBAVFORMAT_IDENT, version_string_len);
> +}
According to 377M, Version String is "req", so you have to put something
here when bitexact is enabled. IMHO "0.0.0" should be fine.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
Michael Niedermayer wrote:
> [...]
>
>> static void mxf_update_header_partition(AVFormatContext *s, int64_t
>> footer_partition_offset)
>> {
>> MXFContext *mxf = s->priv_data;
>> Index: mxf.h
>> ===
>> --- mxf.h(revision 14903)
>> +++ mxf.h(working copy)
>> @@ -41,6 +41,7 @@
>> Identification,
>> ContentStorage,
>> SubDescriptor,
>> +TypeBottom,// add metadata type before this
>> };
>>
>> typedef struct {
>
> ok
>
>
Why do we need this ?
I don't understand why do we need this for uuid genereration ?
My idea is set a MXFContext->cur_uid to a static start value, then
increment this value for each uid needed.
Is there something wrong with this ? I don't see how this mess (if
MaterialPackage etc ...) is needed.
UID is just a way to reference unique metadata in mxf file, enum seems
not needed, streams[0] and streams[1] does not necessearly need to have
number in sequence.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.2
Hi guys,
Michael Niedermayer wrote:
> [...]
>
>>>>
>>>>> [...]
>>>>>
>>>>>> @@ -87,6 +930,41 @@
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +static int mxf_update_header_partition(AVFormatContext *s, int64_t
>>>>> footer_partition_offset)
>>>>>> +{
>>>>>> +MXFContext *mxf = s->priv_data;
>>>>>> +ByteIOContext *pb = s->pb;
>>>>>> +
>>>>>> +if (!url_is_streamed(s->pb)) {
>>>>>> +url_fseek(pb, mxf->header_byte_count_offset, SEEK_SET);
>>>>>> +put_be64(pb, mxf->header_byte_count);
>>>>>> +put_flush_packet(pb);
>>>>>> +
>>>>>> +url_fseek(pb, mxf->header_footer_partition_offset,
>>> SEEK_SET);
>>>>>> +put_be64(pb, footer_partition_offset);
>>>>>> +put_flush_packet(pb);
>>>>>> +} else {
>>>>>> +av_log(s, AV_LOG_ERROR, "update header partition failed, non
>>>>> streamble out put\n");
>>>>>> +return -1;
>>>>>> +}
>>>>> we should support streamed files, not fail for them. I belive the
>>> footer
>>>>> partition is optional and when there is none also no pointer needs to
>>> point
>>>>> to one.
>>>>
>>>> 1)I understand like this:
>>>> when files is not streamed, we can seek by offset freely,
>>>> and when files is streamed, we can not seek.
>>>>
>>>> But if cannot, when wrting the header partition, we can not get the
>>> correct
>>>> value until end of the file, so how to update the correct field in header
>>>> partition?
>>>>
>>>> 2) according to s377m, footer partition is not optional.
>>> s377m says:
>>> "An MXF File shall be divided into a number of partitions:
>>> one Header Partition which shall be followed by
>>> zero or more Body Partitions, the last of which shall be followed by
>>>
>>> zero or one Footer Partition
>>> ^^^
>>> "
>>>
>>>
>> It's my fault, I missed this improtant rule.
>> should we remove footer partition?
>
> I think the footer should be written for non streamed files and
> ommited for streamed ones.
>
>
>> btw: it will be very helpful to hear some suggestion from Baptiste.
>
> yes, i hope he finds some internet access soon whereever he is
>
"The file footer shall be present unless a specialized operational
pattern is being used which defines it to be absent or optional."
OP1a does not override 377m in this matter, so I think a closed complete
footer must be present.
mxf_write_trailer should update header if possible (duration is very
useful) and write footer (without metadata if header is updated), we can
a RIP after footer to locate partitions if wanted, I don't think it is
necessary though.
Header will have 0 has footer offset, unless updated, anyway I don't
think the code will be complicated, overwriting old partition is trivial
(seek offset, same function) and new header should take the same amount
of bytes (except if index tables are added in header, but 16k should be
enough like freemxf does).
All files I have in hands have a footer.
Also I know that D-10 mapping specs recommends index tables to be in
_header_.
>>
>>>> "Where present, a Footer Partition shall be located at the end of the
>>> file.
>>>> It shall comprise a Footer Partition Pack
>>>> followed optionally by the Header Metadata, and optionally by Index Table
>>>> segments. The Footer Partition may
>>>> optionally be followed by a Random Index Pack. "
>>> "where present" means "if there is" so it says
>>> "if there is a footer partition then it should be at the end of the file"
>>>
>>> baptiste probably can say more about all this, but i think he isnt here
>>> ATM?
I think s377m mandates a footer unless explicitly stated optional in
operational pattern.
>>>
>>>> 3) I run ./ffmpeg -i test.mpg test.mxf
>>>> it generate unstreamed files, and how to generated streamed files?
>>> ./ffmpeg -i test.mpg -f mxf - >test.mxf
>>>
>>> I mention again the former issue which you seems missed here:
>
>> when files is not streamed, we can seek by offset freely,
>> and when files is streamed, we can not seek.
>
> yes
>
>
>> But if cannot, when wrting the header partition, we can not get the correct
>> value until end of the file, so we will write a default value and mark the
>> position then update later.
>>
>> so, if streamed file muxed , any solution about this?
>
> if we ommit the footer then theres no need to update the pointer to it
> and header_byte_count can be updated likely as there is a small internal
> buffer that allow small seeks before put_flush_packet() even in streamed
> files
>
Well It's good to have a closed complete header when we can IMHO, I
think it is trivial to update header.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [Patch]Mxf muxer 0.0.1
Baptiste Coudurier wrote: > Michael Niedermayer wrote: >> On Thu, Aug 14, 2008 at 11:41:01AM +0800, zhentan feng wrote: >>> Hi >>> >>> 2008/8/14 Michael Niedermayer <[EMAIL PROTECTED]> >>> >>>> On Wed, Aug 13, 2008 at 03:47:15PM +0800, zhentan feng wrote: >>>>> Hi, >>>>> >>>>> after changing the code in svn soc according to former reviews, >>>>> here is the diff between svn soc and ffmpeg trunk. >>>>> >>>>> mainly do this works: >>>>> 1) add mxfenc.c to impliment MXF simple muxer >>>>> 2) extract common code from mxfenc.c and mxfdec.c into mxf.h >>>>> >>>>> -- >>>>> Best wishes~ >>>>> Index: libavformat/mxfenc.c >>>>> === >>>>> --- libavformat/mxfenc.c (revision 0) >>>>> +++ libavformat/mxfenc.c (revision 0) >>>>> @@ -0,0 +1,1058 @@ >>>>> +/* >>>>> + * MXF muxer >>>>> + * Copyright (c) 2008 GUCAS, Zhentan Feng >>>>> + * >>>>> + * This file is part of FFmpeg. >>>>> + * >>>>> + * FFmpeg is free software; you can redistribute it and/or >>>>> + * modify it under the terms of the GNU Lesser General Public >>>>> + * License as published by the Free Software Foundation; either >>>>> + * version 2.1 of the License, or (at your option) any later version. >>>>> + * >>>>> + * FFmpeg is distributed in the hope that it will be useful, >>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >>>>> + * Lesser General Public License for more details. >>>>> + * >>>>> + * You should have received a copy of the GNU Lesser General Public >>>>> + * License along with FFmpeg; if not, write to the Free Software >>>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA >>>> 02110-1301 USA >>>>> + */ >>>>> + >>>>> +/* >>>>> + * References >>>>> + * SMPTE 336M KLV Data Encoding Protocol Using Key-Length-Value >>>>> + * SMPTE 377M MXF File Format Specifications >>>>> + * SMPTE 379M MXF Generic Container >>>>> + * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container >>>>> + * SMPTE RP210: SMPTE Metadata Dictionary >>>>> + * SMPTE RP224: Registry of SMPTE Universal Labels >>>>> + */ >>>>> + >>>> ok >>>> (this part and all other ok-ed parts can be commited >>>> that way the patch will become smaller and easier to review) >>>> >>> I diff the files with FFmpeg trunk. >>> It seems that I can not commit to FFmpeg repo, but I'll improved it in soc >>> svn. >> baptiste (or any othetr volunteer), can you commit the ok-ed parts? >> > > I will asap, when I figure out how many hunks can be commited, except a > few structs definitions and license header ;) > > Stopping the kidding, yes I will apply them asap. > > [...] > Applied ok'd hunks in mxfenc.c -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [Patch]Mxf muxer 0.0.1
Michael Niedermayer wrote: > On Thu, Aug 14, 2008 at 11:41:01AM +0800, zhentan feng wrote: >> Hi >> >> 2008/8/14 Michael Niedermayer <[EMAIL PROTECTED]> >> >>> On Wed, Aug 13, 2008 at 03:47:15PM +0800, zhentan feng wrote: >>>> Hi, >>>> >>>> after changing the code in svn soc according to former reviews, >>>> here is the diff between svn soc and ffmpeg trunk. >>>> >>>> mainly do this works: >>>> 1) add mxfenc.c to impliment MXF simple muxer >>>> 2) extract common code from mxfenc.c and mxfdec.c into mxf.h >>>> >>>> -- >>>> Best wishes~ >>>> Index: libavformat/mxfenc.c >>>> === >>>> --- libavformat/mxfenc.c (revision 0) >>>> +++ libavformat/mxfenc.c (revision 0) >>>> @@ -0,0 +1,1058 @@ >>>> +/* >>>> + * MXF muxer >>>> + * Copyright (c) 2008 GUCAS, Zhentan Feng >>>> + * >>>> + * This file is part of FFmpeg. >>>> + * >>>> + * FFmpeg is free software; you can redistribute it and/or >>>> + * modify it under the terms of the GNU Lesser General Public >>>> + * License as published by the Free Software Foundation; either >>>> + * version 2.1 of the License, or (at your option) any later version. >>>> + * >>>> + * FFmpeg is distributed in the hope that it will be useful, >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >>>> + * Lesser General Public License for more details. >>>> + * >>>> + * You should have received a copy of the GNU Lesser General Public >>>> + * License along with FFmpeg; if not, write to the Free Software >>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA >>> 02110-1301 USA >>>> + */ >>>> + >>>> +/* >>>> + * References >>>> + * SMPTE 336M KLV Data Encoding Protocol Using Key-Length-Value >>>> + * SMPTE 377M MXF File Format Specifications >>>> + * SMPTE 379M MXF Generic Container >>>> + * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container >>>> + * SMPTE RP210: SMPTE Metadata Dictionary >>>> + * SMPTE RP224: Registry of SMPTE Universal Labels >>>> + */ >>>> + >>> ok >>> (this part and all other ok-ed parts can be commited >>> that way the patch will become smaller and easier to review) >>> >> I diff the files with FFmpeg trunk. >> It seems that I can not commit to FFmpeg repo, but I'll improved it in soc >> svn. > > baptiste (or any othetr volunteer), can you commit the ok-ed parts? > I will asap, when I figure out how many hunks can be commited, except a few structs definitions and license header ;) Stopping the kidding, yes I will apply them asap. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [Patch]Mxf muxer 0.0.1
Hi, Michael Niedermayer wrote: > On Fri, Aug 15, 2008 at 01:03:52AM +0800, zhentan feng wrote: >> Hi >> >> 2008/8/14 Michael Niedermayer <[EMAIL PROTECTED]> >> >>> On Thu, Aug 14, 2008 at 11:41:01AM +0800, zhentan feng wrote: > [...] > >>>>>> +}; >>>>> duplicate >>>>> >>>> I tried to extract this code ,however, we muxing by CodecID type to get >>> UL, >>>> but one CodecID have different ULs, such as CODEC_ID_PCM_S16LE. >>>> >>>> so when checking each item in mxf_essence_container_uls for streams to >>> build >>>> essence container references, we can not decide which ul to use only by >>>> CodecID type. >>>> But we actually know which type we should mux, so just write what will be >>>> muxed type in the table. >>> no reason not the share the tables, either CODEC_ID_PCM_S16LE must be >>> special >>> handled or the UL used for muxing can be the first CODEC_ID_PCM_S16LE in >>> the >>> table. >>> >> hmm, to get the ul when muxing, i think it is not enough only by CodecID >> type. >> Is it necessary to add some flag in the table( or get information from some >> api in FFmpeg) to distinguish one CodecID type having different uls? > > Either > A. MXF supports generic 16bit PCM, in which case it has one (or more) >identifers for it and any of them can be used at will > or > B. MXF does not support generic 16bit PCM but supports just 16bit PCM with >a finite set of fixed samplerates/ channels in which case a different >identifer might need to be choosen for each sample rate or channel count. >in that case a simple >if(codec_id == CODEC_ID_PCM_S16LE && sample_rate==123) write(); can >be used. > It depends on the mapping used, here to wrap WAV/AES3 essence there is a spec, I already told zhentan to follow the spec. For now we are using WAV/AES3 specs, so put this value at the top if you want it to be picked. The other codecs uls are for D-10 mapping, where the UL differs and some specific code is done in demuxer to demux this, until a bitstream filter or decoder is written. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2973 - mxf/mxfenc.c
Hi,
Michael Niedermayer wrote:
> On Sat, Aug 02, 2008 at 01:22:26AM +0800, zhentan feng wrote:
>> Hi
>>
>> 2008/8/2 Michael Niedermayer <[EMAIL PROTECTED]>
>>
>>> On Fri, Aug 01, 2008 at 06:55:59PM +0200, spyfeng wrote:
>>>> Author: spyfeng
>>>> Date: Fri Aug 1 18:55:59 2008
>>>> New Revision: 2973
>>>>
>>>> Log:
>>>> remove malloc mem for mxf->track_number_sign.
>>>> use static array instead.
>>> [...]
>>>> +static
>>> track_number_sign[sizeof(mxf_essence_element_key)/sizeof(MXFEssenceElementKey)]
>>> = { 0 };
>>> [...]
>>>> @@ -627,8 +624,8 @@ static int mxf_write_track(AVFormatConte
>>>> if (st->codec->codec_id== element->type) {
>>>> // write track number
>>>> put_buffer(pb, element->uid + 12, 3);
>>>> -put_byte(pb, element->uid[15] +
>>> mxf->track_number_sign[i]);
>>>> -mxf->track_number_sign[i] ++;
>>>> +put_byte(pb, element->uid[15] + track_number_sign[i]);
>>>> +track_number_sign[i] ++;
>>> static arrays must be constant, it should be in the struct but not malloced
>>>
>> ok.
>> but if this, I should move MXFContext defination under the static tables
>> because the size of the arrary depend mxf_essence_element_key. It will looks
>> like a little ugly ;)
>
> umm, i see, well a variable static array is definitly not ok.
> maybe a local array in mxf_build_structural_metadata() would be
> a possibility?
> Or maybe baptiste has some better idea?
>
Not really, local array seems the solution.
Also I suggest also to set AVStream->priv_data to some structure where
you will have to store per track informations like duration anyway, so
zhentan should remove these fields from main context.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] How is everyone progressing?
zhentan feng wrote: > Hi > > 2008/7/31 Baptiste Coudurier <[EMAIL PROTECTED]> > >> Hi Zhentan, >> >> zhentan feng wrote: >>> [...] >>> >>> My status is improving the code by reviews from friends of the community, >> to >>> make the code cleaner and more efficiency. >>> Moreover, it's necessary to run more test on mxfenc.c, any ideas? >>> I think I should hurry to do it and try to submit the code ASAP. >>> thanks all people reviewing my coarse code. >>> >> Try to search for other MXF sdk/players on the net, maybe they have free >> tools. >> >> Testing can be done using Sony XDCAM viewer on windows, but you'd have >> to create D-10 files (MPEG-2 very constrained), and need many patches >> for that. If you want to inspect MXF D-10 mapping specs and want to >> implement I will help and give you patches and commandlines. >> > > ok. > however, could we clarify the goals of the GSoC? You need to get the muxer working and commited to svn. > Does I need to implement D-10 files muxer? No. > It seems I have to read more specs about it :p > > I mean that it will be good to get some results and reach milestones when > GSoC finished. > certainly, I'll continue to maintance and extend mxfenc.c out of the summer > if necessary. > Certainly. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] How is everyone progressing?
Hi Zhentan, zhentan feng wrote: > [...] > > My status is improving the code by reviews from friends of the community, to > make the code cleaner and more efficiency. > Moreover, it's necessary to run more test on mxfenc.c, any ideas? > I think I should hurry to do it and try to submit the code ASAP. > thanks all people reviewing my coarse code. > Try to search for other MXF sdk/players on the net, maybe they have free tools. Testing can be done using Sony XDCAM viewer on windows, but you'd have to create D-10 files (MPEG-2 very constrained), and need many patches for that. If you want to inspect MXF D-10 mapping specs and want to implement I will help and give you patches and commandlines. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2903 - mxf/mxfenc.c
Diego Biurrun wrote:
> On Tue, Jul 29, 2008 at 10:40:54AM -0700, Baptiste Coudurier wrote:
>> spyfeng wrote:
>>> Log:
>>> change lower case to upper case of the keys
>>>
>>> --- mxf/mxfenc.c(original)
>>> +++ mxf/mxfenc.cTue Jul 29 19:01:20 2008
>>> @@ -101,22 +101,22 @@ typedef struct {
>>>
>>> /* complete key */
>>> -static const uint8_t op1a_ul[]= { 0x06, 0x0e, 0x2b, 0x34,
>>> 0x04, 0x01, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x01, 0x01, 0x00 };
>>> -static const uint8_t header_partition_key[]= { 0x06, 0x0e,
>>> 0x2b, 0x34, 0x02, 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x02,
>>> 0x04, 0x00 }; // ClosedComplete
>>> -static const uint8_t footer_partition_key[] = {0x06, 0x0e, 0x2b, 0x34,
>>> 0x02, 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x04, 0x04, 0x00}; //
>>> ClosedComplete
>>> -static const uint8_t primer_pack_key[] = {
>>> 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x05,0x01,0x00
>>> };
>>> +static const uint8_t op1a_ul[]= { 0x06, 0x0E, 0x2B, 0x34,
>>> 0x04, 0x01, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x01, 0x01, 0x00 };
>>> +static const uint8_t header_partition_key[]= { 0x06, 0x0E,
>>> 0x2B, 0x34, 0x02, 0x05, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x02,
>>> 0x04, 0x00 }; // ClosedComplete
>>> +static const uint8_t footer_partition_key[] = {0x06, 0x0E, 0x2B, 0x34,
>>> 0x02, 0x05, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x04, 0x04, 0x00}; //
>>> ClosedComplete
>>> +static const uint8_t primer_pack_key[] = {
>>> 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x05,0x01,0x00
>>> };
>> Vertically align these.
>> You can remove spaces between numbers if you want, key are already long
>> enough.
>
> Please keep the spaces and break the lines instead. The spaces make it
> much more readable IMO.
>
I'll be maintaining the file, please remove spaces and don't break the
lines for now. I find it more readable. Thanks.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2858 - mxf/mxfenc.c
Hi, spyfeng wrote: > [...] > > + > +// write audio sampling rate > +mxf_write_local_tag(pb, 8, 0x3D03); > +put_be32(pb, 48000); > +put_be32(pb, 1); > + st->codec->sample_rate -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2903 - mxf/mxfenc.c
Hi,
spyfeng wrote:
> Author: spyfeng
> Date: Tue Jul 29 19:01:20 2008
> New Revision: 2903
>
> Log:
> change lower case to upper case of the keys
>
>
> Modified:
>mxf/mxfenc.c
>
> Modified: mxf/mxfenc.c
> ==
> --- mxf/mxfenc.c (original)
> +++ mxf/mxfenc.c Tue Jul 29 19:01:20 2008
> @@ -101,22 +101,22 @@ typedef struct {
> enum CodecType type;
> } MXFDescriptorWriteTableEntry;
>
> -static const uint8_t umid_base[] = {0x06, 0x0a, 0x2b, 0x34, 0x01, 0x01,
> 0x01, 0x01, 0x01, 0x01, 0x0f, 0x00, 0x13, 0x00, 0x00, 0x00};
> +static const uint8_t umid_base[] = {0x06, 0x0A, 0x2B, 0x34, 0x01, 0x01,
> 0x01, 0x01, 0x01, 0x01, 0x0F, 0x00, 0x13, 0x00, 0x00, 0x00};
>
> /* complete key */
> -static const uint8_t op1a_ul[]= { 0x06, 0x0e, 0x2b, 0x34, 0x04,
> 0x01, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x01, 0x01, 0x00 };
> -static const uint8_t header_partition_key[]= { 0x06, 0x0e, 0x2b,
> 0x34, 0x02, 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x02, 0x04, 0x00
> }; // ClosedComplete
> -static const uint8_t footer_partition_key[] = {0x06, 0x0e, 0x2b, 0x34, 0x02,
> 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x04, 0x04, 0x00}; //
> ClosedComplete
> -static const uint8_t primer_pack_key[] = {
> 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x05,0x01,0x00
> };
> +static const uint8_t op1a_ul[]= { 0x06, 0x0E, 0x2B, 0x34, 0x04,
> 0x01, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x01, 0x01, 0x00 };
> +static const uint8_t header_partition_key[]= { 0x06, 0x0E, 0x2B,
> 0x34, 0x02, 0x05, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x02, 0x04, 0x00
> }; // ClosedComplete
> +static const uint8_t footer_partition_key[] = {0x06, 0x0E, 0x2B, 0x34, 0x02,
> 0x05, 0x01, 0x01, 0x0D, 0x01, 0x02, 0x01, 0x01, 0x04, 0x04, 0x00}; //
> ClosedComplete
> +static const uint8_t primer_pack_key[] = {
> 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x05,0x01,0x00
> };
Vertically align these.
You can remove spaces between numbers if you want, key are already long
enough.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] mxfenc.c version 0.0.3
Hi, zhentan feng wrote: > Hi > > 2008/7/26 Reimar Döffinger <[EMAIL PROTECTED]> > >> Hello, >> On Sat, Jul 26, 2008 at 10:38:11PM +0800, zhentan feng wrote: >>> I set breakpoint in ffmpeg.c:1662 and checked that I have stored the >> codec >>> type and code id correctly. >>> >>> codec_type = CODEC_TYPE_VIDEO, codec_id = CODEC_ID_MPEG4, pix_fmt = >>> PIX_FMT_YUV420P >> Then if the width and height are indeed optional, the mxf demuxer >> probably should set AVSTREAM_PARSE_HEADERS for each stream where >> they are not set. >> > > you are right. > > mxf.c says: > if (has descriptor) > do some thing and set AVSTREAM_PARSE_HEADERS. > else > continue and do not set AVSTREAM_PARSE_HEADERS. > > I didn't write descriptors for track, so mxf.c doesn't set > AVSTREAM_PARSE_HEADERS. > so the bug occurs, is it? > Please write descriptors. These are HIGHLY recommended in the specs. Demuxer simply does not support track without descriptor, and it is even written in comments ! -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2842 - aacenc/aacenc.c
Hi, kostya wrote: > Author: kostya > Date: Thu Jul 24 11:57:40 2008 > New Revision: 2842 > > Log: > Delay encoding by one frame to provide lookahead samples > Im not sure, and this issue is really puzzling me. In this specific case, pts would be different than dts. I don't know why no encoder takes this into account, there might be something Im not understanding. I think therefore encoder should now output pts for encoded frames. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2827 - mxf/mxfenc.c
Hi,
spyfeng wrote:
> Author: spyfeng
> Date: Sun Jul 20 06:59:53 2008
> New Revision: 2827
>
> Log:
> caculate the number of essence container type when writing header partition,
> and store the values in MXFContext.
> so we can use the values freely when writing preface set and footer partition.
>
> [...]
>
> +static void mxf_set_essence_number(AVFormatContext *s)
> +{
> +MXFContext *mxf = s->priv_data;
> +AVStream *st;
> +int i, video_type = 0, audio_type = 0;
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +st = s->streams[i];
> +if (!video_type && st->codec->codec_type == CODEC_TYPE_VIDEO) {
> +mxf->video_container_ul =
> mxf_get_essence_container_ul(mxf_picture_essence_container_uls,
> st->codec->codec_id);
> +video_type++;
> +}
> +if (!audio_type && st->codec->codec_type == CODEC_TYPE_AUDIO) {
> +mxf->audio_container_ul =
> mxf_get_essence_container_ul(mxf_sound_essence_container_uls,
> st->codec->codec_id);
> +audio_type++;
> +}
> +if (video_type && audio_type)
> +break;
> +}
> +mxf->type_num = video_type + audio_type;
If we have more than one audio track and more than one video track, it
is possible for each track to have different essence containers, and it
is not specific to codec type I think.
So you must store them in a list, and check against codec_id only if
possible.
> +
> static int mxf_write_header_partition(AVFormatContext *s)
> {
> MXFContext *mxf = s->priv_data;
> ByteIOContext *pb = s->pb;
> int64_t header_metadata_start;
> -// for op1a, only 1 essence container
> -uint64_t partitionLen = 88 + 16;
> +
> +// calculate the numner of essence container type
> +mxf_set_essence_number(s);
I think the name is not right. I think mxf_get_essence_containers is a
better name.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2802 - mxf/mxfenc.c
Hi,
Reimar Döffinger wrote:
> Hello,
> I know this is a first version, and maybe you intend to change most
> things anyway, but I think I better point them out since fixing them
> later when they appear in even more place sure won't be easier.
>
> On Wed, Jul 16, 2008 at 06:39:42PM +0200, spyfeng wrote:
>> +static const uint8_t umid_base[] = {0x06, 0x0a, 0x2b, 0x34, 0x01, 0x01,
>> 0x01, 0x01, 0x01, 0x01, 0x0f, 0x00, 0x13, 0x00, 0x00, 0x00};//16 bytes
>
> Useless comment. People can count, or if you want to make it explicit,
> write it in the [] (you could then also drop the last 0 elements).
Yes.
>> +/* complete key */
>> +static const uint8_t op1a_ul[]= { 0x06, 0x0e, 0x2b, 0x34, 0x04,
>> 0x01, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x01, 0x01, 0x00 };
>> +static const uint8_t header_partition_key[]= { 0x06, 0x0e,
>> 0x2b, 0x34, 0x02, 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x02,
>> 0x04, 0x00 };//ClosedComplete
>> +static const uint8_t footer_partition_key[] = {0x06, 0x0e, 0x2b, 0x34,
>> 0x02, 0x05, 0x01, 0x01, 0x0d, 0x01, 0x02, 0x01, 0x01, 0x04, 0x04,
>> 0x00};//ClosedComplete
>
> Comments should be doxygen-compatible. Also, a one-word comment almost
> never has any value, at most for the author and that only for at most
> one year.
> There are also some very weird spaces, preferably it should be aligned
> so the '=' match.
>
>> +/* partial key for header metadata */
>
> Just repeating once more to make it clear ;-): (almost) all comments should
> be converted to be
> doxygen-compatible. Almost is the exception for comments that doxygen
> does not support, like inside functions.
> Also, (almost) all functions should have doxygen comments.
I absolutely agree with this, I'd though prefer the code to work before
spending time on comments :>
>> +#define PRINT_KEY(pc, s, x) dprintf(pc, "%s %02X %02X %02X %02X %02X %02X
>> %02X %02X %02X %02X %02X %02X %02X %02X %02X %02X\n", s, \
>> + (x)[0], (x)[1], (x)[2], (x)[3], (x)[4],
>> (x)[5], (x)[6], (x)[7], (x)[8], (x)[9], (x)[10], (x)[11], (x)[12], (x)[13],
>> (x)[14], (x)[15])
>
> I think this is also in the mxf demuxer (and probably some other stuff).
> That should be moved into some shared file.
Yes, that will be taken care of later, I'll extract common code.
>> +static void mxf_generate_uuid(AVFormatContext *s, UID uuid)
>> +{
>> +MXFContext *mxf = s->priv_data;
>> +int rand_num, i;
>> +
>> +for (i = 0; i < 16; i++) {
>> +rand_num = av_random(&mxf->random_state);
>> +rand_num = rand_num%256 + 1;
>
> That probably will need some checking. I have some doubts that av_random
> is suitable for this.
> With a constant initializer it certainly is quite pointless, and without
> it needs some extra case for bitexact.
Probably, if this is about uniqueness then pick on random at first, then
increment value.
> [...]
>
>> +ref = type == MaterialPackage ? set_ref->package : &
>> set_ref->package[1];
>
> ref = set_ref->package;
> if (type == MaterialPackage)
> ref++;
>
> seems much more readable to me.
Well, I'd prefer code to be, if correct and possible:
ref = &set_ref->package[type == MaterialPackage];
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] ALAC Testing Report
Benjamin Larsson wrote: > Baptiste Coudurier wrote: >> Hi Mike, >> >> Mike Melanson wrote: >>> Baptiste Coudurier wrote: >>>> Baptiste Coudurier wrote: >>>>> Hi Mike, >>>>> >>>>> Mike Melanson wrote: >>>>>> [...] >>>>>> >>>>>> *doesn't work* on my iPod Touch >>>>>> >>>>>> Methodology: >>>>>> >>>>>>ffmpeg -i -acodec alac dest.mov >>>>>> >>>>>> Problem: Specifying either dest.mp4 or dest.m4a does not work. It >>>>>> should. ALAC is supposed to be encapsulated in these formats and not in >>>>>> .mov, >>>>> Well, Quicktime player perfectly creates ALAC in .mov files, so I guess >>>>> it's obviously supposed to be encapsulated in .mov. >>>>> >>>>> Im afraid alac in .mp4 is definitely NON STANDARD. >>>>> You'll have to use -f ipod to be allowed to put ALAC in .m4a. >>>>> Im working on a patch. >>>>> >>>> Done, -acodec alac test.m4a should work, Mike can you please test it on >>>> your ipod/iphone ? Thanks a lot. >>> Still no go on the iPod, even though transcoding to .m4a now works. >>> >> Crap, with really latest svn ? Like r13744 ? It plays fine with >> quicktime player :( >> >> And with stream copy ? >> > > I tried on my Ipod video and the file worked. > Ok this is cool, and what if used with iTunes to transfer ? I damn need an ipod, hopefully I'll get a 3g iphone on july 11th ;) -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] ALAC Testing Report
Hi Mike, Mike Melanson wrote: > Baptiste Coudurier wrote: >> Baptiste Coudurier wrote: >>> Hi Mike, >>> >>> Mike Melanson wrote: >>>> [...] >>>> >>>> *doesn't work* on my iPod Touch >>>> >>>> Methodology: >>>> >>>>ffmpeg -i -acodec alac dest.mov >>>> >>>> Problem: Specifying either dest.mp4 or dest.m4a does not work. It >>>> should. ALAC is supposed to be encapsulated in these formats and not in >>>> .mov, >>> Well, Quicktime player perfectly creates ALAC in .mov files, so I guess >>> it's obviously supposed to be encapsulated in .mov. >>> >>> Im afraid alac in .mp4 is definitely NON STANDARD. >>> You'll have to use -f ipod to be allowed to put ALAC in .m4a. >>> Im working on a patch. >>> >> Done, -acodec alac test.m4a should work, Mike can you please test it on >> your ipod/iphone ? Thanks a lot. > > Still no go on the iPod, even though transcoding to .m4a now works. > Crap, with really latest svn ? Like r13744 ? It plays fine with quicktime player :( And with stream copy ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] ALAC Testing Report
Baptiste Coudurier wrote: > Hi Mike, > > Mike Melanson wrote: >> [...] >> >> *doesn't work* on my iPod Touch >> >> Methodology: >> >>ffmpeg -i -acodec alac dest.mov >> >> Problem: Specifying either dest.mp4 or dest.m4a does not work. It >> should. ALAC is supposed to be encapsulated in these formats and not in >> .mov, > > Well, Quicktime player perfectly creates ALAC in .mov files, so I guess > it's obviously supposed to be encapsulated in .mov. > > Im afraid alac in .mp4 is definitely NON STANDARD. > You'll have to use -f ipod to be allowed to put ALAC in .m4a. > Im working on a patch. > Done, -acodec alac test.m4a should work, Mike can you please test it on your ipod/iphone ? Thanks a lot. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] ALAC Testing Report
Hi Mike, Mike Melanson wrote: > [...] > > *doesn't work* on my iPod Touch > > Methodology: > >ffmpeg -i -acodec alac dest.mov > > Problem: Specifying either dest.mp4 or dest.m4a does not work. It > should. ALAC is supposed to be encapsulated in these formats and not in > .mov, Well, Quicktime player perfectly creates ALAC in .mov files, so I guess it's obviously supposed to be encapsulated in .mov. Im afraid alac in .mp4 is definitely NON STANDARD. You'll have to use -f ipod to be allowed to put ALAC in .m4a. Im working on a patch. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Smartjog USA Inc.http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2291 - wmapro/wma3dec.c
Hi,
faust3 wrote:
> Author: faust3
> Date: Sun Jun 1 11:34:48 2008
> New Revision: 2291
>
> Log:
> changed codec id to WMAPRO to be consistent with the rest of ffmpeg
>
> Modified:
>wmapro/wma3dec.c
>
> Modified: wmapro/wma3dec.c
> ==
> --- wmapro/wma3dec.c (original)
> +++ wmapro/wma3dec.c Sun Jun 1 11:34:48 2008
> @@ -235,7 +235,7 @@ AVCodec wmav3pro_decoder =
> {
> "wmav3Pro",
> CODEC_TYPE_AUDIO,
> -CODEC_ID_WMAV3PRO,
> +CODEC_ID_WMAPRO,
> sizeof(WMA3DecodeContext),
> wma3_decode_init,
> NULL,
I think WMAV3 is more consistent :>
Though what about lossless ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Extend TSMuxer to H264 muxing
On Mon, Apr 14, 2008 at 02:40:54PM +0800, zhentan feng wrote:
> [...]
>
> > > +if(st->codec->codec_id == CODEC_ID_H264){
> > > +H264Context * h_st = st->codec->priv_data;
> >
> > This is invalid, there is a reason why its called priv_data, and that is
> > that it is private to the codec.
>
> I think it is the key point to write descriptors into PMT for AVC stream.
> Can't I get the h264 codec information when init TS out stream?
> Do you mean the *priv_data* only could be used by libavcodec functions, we
> can't read some information from it by other extern functions?
> If so, I am a little confused how could I get information when init the
> descriptor?
>
No you cannot, only libavcodec h264 decoder is allowed to use priv_data,
TS muxer has to parse PPS/PPS and gather needed infos.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Extend TSMuxer to H264 muxing
Hi,
In addition to Michael's comments,
On Mon, Apr 14, 2008 at 01:52:41AM +0800, zhentan feng wrote:
> [...]
>
> +for(; buf_index + 3 < size; buf_index++){
> +if(buf[buf_index] == 0 && buf[buf_index+1] == 0 && buf[buf_index+2]
> == 1){
AUD nal unit type is 9, are you actually checking this ? Use AV_RB*.
> [...]
>
> +if(h_st->nal_unit_type == NAL_SPS){
> +*q++ = 0x28;
> +*q++ = 4;
> +*q++ = h_st->sps->profile_idc;
> +*q++ = 0;
> +*q++ = h_st->sps->level_idc;
> +*q++ = 0xc0;
> +// write HRD descriptor
> +if(h_st->sps->timing_info_present_flag){
> +*q++ = 0x2a;
> +*q++ = 8;
> +*q++ = 0x81;
> +*q++ = 0;//90khz_flag
Please add doxygen comments after constant values.
> +uint32_t ntick;
> +ntick = h_st->sps->num_units_in_tick;
> +*q++ = ntick >> 24;
> +*q++ = ntick >> 16;
> + *q++ = ntick >> 8;
> +*q++ = ntick;
See bytestream_put *
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] TS muxer extend to H264 muxing questiones
Hi, Michael Niedermayer wrote: > On Tue, Apr 08, 2008 at 05:50:23PM +0800, zhentan feng wrote: > [...] >> 2,beofre I write the H264 data from AVPacket to PES packet,sholud I parser >> the pkt->data to ensure it comply the constrains according to Annex >> B of ITU-T Rec. H.264 | >> ISO/IEC 14496-10. >> or just trust the data provied by AVPacket. > > The data in the AVPacket should be conformant to H264 annex B. > I think the question is more if AVPacket data contains AUD nal units, which is not common in other containers, is it ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312 ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [FFmpeg-devel] [Patch]GSoC 2008 qualification task TS Muxer
On Thu, Apr 03, 2008 at 09:42:37PM +0800, zhentan feng wrote: > [...] > > Sorry forget to attach the patch > Ok, applied with some cosmetics and doc modifications. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312 ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [FFmpeg-devel] [Patch]GSoC 2008 qualification task TS Muxer
Hi,
On Fri, Apr 04, 2008 at 01:50:18AM +0800, zhentan feng wrote:
> [...]
>
> --- ff_pes_cal_header_1/mpegpesenc.c 2008-04-03 21:32:51.0 +0800
> +++ 4.3/mpegpesenc.c 2008-04-04 01:41:44.0 +0800
> @@ -37,6 +37,7 @@
> for(i=0;inb_streams;i++) {
> st = ctx->streams[i];
> stream = st->priv_data;
> +stream->format = PES_FMT_TS;/* just initial for TS */
> av_set_pts_info(st, 64, 1, 9);
Separate patch.
> [...]
>
> switch(st->codec->codec_type) {
> @@ -397,9 +398,10 @@
> * Write packet into PES FIFO.
> * @param [in] ctx the AVFormatContext which contains streams.
> * @param [in] pkt the packet to write.
> + * @param [in] the pointer point to variable in PS struct
> * @return NULL
> */
> -void ff_pes_write_packet(AVFormatContext *ctx, AVPacket *pkt)
> +void ff_pes_write_packet(AVFormatContext *ctx, AVPacket *pkt, int
> *packet_number)
> {
Why a pointer ? Is the variable modified ?
> [...]
>
> /**
> * Find the stream to mux into the PES stream.
> diff -ur ff_pes_cal_header_1/mpegtsenc.c 4.3/mpegtsenc.c
> --- ff_pes_cal_header_1/mpegtsenc.c 2008-03-31 22:49:48.0 +0800
> +++ 4.3/mpegtsenc.c 2008-04-04 01:30:58.0 +0800
> @@ -630,7 +630,6 @@
> int general_pack = 0; /*"general" pack without data specific to one
> stream?*/
> int pes_size;
> uint8_t* q = stream->payload;
> -pes_stream->format = PES_FMT_TS;
>
Separate patch.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2089 - in dvbmuxer: mpegenc.c mpegpes.h mpegpesenc.c mpegtsenc.c
Michael Niedermayer wrote: > On Fri, Apr 04, 2008 at 01:07:56PM +0200, bcoudurier wrote: >> Author: bcoudurier >> Date: Fri Apr 4 13:07:56 2008 >> New Revision: 2089 >> >> Log: >> move common code to ff_pes_cal_header > > patch by ... or with modifications or your own work? > Sorry, message changed. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312 ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Extend TSMuxer to H264 muxing
Hi, zhentan feng wrote: > [...] > > New Add fields: > 1,AVC video descriptor > 2,AVC timing and HRD descriptor Those are worth to be added. Also We must ensure in some way that H264 bitstream contains AUD NAL units. > > (4)At last, how do I test the code works right for H264 muxing? > Tank you for any advice. > Well for now, use VLC to play back streams, but justify all your changes by the specs. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312 ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [FFmpeg-devel] [Patch]GSoC 2008 qualification task TS Muxer
Hi,
On Mon, Mar 31, 2008 at 11:18:07PM +0800, zhentan feng wrote:
> [...]
>
> Index: mpegpes.h
> ===
> --- mpegpes.h (revision 2048)
> +++ mpegpes.h (working copy)
> @@ -30,6 +30,12 @@
> #include "avformat.h"
> #include "fifo.h"
>
> +#define PES_FMT_MPEG2 0x01
> +#define PES_FMT_VCD 0x02
> +#define PES_FMT_SVCD 0x04 | PES_FMT_MPEG2
> +#define PES_FMT_DVD 0x08 | PES_FMT_MPEG2
> +#define PES_FMT_TS 0x10 | PES_FMT_MPEG2
> +
Yes, but problem now is that == PES_FMT_TS is causing problems,
and gcc warns you about it. So you should directly merge values I guess.
> [...]
>
> Index: mpegpesenc.c
> ===
> --- mpegpesenc.c (revision 2048)
> +++ mpegpesenc.c (working copy)
> @@ -100,7 +100,109 @@
>
> return nb_frames;
> }
> +/**
> + * Caculate the PES header to flush
> + * @param[in] idthe stream id
> + * @param[in] streamthe PES stream
> + * @param[in] packet_sizethe packet size for PES
> + * @param[in] header_len the PES header length
> + * @param[in] ptsthe PTS
> + * @param[in] dts the DTS
> + * @param[in] payload_size the PES palyload size
> + * @param[in] startcode the startcode
> + * @param[in]stuffing_size the PES stuff size
> + * @param[in] trailer_size the trailer_ size
> + * @param[in] pad_packet_bytes the padding size for packet
> + * @return NULL
> + */
> +void ff_pes_cal_header(int id,PESStream * stream,
> + int *packet_size,int *header_len,int64_t *pts,int64_t *dts,
> +int *payload_size,int *startcode,int *stuffing_size,
> + int *trailer_size,int *pad_packet_bytes)
> +{
> + /* packet header size */
> +*packet_size -= 6;
>
> +/* packet header */
> +if (stream->format & PES_FMT_MPEG2){
> + *header_len = 3;
> + if (stream->packet_number==0)
> + *header_len += 3; /* PES extension */
You don't check for TS here ? Old code is not checking this.
Are you sure it is correct ? Did you test it ?
Except that patch is ok.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [FFmpeg-devel] [Patch]GSoC 2008 qualification task TS Muxer
On Mon, Mar 31, 2008 at 12:48:00AM +0800, zhentan feng wrote:
> [...]
>
> >
> > > +/*just consider dvd and mpeg2 for ff_pes_cal_header()*/
> > > +if(s->is_mpeg2){
> > > +stream->format = FMT_MPEG2;
> > > +if(s->is_dvd)
> > > +stream->format = FMT_DVD | FMT_MPEG2;
> > > +}
> > > id = stream->id;
> > >
> >
> > You must get rid of is_mpeg and is_dvd if you have FMT_*
> > Btw, after rethinking, PES_FMT_* is more appropriate.
> >
> well, I remove the assignments to "stream->format" to the function
> mpeg_mux_init().
> you can find it in the new patch.
> Since is_dvd and is_mpeg2 appear many times in mpeg_mux_init(), at the
> same time,PESStream haven't been initialized, so I think we cannot get
> rid of is_dvd and is_mpeg2.Moreover, they are variables in
> MpegMuxContext and may be used in somewhere else.
Having a format field in MpexMuxContext and in StreamInfo, is not that bad IMHO,
still it merges 5 fields into one, but yes, this could be done separately.
>
> > Furthermore, the new mechanism can be added separately, it is non
> > functionnal.
> > So this means the patch must be separate.
> >
> > > [...]
> > >
> > > Index: mpegpes.h
> > > ===
> > > --- mpegpes.h (revision 2048)
> > > +++ mpegpes.h (working copy)
> > > @@ -30,6 +30,12 @@
> > > #include "avformat.h"
> > > #include "fifo.h"
> > >
> > > +#define FMT_MPEG2 0x01
> > > +#define FMT_VCD 0x02
> > > +#define FMT_SVCD 0x04
> > > +#define FMT_DVD 0x08
> > > +#define FMT_TS 0x10
> > > +
> >
> > SVCD/DVD/TS are MPEG2 so you can add FMT_MPEG2 to constants.
> >
> > This will avoid some checks.
>
> fixed.
Well, why don't you always define TS as MPEG2 ?
> [...]
>
> +void ff_pes_cal_header(int id,PESStream * stream,
> + int *packet_size,int *header_len,int64_t *pts,int64_t *dts,
> +int *payload_size,int *startcode,int *stuffing_size,
> + int *trailer_size,int *pad_packet_bytes)
> +{
> + /* packet header size */
> +*packet_size -= 6;
>
> +/* packet header */
> +if (stream->format & PES_FMT_TS) {
> +*header_len = 3;
> +*header_len += 1; /* obligatory stuffing byte */
> +}else if (stream->format & PES_FMT_MPEG2){
> + *header_len = 3;
> + if (stream->packet_number==0)
> + *header_len += 3; /* PES extension */
> + *header_len += 1; /* obligatory stuffing byte */
> +} else {
> + *header_len = 0;
> +}
This can be merged in & PES_FMT_MPEG2 case.
> [...]
>
> +*pts=*dts=AV_NOPTS_VALUE;
> +*header_len -= timestamp_len;
> +if ((stream->format & PES_FMT_DVD) && stream->align_iframe){
> +*pad_packet_bytes += timestamp_len;
> +*packet_size -= timestamp_len;
> +}
> +else {
> +*payload_size += timestamp_len;
> + }
> +*stuffing_size += timestamp_len;
> +if(*payload_size > *trailer_size)
> +*stuffing_size += *payload_size - *trailer_size;
> +}
Indentation looks weird.
> [...]
>
> int pes_size;
> uint8_t* q = stream->payload;
> +pes_stream->format = PES_FMT_TS|PES_FMT_MPEG2;
>
See top comment.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [FFmpeg-devel] [Patch]GSoC 2008 qualification task TS Muxer
Hi,
On Sun, Mar 30, 2008 at 02:28:35AM +0800, zhentan feng wrote:
> 2008/3/28, Baptiste Coudurier <[EMAIL PROTECTED]>:
> > Hi,
> >
> >
> > On Thu, Mar 27, 2008 at 10:52:09PM +0800, zhentan feng wrote:
> > > Index: mpegenc.c
> > > ===
> >
> > > --- mpegenc.c (revision 2048)
> > > +++ mpegenc.c (working copy)
> > > @@ -266,11 +266,13 @@
> > > static int mpeg_mux_init(AVFormatContext *ctx)
> > > {
> >
> > > MpegMuxContext *s = ctx->priv_data;
> >
> > > -int bitrate, i, mpa_id, mpv_id, mps_id, ac3_id, dts_id, lpcm_id, j;
> > > +int bitrate, i;
> > > AVStream *st;
> > > PESStream *stream;
> > > int audio_bitrate;
> > > int video_bitrate;
> > > +int *ps_audio_bound = &(s->audio_bound);
> > > +int *ps_video_bound = &(s->video_bound);
> > >
> > > [...]
> >
> > >
> > > +if(ff_pes_muxer_init(ctx,ps_audio_bound,ps_video_bound) != 0)
> > >
> >
> >
> > Code seems to only count audio and video streams, I don't think
> > ff_pes_muxer_init needs to be extented, only count them in
> > mpeg_mux_init (a small for loop should do the trick).
> >
> yes.
> ps_audio_bound, and ps_video_bound are just flags to keep off TS can
> not execute some codes when call the function ff_pes_muxer_init().
> I review the codes again , find mepg_mux_init() in mpegenc.c and
> mpegts_write_header() in mpegtsenc.c actually have small common codes.
>
Well, you can use !(stream->format & PES_FMT_TS)
> Moreover, mpegtsenc.c initial the stream data as below:
> for(i=0;inb_streams;i++) {
> st = ctx->streams[i];
> stream = st->priv_data;
>
> but mpegenc.c initial the stream like this:
> for(i=0;inb_streams;i++) {
> st = ctx->streams[i];
> stream = av_mallocz(sizeof(StreamInfo));
> if (!stream)
> goto fail;
> st->priv_data = stream;
>
> Thus, I think it is stiff resued without flags to sign PS or TS stream.
> So, I leave it just as svn-soc original.
Uniformizing code is always welcome if you think it is worth, but as always
clean and seperate patches.
> > > [...]
> > >
> > > + */
> > > +void ff_pes_cal_header(int ps_flag,int *is_mpeg2,int *is_dvd,int
> > id,PESStream *stream,
> > > + int *packet_size,int *header_len,int64_t *pts,int64_t *dts,
> > > + int *payload_size,int *startcode,int *stuffing_size,
> > > + int *trailer_size,int *pad_packet_bytes);
> > > +
> > > +/**
> > >
> >
> > I think some flags should be used for different variants:
> >
> > #define FMT_MPEG2 0x01
> > #define FMT_VCD 0x02 | FMT_MPEG2
> > #define FMT_SVCD 0x04 | FMT_MPEG2
> > #define FMT_DVD 0x08 | FMT_MPEG2
> > #define FMT_TS0x10 | FMT_MPEG2
> >
> > then add a "format" field in PESStream.
> >
> > You will be able to check with (s->format & FMT_MPEG2).
> >
> > Beware of mpeg1system muxer though.
> >
> > It should be simpler and cleaner, and will avoid passing 3 args.
> >
> > This needs a separate patch.
>
> The patch names "ff_pes_cal_header_3-29.patch" show the changes.
>
> [...]
>
> +/*just consider dvd and mpeg2 for ff_pes_cal_header()*/
> +if(s->is_mpeg2){
> +stream->format = FMT_MPEG2;
> +if(s->is_dvd)
> +stream->format = FMT_DVD | FMT_MPEG2;
> +}
> id = stream->id;
>
You must get rid of is_mpeg and is_dvd if you have FMT_*
Btw, after rethinking, PES_FMT_* is more appropriate.
Furthermore, the new mechanism can be added separately, it is non functionnal.
So this means the patch must be separate.
> [...]
>
> Index: mpegpes.h
> ===
> --- mpegpes.h (revision 2048)
> +++ mpegpes.h (working copy)
> @@ -30,6 +30,12 @@
> #include "avformat.h"
> #include "fifo.h"
>
> +#define FMT_MPEG2 0x01
> +#define FMT_VCD 0x02
> +#define FMT_SVCD 0x04
> +#define FMT_DVD 0x08
> +#define FMT_TS 0x10
> +
SVCD/DVD/TS are MPEG2 so you can add FMT_MPEG2 to constants.
This will avoid some checks.
> [...]
>
> +/* packet header */
> +if (!(stream->format & FMT_TS)) {
> +*header_len = 3;
> +*header_len += 1; /* obligatory stuffing byte */
> +
