[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for mlp/truehd
Signed-off-by: Jai Luthra --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7e8298..f1f991d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -196,7 +196,7 @@ Codecs: mdec.cMichael Niedermayer mimic.c Ramiro Polla mjpeg*.c Michael Niedermayer - mlp* Ramiro Polla + mlp* Ramiro Polla, Jai Luthra mmvideo.c Peter Ross mpeg12.c, mpeg12data.hMichael Niedermayer mpegvideo.c, mpegvideo.h Michael Niedermayer -- 2.7.4 (Apple Git-66) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] [PATCH 2/2] mlpenc: Working MLP/TrueHD encoder
On Sat, Sep 17, 2016 at 05:07:28PM +0100, Andy Furniss wrote: > Nice work, this is just a sort of related question really from a user > who hasn't taken any notice of TrueHD for a few years. > > Last I looked I couldn't find much in the way of specs for TrueHD and > noticed that the Decoder didn't have anything related to dynamic range > control. > > Is there more info about now? > > IIRC testing decoder - (depending on content) for downmix or 2 channel > sub stream the absence of DRC was a bit of a show stopper in that full > range can be way too much. The AC3 version of course did have DRC meta > and ffmpeg would correctly fully apply it for downmix, so for a stereo > listener like me AC3 = good, TrueHD (or DTS) = bad. The proprietary suite for TrueHD does support dynamic range compression, but I'm unsure if (and where) the metadata for DRC is present in the bitstream. The bitstream isn't fully reversed yet, just enough to get things working. I think this is a very useful feature for downmixed substream to sound good, so I'll try to figure it out in my spare time. Cheers, -- darkapex ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/opengl: use SDL2
W dniu niedziela, 18 września 2016 Lou Logan > napisał(a): > On Sat, Sep 17, 2016, at 05:21 PM, Lukasz Marek wrote: > > On 18 September 2016 at 00:30, Josh de Kock wrote: > [...] > >> Would like some feedback where it doesnt work etc > [...] > > I said I will patch opengl, your implemantation donsn't look good at this > > point, declined, > > It would be helpful to provide some details describing what exactly does > not look good. > ___ opengl device depends on opengl context. this patch works on sdl renderer which works on X. in many cases X is opengł so patch is working for many cases, but is shity in general. > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]
Hi, On Sat, Sep 17, 2016 at 4:26 PM, Marton Balint wrote: > I think we should wait until Lukasz does the port of the opengl device to > SDL2, and do the switch after that. When do we think that'll be finished? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/opengl: use SDL2
On Sat, Sep 17, 2016, at 05:21 PM, Lukasz Marek wrote: > On 18 September 2016 at 00:30, Josh de Kock wrote: [...] >> Would like some feedback where it doesnt work etc [...] > I said I will patch opengl, your implemantation donsn't look good at this > point, declined, It would be helpful to provide some details describing what exactly does not look good. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]
On Thu, Sep 15, 2016 at 02:36:32PM -0300, James Almer wrote: > There have been some complains from developers about keeping both > SDL1 and SDL2 support at the same time even after all SDL1 code > has been already ported, and especially since it makes maintaining > ffplay more complex, so seeing the waters are divided I think the > best solution will be to vote. Are there any developers currently depending on SDL1 in a way that they cannot upgrade to SDL2 ? Are debian old stable and Ubuntu 12.04 the only still maintained affected distros ? When SDL1 is replaced by SDL2 some announcment should be made, that should contain instructions on how users of affected distros can update to SDL2. (maybe as a link to sdl2 packages where they exist or a link to our wiki where we also document how other 3rd party libs can be build) I dont want to tell our users "You must use a release for SDL support" and then when they submit a bugreport or patch tell them "You must use latest git master" We want bug reports and patches against git master, always, we should ensure git master works always I vote for listening to our users and fellow developers and resolving any issues a SDL1->SDL2 switch would have for them and once resolved to drop SDL1 Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/opengl: use SDL2
On 18 September 2016 at 00:30, Josh de Kock wrote:
> I did this in about 5 minutes, and only tested it with one sample (on
> OSX using the cocoa opengl renderer). Seems to work, but probably
> won't for all cases. Would like some feedback where it doesnt work etc
>
> Signed-off-by: Josh de Kock
> ---
> libavdevice/opengl_enc.c | 87 +-
> --
> 1 file changed, 46 insertions(+), 41 deletions(-)
>
> diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
> index 1dbbb80..1917459 100644
> --- a/libavdevice/opengl_enc.c
> +++ b/libavdevice/opengl_enc.c
> @@ -46,7 +46,7 @@
> #include
> #endif
>
> -#if HAVE_SDL
> +#if HAVE_SDL2
> #include
> #endif
>
> @@ -174,8 +174,10 @@ static const GLushort g_index[6] =
> typedef struct OpenGLContext {
> AVClass *class;///< class for private options
>
> -#if HAVE_SDL
> -SDL_Surface *surface;
> +#if HAVE_SDL2
> +SDL_Texture *texture;
> +SDL_Window *window;
> +SDL_Renderer *renderer;
>
I said I will patch opengl, your implemantation donsn't look good at this
point, declined,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add CONTRIBUTING.md
On 9/17/2016 8:42 PM, Josh de Kock wrote: > TimothyGu (https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-143274708) > suggested doing this a while ago, but it was never done. As pull requests > seem to be still coming through, I thought I'd send a patch to add the notice. > > Signed-off-by: Josh de Kock > --- > CONTRIBUTING.md | 4 > 1 file changed, 4 insertions(+) > create mode 100644 CONTRIBUTING.md > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > new file mode 100644 > index 000..c2b79e4 > --- /dev/null > +++ b/CONTRIBUTING.md > @@ -0,0 +1,4 @@ > +# Note to Github users > +Patches should be submitted to the [ffmpeg-devel mailing > list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git > format-patch` or `git send-email`. Github pull requests should be avoided > because they are not part of our review process and **will be ignored**. The wording here is different to the notice in README.md, so make it either "will be ignored" or "will likely be ignored" in both. This patch should be ok in any case. > + > +See > [https://ffmpeg.org/developer.html#Contributing](https://ffmpeg.org/developer.html#Contributing) > for more information. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add CONTRIBUTING.md
> Am 18.09.2016 um 01:42 schrieb Josh de Kock : > > TimothyGu (https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-143274708) > suggested doing this a while ago, but it was never done. As pull requests > seem to be still coming through, I thought I'd send a patch to add the notice. > > Signed-off-by: Josh de Kock > --- > CONTRIBUTING.md | 4 > 1 file changed, 4 insertions(+) > create mode 100644 CONTRIBUTING.md > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > new file mode 100644 > index 000..c2b79e4 > --- /dev/null > +++ b/CONTRIBUTING.md > @@ -0,0 +1,4 @@ > +# Note to Github users > +Patches should be submitted to the [ffmpeg-devel mailing > list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git > format-patch` or `git send-email`. Github pull requests should be avoided > because they are not part of our review process and **will be ignored**. > + > +See > [https://ffmpeg.org/developer.html#Contributing](https://ffmpeg.org/developer.html#Contributing) > for more information. > -- LGTM -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
On Sun, Sep 18, 2016 at 01:00:01AM +0200, Paul B Mahol wrote:
> On 9/17/16, Michael Niedermayer wrote:
> > On Sat, Sep 17, 2016 at 03:06:57PM +0200, Carl Eugen Hoyos wrote:
> >> 2016-09-15 20:48 GMT+02:00 Michael Niedermayer :
> >> > On Thu, Sep 15, 2016 at 03:47:49PM +0200, Carl Eugen Hoyos wrote:
> >> >> 2016-09-15 15:42 GMT+02:00 Michael Niedermayer
> >> >> :
> >> >> >> -{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
> >> >> >> /* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID?
> >> >> >> */
> >> >> >> { AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
> >> >> >> { AV_CODEC_ID_NONE, 0 },
> >> >> >
> >> >> > does this affect adpcm_swf in nut ?
> >> >>
> >> >> Yes, indeed.
> >> >>
> >> >> Is it possible to fix adpcm_swf in wav?
> >> >
> >> > maybe if block_align is set (and is constant)
> >>
> >> Attached fixes encoding, decoding still has the issue
> >> that the decoder doesn't like more than one packet.
> >> (Iiuc, it works if I limit the packet size in the wav demuxer.)
> >>
> >> Carl Eugen
> >
> >> adpcmenc.c |1 +
> >> 1 file changed, 1 insertion(+)
> >> dccfa2d54e899c17dcb57b8e37658955dfa6ea9c
> >> 0001-lavc-adpcmenc-Set-block_align-for-adpcm_swf.patch
> >> From 168bc2f828ffd7f85c0db736e6097e4198854c5d Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos
> >> Date: Sat, 17 Sep 2016 15:01:19 +0200
> >> Subject: [PATCH] lavc/adpcmenc: Set block_align for adpcm_swf.
> >>
> >> ---
> >> libavcodec/adpcmenc.c |1 +
> >> 1 file changed, 1 insertion(+)
> >
> > LGTM
> >
> > can you add a fate test?
>
> This patch is invalid. Block align should be set to what ADPCM_SWF
> uses in adpcm_encode_frame as pkt_size.
yes
> And ADPCM_SWF should not be special, it should use block_align as pkt_size.
yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: VAAPI video processing filter
Can't find SKL available now, just run the test in IVY(Ivybridge)/Debian 8.5/ Kernel 3.16.0/Libva master/intel-driver master/ffmpeg master - Build config: ./configure --enable-libx264 --enable-gpl --enable-vaapi --prefix=/opt/ffmpeg - Libva and intel-driver barry@barry:~/Source/video/ffmpeg$ vainfo libva info: VA-API version 0.39.3 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/yami/vaapi/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.3.pre1) vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 1.7.3.pre1 (1.7.0-118-gb5cd299) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Simple: VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD - Kernel and distribution barry@barry:~/Source/video/ffmpeg$ uname -a Linux barry 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux barry@barry:~/Source/video/ffmpeg$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.5 (jessie) Release:8.5 Codename: jessie - Test result a). denoise -> scale [With the patch adding vf_process_vaapi] ./ffmpeg_g -y -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i ../yami/ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 'format=vaapi|nv12,hwupload,process_vaapi=denoise=50,scale_vaapi=w=1280:h=720' -c:v h264_vaapi -qp 20 out_denoise_scale.mp4 121 fps b). scale -> denosie [With the patch adding vf_process_vaapi] ./ffmpeg_g -y -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i ../yami/ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 'format=vaapi|nv12,hwupload,scale_vaapi=w=1280:h=720,process_vaapi=denoise=50' -c:v h264_vaapi -qp 20 out_scale_denoise.mp4 169 fps c). scale + denosie in all [patch to vf_scale_vaapi] ./ffmpeg_g -y -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i ../yami/ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 'format=vaapi|nv12,hwupload,scale_vaapi=w=1280:h=720:denoise=50' -c:v h264_vaapi -qp 20 out_all.mp4 139 fps d). scale without denoise ./ffmpeg_g -y -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i ../yami/ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 'format=vaapi|nv12,hwupload,scale_vaapi=w=1280:h=720' -c:v h264_vaapi -qp 20 out_scale.mp4 254 fps I will try this after find the SKL. :) On 2016/9/14 6:06, Mark Thompson wrote: > WIP. > --- > On 05/09/16 02:52, Jun Zhao wrote: >> On 2016/8/31 6:48, Mark Thompson wrote: >>> On 30/08/16 09:00, Jun Zhao wrote: v3 : fix sharpless mapping issue v2 : fix filter support flag check logic issue >>> >>> Hi, >>> >>> A general remark to start: vf_scale_vaapi is named to be a scaling filter >>> (i.e. it replaces vf_scale/swscale for AV_PIX_FMT_VAAPI) - is this >>> therefore really the right place to be adding other operations unrelated to >>> scaling? >>> >>> Do use-cases for these operations actually make sense to add here rather >>> than in a separate filter? (I'm not sure what the answer to this should be >>> - I would definitely argue that the deinterlacer should be a separate >>> filter, but these other operations are unclear.) >>> >>> >> >> As you know, VPP use the pipeline mode, split the >> scale/denoise/sharpness/... in >> different filter maybe is not good idea, I guess nobody want to call >> vaRenderPicture()/ >> vaEndpicture/... again and again in >> vf_scale_vaapi.c/vf_denosie_vaapi.c/vf_sharpness_vaapi.c/... > > How about something like this, then? It adds a new filter to do the video > processing, while leaving the scale filter as-is. > > Implements denoise, sharpen and all of the colour balance controls; lightly > tested but seems working on i965/Skylake. > > Outstanding issues: > * The name is not very good, but I can't think of anything better. > * Needs more testing. > * Some error recovery is missing. > * Documentation. > * Reuses the surface pool from the input hw_frames_ctx - is anything going
[FFmpeg-devel] [PATCH] Add CONTRIBUTING.md
TimothyGu (https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-143274708) suggested doing this a while ago, but it was never done. As pull requests seem to be still coming through, I thought I'd send a patch to add the notice. Signed-off-by: Josh de Kock --- CONTRIBUTING.md | 4 1 file changed, 4 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000..c2b79e4 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,4 @@ +# Note to Github users +Patches should be submitted to the [ffmpeg-devel mailing list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git format-patch` or `git send-email`. Github pull requests should be avoided because they are not part of our review process and **will be ignored**. + +See [https://ffmpeg.org/developer.html#Contributing](https://ffmpeg.org/developer.html#Contributing) for more information. -- 2.8.4 (Apple Git-73) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: refine EXT-X-BYTERANGE support for segments
2016-09-18 1:07 GMT+08:00 Michael Niedermayer :
> On Sat, Sep 17, 2016 at 01:09:02PM +0800, Steven Liu wrote:
> [...]
> > @@ -867,6 +886,16 @@ static int hls_write_header(AVFormatContext *s)
> > for (i = 0; i < s->nb_streams; i++) {
> > AVStream *inner_st;
> > AVStream *outer_st = s->streams[i];
> > +
> > +if (hls->max_seg_size > 0) {
> > +if ((outer_st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
> &&
> > +outer_st->codecpar->bit_rate > hls->max_seg_size) {
> > +av_log(s, AV_LOG_WARNING, "Your video bitrate is bigger
> than hls_segment_size, "
> > + "%lld > %lld ( video birate > hls_segment_size
> ),the result maybe not you want.",
> > + outer_st->codecpar->bit_rate, hls->max_seg_size);
>
> %lld is the wrong type for *int64_t
>
> The compiler should produce a warning for this, though probably not
> every copiler does
> please make sure your changes add no warnings
>
Hi Michael,
Bellow is my compile history before i send the last patch mail, maybe i
need cross complie cross any platform:
localhost:xxx StevenLiu$ make
CC libavformat/hlsenc.o
src/libavformat/hlsenc.c:326:14: error: use of undeclared identifier 'st'
if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
^
src/libavformat/hlsenc.c:327:13: error: use of undeclared identifier 'st'
st->codecpar->bit_rate > hls->max_seg_size) {
^
src/libavformat/hlsenc.c:330:20: error: use of undeclared identifier 'st'
st->codecpar->bit_rate, hls->max_seg_size);
^
src/libavformat/hlsenc.c:573:27: warning: absolute value function 'abs'
given an argument of type 'long' but has parameter of type 'int' which may
cause truncation of value [-Wabsolute-value]
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^
src/libavformat/hlsenc.c:573:27: note: use function 'labs' instead
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^~~
labs
1 warning and 3 errors generated.
make: *** [libavformat/hlsenc.o] Error 1
localhost:xxx StevenLiu$ make
CC libavformat/hlsenc.o
src/libavformat/hlsenc.c:564:27: warning: absolute value function 'abs'
given an argument of type 'long' but has parameter of type 'int' which may
cause truncation of value [-Wabsolute-value]
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^
src/libavformat/hlsenc.c:564:27: note: use function 'labs' instead
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^~~
labs
src/libavformat/hlsenc.c:890:18: error: use of undeclared identifier 'st'
if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
^
src/libavformat/hlsenc.c:891:17: error: use of undeclared identifier 'st'
st->codecpar->bit_rate > hls->max_seg_size) {
^
src/libavformat/hlsenc.c:894:24: error: use of undeclared identifier 'st'
st->codecpar->bit_rate, hls->max_seg_size);
^
1 warning and 3 errors generated.
make: *** [libavformat/hlsenc.o] Error 1
localhost:xxx StevenLiu$
localhost:xxx StevenLiu$
localhost:xxx StevenLiu$ make
CC libavformat/hlsenc.o
src/libavformat/hlsenc.c:564:27: warning: absolute value function 'abs'
given an argument of type 'long' but has parameter of type 'int' which may
cause truncation of value [-Wabsolute-value]
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^
src/libavformat/hlsenc.c:564:27: note: use function 'labs' instead
tz_min = (abs(wrongsecs - tt) + 30) / 60;
^~~
labs
1 warning generated.
AR libavformat/libavformat.a
LD ffmpeg_g
CP ffmpeg
STRIP ffmpeg
LD ffplay_g
CP ffplay
STRIP ffplay
LD ffprobe_g
CP ffprobe
STRIP ffprobe
LD ffserver_g
CP ffserver
STRIP ffserver
localhost:xxx StevenLiu$
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
On 9/17/16, Michael Niedermayer wrote:
> On Sat, Sep 17, 2016 at 03:06:57PM +0200, Carl Eugen Hoyos wrote:
>> 2016-09-15 20:48 GMT+02:00 Michael Niedermayer :
>> > On Thu, Sep 15, 2016 at 03:47:49PM +0200, Carl Eugen Hoyos wrote:
>> >> 2016-09-15 15:42 GMT+02:00 Michael Niedermayer
>> >> :
>> >> >> -{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
>> >> >> /* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID?
>> >> >> */
>> >> >> { AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
>> >> >> { AV_CODEC_ID_NONE, 0 },
>> >> >
>> >> > does this affect adpcm_swf in nut ?
>> >>
>> >> Yes, indeed.
>> >>
>> >> Is it possible to fix adpcm_swf in wav?
>> >
>> > maybe if block_align is set (and is constant)
>>
>> Attached fixes encoding, decoding still has the issue
>> that the decoder doesn't like more than one packet.
>> (Iiuc, it works if I limit the packet size in the wav demuxer.)
>>
>> Carl Eugen
>
>> adpcmenc.c |1 +
>> 1 file changed, 1 insertion(+)
>> dccfa2d54e899c17dcb57b8e37658955dfa6ea9c
>> 0001-lavc-adpcmenc-Set-block_align-for-adpcm_swf.patch
>> From 168bc2f828ffd7f85c0db736e6097e4198854c5d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Sat, 17 Sep 2016 15:01:19 +0200
>> Subject: [PATCH] lavc/adpcmenc: Set block_align for adpcm_swf.
>>
>> ---
>> libavcodec/adpcmenc.c |1 +
>> 1 file changed, 1 insertion(+)
>
> LGTM
>
> can you add a fate test?
This patch is invalid. Block align should be set to what ADPCM_SWF
uses in adpcm_encode_frame as pkt_size.
And ADPCM_SWF should not be special, it should use block_align as pkt_size.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
2016-09-17 18:26 GMT+02:00 Michael Niedermayer : >> >> Is it possible to fix adpcm_swf in wav? >> > >> > maybe if block_align is set (and is constant) >> >> Attached fixes encoding, decoding still has the issue >> that the decoder doesn't like more than one packet. >> (Iiuc, it works if I limit the packet size in the wav demuxer.) >> adpcmenc.c |1 + >> 1 file changed, 1 insertion(+) >> dccfa2d54e899c17dcb57b8e37658955dfa6ea9c >> 0001-lavc-adpcmenc-Set-block_align-for-adpcm_swf.patch >> From 168bc2f828ffd7f85c0db736e6097e4198854c5d Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Sat, 17 Sep 2016 15:01:19 +0200 >> Subject: [PATCH] lavc/adpcmenc: Set block_align for adpcm_swf. >> >> --- >> libavcodec/adpcmenc.c |1 + >> 1 file changed, 1 insertion(+) > > LGTM It unfortunately still needs a decoder fix that I may not be able to provide, I tested by reducing MAX_SIZE in wavdec.c Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/opengl: use SDL2
I did this in about 5 minutes, and only tested it with one sample (on
OSX using the cocoa opengl renderer). Seems to work, but probably
won't for all cases. Would like some feedback where it doesnt work etc
Signed-off-by: Josh de Kock
---
libavdevice/opengl_enc.c | 87 +---
1 file changed, 46 insertions(+), 41 deletions(-)
diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index 1dbbb80..1917459 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -46,7 +46,7 @@
#include
#endif
-#if HAVE_SDL
+#if HAVE_SDL2
#include
#endif
@@ -174,8 +174,10 @@ static const GLushort g_index[6] =
typedef struct OpenGLContext {
AVClass *class;///< class for private options
-#if HAVE_SDL
-SDL_Surface *surface;
+#if HAVE_SDL2
+SDL_Texture *texture;
+SDL_Window *window;
+SDL_Renderer *renderer;
#endif
FFOpenGLFunctions glprocs;
@@ -341,12 +343,18 @@ static int opengl_control_message(AVFormatContext *h, int
type, void *data, size
return AVERROR(ENOSYS);
}
-#if HAVE_SDL
+#if HAVE_SDL2
static int opengl_sdl_recreate_window(OpenGLContext *opengl, int width, int
height)
{
-opengl->surface = SDL_SetVideoMode(width, height,
- 32, SDL_OPENGL | SDL_RESIZABLE);
-if (!opengl->surface) {
+int ret;
+if ((ret = SDL_CreateWindowAndRenderer(width, height, 0, &opengl->window,
+ &opengl->renderer)) < 0)
+return ret;
+
+opengl->texture = SDL_CreateTexture(opengl->renderer,
SDL_PIXELFORMAT_ARGB,
+SDL_TEXTUREACCESS_STREAMING, width,
height);
+
+if (!opengl->texture) {
av_log(opengl, AV_LOG_ERROR, "Unable to set video mode: %s\n",
SDL_GetError());
return AVERROR_EXTERNAL;
}
@@ -363,8 +371,7 @@ static int opengl_sdl_process_events(AVFormatContext *h)
int ret;
OpenGLContext *opengl = h->priv_data;
SDL_Event event;
-SDL_PumpEvents();
-while (SDL_PeepEvents(&event, 1, SDL_GETEVENT, SDL_ALLEVENTS) > 0) {
+while (SDL_PollEvent(&event) > 0) {
switch (event.type) {
case SDL_QUIT:
return AVERROR(EIO);
@@ -375,24 +382,23 @@ static int opengl_sdl_process_events(AVFormatContext *h)
return AVERROR(EIO);
}
return 0;
-case SDL_VIDEORESIZE: {
-char buffer[100];
-int reinit;
-AVDeviceRect message;
-/* clean up old context because SDL_SetVideoMode may lose its
state. */
-SDL_VideoDriverName(buffer, sizeof(buffer));
-reinit = !av_strncasecmp(buffer, "quartz", sizeof(buffer));
-if (reinit) {
-opengl_deinit_context(opengl);
-}
-if ((ret = opengl_sdl_recreate_window(opengl, event.resize.w,
event.resize.h)) < 0)
-return ret;
-if (reinit && (ret = opengl_init_context(opengl)) < 0)
-return ret;
-message.width = opengl->surface->w;
-message.height = opengl->surface->h;
-return opengl_control_message(h, AV_APP_TO_DEV_WINDOW_SIZE,
&message, sizeof(AVDeviceRect));
+case SDL_WINDOWEVENT:
+switch(event.window.event){
+case SDL_WINDOWEVENT_SIZE_CHANGED:
+case SDL_WINDOWEVENT_RESIZED: {
+AVDeviceRect message;
+if ((ret = opengl_sdl_recreate_window(opengl,
event.window.data1, event.window.data2)) < 0)
+return ret;
+if ((SDL_QueryTexture(opengl->texture, NULL, NULL,
&message.width, &message.height)) < 0)
+return ret;
+return opengl_control_message(h, AV_APP_TO_DEV_WINDOW_SIZE,
&message, sizeof(AVDeviceRect));
+}
+default:
+break;
}
+break;
+default:
+break;
}
}
return 0;
@@ -401,7 +407,6 @@ static int opengl_sdl_process_events(AVFormatContext *h)
static int av_cold opengl_sdl_create_window(AVFormatContext *h)
{
int ret;
-char buffer[100];
OpenGLContext *opengl = h->priv_data;
AVDeviceRect message;
if (SDL_Init(SDL_INIT_VIDEO)) {
@@ -411,10 +416,10 @@ static int av_cold
opengl_sdl_create_window(AVFormatContext *h)
if ((ret = opengl_sdl_recreate_window(opengl, opengl->window_width,
opengl->window_height)) < 0)
return ret;
-av_log(opengl, AV_LOG_INFO, "SDL driver: '%s'.\n",
SDL_VideoDriverName(buffer, sizeof(buffer)));
-message.width = opengl->surface->w;
-message.height = opengl->surface->h;
-SDL_WM_SetCaption(opengl->window_title, NULL);
+av_log(opengl, AV_LOG_INFO, "SDL driver: '%s'.\n",
SDL_GetCurrentVideoDriver());
+if ((ret = SDL_QueryTexture(opengl->texture, NULL, NULL, &messa
Re: [FFmpeg-devel] Resurrection of ffserver
Hello Rostislav, what are, in your oppinion, the biggest problems in ffserver? (I would like to hear other oppinions a well ;-) ) Missing FATE and usage of internal / deprecated API are known to me, but it seems that you have more generic problems with ffserver? Personally I must admit that I'm very confident with ffserver at the user side of view. For me, the configuration style was easy to unterstand and I didn't observed any crashes or problems - despite using it with cygwin under Windows(!) and having 6 feeds in parallel. I think the most applied usecase for ffserver is to use it as a streaming server for webcams, for which many simple tutorials can be found on the web. And this "just works" ;) Best regards, Michael ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17.09.2016 22:27, Rostislav Pehlivanov wrote: > >> Good day, >> >> I read the sad news about ffservers a few days ago and have already >> written some mails to ffmpeg-user. >> >> I would like to step in to make ffserver maintainable and distributable >> again, especially because of the many users depending on ffserver - >> including myself. I'm capable of C and had made some tiny changes to ffmpeg >> already, but I'm a beginner regarding the architecture and "unwritten >> rules" of ffmpeg development. Additionally, I would like to discuss >> strategic decisions with the main developers to avoid useless work. >> >> >> > I really think ffserver is better off being in a separate repository. That > way there'd be some finer attention brought to keeping the API usable by > external users too. Same with the rest of the programs. > So yeah, if you want, just make a separate repository somewhere with only > ffserver.c and a configure + makefile and try to make something better and > usable. This sounds very good. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17/09/2016 22:22, Michael Fritscher wrote: Hello, The other programs will probably be exported elsewhere sometime in the future, for now since ffserver is getting removed having it put someplace else is a good starting point. My idea was to have the 2 repositories "ffmpeg-main" with the libraries and "ffmpeg-tools" with all of the ff* programs, to have a clear seperation. Personally I think that having an own repo for every single tool does not have much advantages. But it could be an idea to have the ffmpeg-tools repo started with ffserver and let the other tools do the move to this repo later. I really like the idea of moving ffserver to another repo (and eventually the other tools), it would help for keeping API usage cleaner, and maybe highlight some cases where the API needs to be extended or changed etc. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
Hello, > The other programs will probably be exported elsewhere sometime in the > future, for now since ffserver is getting removed having it put someplace > else is a good starting point. My idea was to have the 2 repositories "ffmpeg-main" with the libraries and "ffmpeg-tools" with all of the ff* programs, to have a clear seperation. Personally I think that having an own repo for every single tool does not have much advantages. But it could be an idea to have the ffmpeg-tools repo started with ffserver and let the other tools do the move to this repo later. Best regards, Michael -- ZfT - Zentrum für Telematik e.V. Michael Fritscher Magdalene-Schoch-Straße 5 97074 Würzburg Tel: +49 (931) 615 633 - 57 Fax: +49 (931) 615 633 - 11 Email: michael.fritsc...@telematik-zentrum.de Web: http://www.telematik-zentrum.de Vorstand: Prof. Dr. Klaus Schilling, Hans-Joachim Leistner Sitz: Gerbrunn USt.-ID Nr.: DE 257 244 580, Steuer-Nr.: 257/111/70203 Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/dvdsubdec: ignore h <= 1 case, to properly decode subtitle
Fixes #5825.
Regression since: 3f0a3e9e127d067c5cf65640a44765c1ddd01622.
Signed-off-by: Paul B Mahol
---
libavcodec/dvdsubdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 19f25f0..b81b481 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -368,7 +368,7 @@ static int decode_dvd_subtitles(DVDSubContext *ctx,
AVSubtitle *sub_header,
h = y2 - y1 + 1;
if (h < 0)
h = 0;
-if (w > 0 && h > 0) {
+if (w > 0 && h > 1) {
reset_rects(sub_header);
sub_header->rects = av_mallocz(sizeof(*sub_header->rects));
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17.09.2016 23:10, Rostislav Pehlivanov wrote: On 17 September 2016 at 22:04, Lukasz Marek wrote: Yeah, no. You can hardly say ffserver is a perfect program right now, so really moving it to another repo is hardly much of a change in terms of functionality. Bisection won't matter if half the program needs to be rewritten to make it good. And the future of ffm mux/demux is the same as the future of ffserver. And besides none of this even matters because ffserver's getting deleted. You can't stop it. This was decided long ago. It's in the news. It won't get better overnight. This email thread is now about whether someone wants to maintain it somewhere else, which doesn't concern the project other than having people who are interested in contributing to something like that. I didn't know it is decided to delete it. In such case I have no objections. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17 September 2016 at 21:34, Michael Fritscher < michael.fritsc...@telematik-zentrum.de> wrote: > Hello Rostislav, > > I really think ffserver is better off being in a separate repository. > That > > way there'd be some finer attention brought to keeping the API usable by > > external users too. Same with the rest of the programs. > So, if I unterstand you correctly, your vision is to move all ff* > programs to external repositories (or one) for a better seperation of > library and tools/programs? Personally, I think that could be a good > idea - but way out of my scope ;-) I don't want to make a such big > disruption as my first action to ffmpeg *g* > > Best regards, > Michael > > -- > ZfT - Zentrum für Telematik e.V. > Michael Fritscher > Magdalene-Schoch-Straße 5 > 97074 Würzburg > Tel: +49 (931) 615 633 - 57 > Fax: +49 (931) 615 633 - 11 > Email: michael.fritsc...@telematik-zentrum.de > Web: http://www.telematik-zentrum.de > > Vorstand: > Prof. Dr. Klaus Schilling, Hans-Joachim Leistner > Sitz: Gerbrunn > USt.-ID Nr.: DE 257 244 580, Steuer-Nr.: 257/111/70203 > Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > The other programs will probably be exported elsewhere sometime in the future, for now since ffserver is getting removed having it put someplace else is a good starting point. It's simpler than you might think, since all you need right now is to cut enough from ffserver.c to make it compile with just the regular library headers. All you need then is a makefile and you'd be good. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17 September 2016 at 22:04, Lukasz Marek wrote: > On 17.09.2016 22:27, Rostislav Pehlivanov wrote: > >> On 17 September 2016 at 20:58, Michael Fritscher < >> michael.fritsc...@telematik-zentrum.de> wrote: >> >> Good day, >>> >>> I read the sad news about ffservers a few days ago and have already >>> written some mails to ffmpeg-user. >>> >>> I would like to step in to make ffserver maintainable and distributable >>> again, especially because of the many users depending on ffserver - >>> including myself. I'm capable of C and had made some tiny changes to >>> ffmpeg >>> already, but I'm a beginner regarding the architecture and "unwritten >>> rules" of ffmpeg development. Additionally, I would like to discuss >>> strategic decisions with the main developers to avoid useless work. >>> >>> I really think ffserver is better off being in a separate repository. >> That >> way there'd be some finer attention brought to keeping the API usable by >> external users too. Same with the rest of the programs. >> So yeah, if you want, just make a separate repository somewhere with only >> ffserver.c and a configure + makefile and try to make something better and >> usable. >> > > I don't want to declare my statement here what should be done, but there > is one more thing you didn't mention. ffserver depends on some specific > components located inside ffmpeg libraries. At least on ffm mux/demux. They > cannot be moved. The problem is, people sometimes opens ticket with error > report like that: "I used version X, released about year ago and it worked > fine. Now I upgraded and it doesn't work" Keeping it everything in one repo > allows you to use bisection to find where the problem were introduced. > Where you keep it in separate repositories it become much more complex. Now > when you move back in repo history, you know all tools will compile (unless > some commits are pushed in wrong order), when you have more repositories > then you have to correlate it. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Yeah, no. You can hardly say ffserver is a perfect program right now, so really moving it to another repo is hardly much of a change in terms of functionality. Bisection won't matter if half the program needs to be rewritten to make it good. And the future of ffm mux/demux is the same as the future of ffserver. And besides none of this even matters because ffserver's getting deleted. You can't stop it. This was decided long ago. It's in the news. It won't get better overnight. This email thread is now about whether someone wants to maintain it somewhere else, which doesn't concern the project other than having people who are interested in contributing to something like that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17.09.2016 22:27, Rostislav Pehlivanov wrote: On 17 September 2016 at 20:58, Michael Fritscher < michael.fritsc...@telematik-zentrum.de> wrote: Good day, I read the sad news about ffservers a few days ago and have already written some mails to ffmpeg-user. I would like to step in to make ffserver maintainable and distributable again, especially because of the many users depending on ffserver - including myself. I'm capable of C and had made some tiny changes to ffmpeg already, but I'm a beginner regarding the architecture and "unwritten rules" of ffmpeg development. Additionally, I would like to discuss strategic decisions with the main developers to avoid useless work. I really think ffserver is better off being in a separate repository. That way there'd be some finer attention brought to keeping the API usable by external users too. Same with the rest of the programs. So yeah, if you want, just make a separate repository somewhere with only ffserver.c and a configure + makefile and try to make something better and usable. I don't want to declare my statement here what should be done, but there is one more thing you didn't mention. ffserver depends on some specific components located inside ffmpeg libraries. At least on ffm mux/demux. They cannot be moved. The problem is, people sometimes opens ticket with error report like that: "I used version X, released about year ago and it worked fine. Now I upgraded and it doesn't work" Keeping it everything in one repo allows you to use bisection to find where the problem were introduced. Where you keep it in separate repositories it become much more complex. Now when you move back in repo history, you know all tools will compile (unless some commits are pushed in wrong order), when you have more repositories then you have to correlate it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]
On 9/17/2016 5:26 PM, Marton Balint wrote: > > On Fri, 16 Sep 2016, Ronald S. Bultje wrote: > >> Hi folks, >> >> On Thu, Sep 15, 2016 at 1:36 PM, James Almer wrote: >> >>> The vote will end 1 week from now, simple majority wins, and >>> it's open only to those in the voting committee[1]. >>> Marton Balint, while not in the committee, should IMO also >>> have the chance to vote or at least comment since he's the >>> main ffplay maintainer. > > I think I am in the committee, it got extended, and I got in, somebody surely > can find the reference... You're right, i missed the second extension. Sorry. https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html We should probably put the list in the website or somewhere easily accessible, so people don't have to dig old emails. There was also a third attempt to extend it but it seems it wasn't well received because many of the suggestions were either devs long gone or that had minimal infrastructure roles not related to the core development of the project. Unless I'm missing something, that one went nowhere and the above mail is the most recent approved list. And IMO, since it's been a year now it could be revised and some of those names suggested again, but that's another discussion. > I'd rather drop SDL1, there are times when we bump the minimal version > requirements of external libraries, this is not that different. > > On the other hand, if others do the work of maintaining the old sdl1 version > of ffplay and the devices, I don't really mind having them around for a few > more months, but I don't think it is necessary. This is somewhat ambiguous, so before the voting is done it would be great if you can make your vote clear :P > > I think we should wait until Lukasz does the port of the opengl device to > SDL2, and do the switch after that. > > Regards, > Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
Hello Rostislav, > I really think ffserver is better off being in a separate repository. That > way there'd be some finer attention brought to keeping the API usable by > external users too. Same with the rest of the programs. So, if I unterstand you correctly, your vision is to move all ff* programs to external repositories (or one) for a better seperation of library and tools/programs? Personally, I think that could be a good idea - but way out of my scope ;-) I don't want to make a such big disruption as my first action to ffmpeg *g* Best regards, Michael -- ZfT - Zentrum für Telematik e.V. Michael Fritscher Magdalene-Schoch-Straße 5 97074 Würzburg Tel: +49 (931) 615 633 - 57 Fax: +49 (931) 615 633 - 11 Email: michael.fritsc...@telematik-zentrum.de Web: http://www.telematik-zentrum.de Vorstand: Prof. Dr. Klaus Schilling, Hans-Joachim Leistner Sitz: Gerbrunn USt.-ID Nr.: DE 257 244 580, Steuer-Nr.: 257/111/70203 Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resurrection of ffserver
On 17 September 2016 at 20:58, Michael Fritscher < michael.fritsc...@telematik-zentrum.de> wrote: > Good day, > > I read the sad news about ffservers a few days ago and have already > written some mails to ffmpeg-user. > > I would like to step in to make ffserver maintainable and distributable > again, especially because of the many users depending on ffserver - > including myself. I'm capable of C and had made some tiny changes to ffmpeg > already, but I'm a beginner regarding the architecture and "unwritten > rules" of ffmpeg development. Additionally, I would like to discuss > strategic decisions with the main developers to avoid useless work. > > > I really think ffserver is better off being in a separate repository. That way there'd be some finer attention brought to keeping the API usable by external users too. Same with the rest of the programs. So yeah, if you want, just make a separate repository somewhere with only ffserver.c and a configure + makefile and try to make something better and usable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]
On Fri, 16 Sep 2016, Ronald S. Bultje wrote: Hi folks, On Thu, Sep 15, 2016 at 1:36 PM, James Almer wrote: The vote will end 1 week from now, simple majority wins, and it's open only to those in the voting committee[1]. Marton Balint, while not in the committee, should IMO also have the chance to vote or at least comment since he's the main ffplay maintainer. I think I am in the committee, it got extended, and I got in, somebody surely can find the reference... Marton, it sounds like your opinion is valued. Penny for your thoughts? :) I'd rather drop SDL1, there are times when we bump the minimal version requirements of external libraries, this is not that different. On the other hand, if others do the work of maintaining the old sdl1 version of ffplay and the devices, I don't really mind having them around for a few more months, but I don't think it is necessary. I think we should wait until Lukasz does the port of the opengl device to SDL2, and do the switch after that. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]
On Fri, 16 Sep 2016 14:48:03 +0200 Carl Eugen Hoyos wrote: > 2016-09-16 14:21 GMT+02:00 Rostislav Pehlivanov : > > > I'd rather have SDL1 support dropped. ffplay is the only thing on my > > machine which uses libsdl1.2 > > And we already (everybody) agreed that we want to switch to SDL2 > so that you (and others) do not have to use (or depend on) sdl1 > anymore. > But this is an entirely different question that is completely unrelated > to your installation: > Do we allow developers to continue to use sdl1 to test on their > old (but supported) Linux distributions or do we forcibly stop > them from contributing here? If that developer is apparently unable to update his system, then yes, kick him out. 10 people not wanting to use SDL1 surely counts more than 1 person being too goddamn obstinate not to install SDL2 (or too incompetent to do that?) I'm always amazed by these absurdities. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Resurrection of ffserver
Good day, I read the sad news about ffservers a few days ago and have already written some mails to ffmpeg-user. I would like to step in to make ffserver maintainable and distributable again, especially because of the many users depending on ffserver - including myself. I'm capable of C and had made some tiny changes to ffmpeg already, but I'm a beginner regarding the architecture and "unwritten rules" of ffmpeg development. Additionally, I would like to discuss strategic decisions with the main developers to avoid useless work. Clement already gave my a list of todos: * FATE integration * Kill using of internal API / headers (the libavformat/*.h seem to be most urgent - leaving only avformat.h) * Kill using of deprecated API * Long time maintainment I would be more then happy if there would be some commitment that ffserver could stay if these todos are fulfilled. I'll try to be rather conservative, at least for the first time until I feel more comfortable with the code, the architecture and the workflows. Ideas for better configuration style (honestly, personally I like the current style) etc. can be done when the basic work is done ;-) I already looked around a bit and have a few questions: About using internal APIs: One troublesome thing seems to be the rtsp server. ffserver seems to do much of the rtsp server himself, but uses e.g. RTSPMessageHeader from libavformat/rtsp.h. I see four possibilities: 1. Leave it as-is. 2. Copy the definitions to ffserver. 3. Use the official API. But if I read http://www.ffmpeg.org/ffmpeg-protocols.html#rtsp correctly, libavformat can only act as a RTSP-client (but both sending and receiving)? 4. If this is not possible, make an "official" RTSP server related API. For possibilities 3 and 4 I would need some support: For 3. some insight how to use the API (as I said, I found nothing about a RTSP server in the library). For 4. I would need some advice where to put the API and how the API should look like. E.g. can I use the rtsp_* functions in ffserver.c as a base? Should it be completely different? I can live with all of the 4 mentioned solutions - but I want to have an opinion of some main developers ;-) Regarding deprecated API: Can I rely on the @deprecated flag or is there a list? Best regards, Michael Fritscher -- ZfT - Zentrum für Telematik e.V. Michael Fritscher Magdalene-Schoch-Straße 5 97074 Würzburg Tel: +49 (931) 615 633 - 57 Fax: +49 (931) 615 633 - 11 Email: michael.fritsc...@telematik-zentrum.de Web: http://www.telematik-zentrum.de Vorstand: Prof. Dr. Klaus Schilling, Hans-Joachim Leistner Sitz: Gerbrunn USt.-ID Nr.: DE 257 244 580, Steuer-Nr.: 257/111/70203 Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: refine EXT-X-BYTERANGE support for segments
On Sat, Sep 17, 2016 at 01:09:02PM +0800, Steven Liu wrote:
[...]
> @@ -867,6 +886,16 @@ static int hls_write_header(AVFormatContext *s)
> for (i = 0; i < s->nb_streams; i++) {
> AVStream *inner_st;
> AVStream *outer_st = s->streams[i];
> +
> +if (hls->max_seg_size > 0) {
> +if ((outer_st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
> +outer_st->codecpar->bit_rate > hls->max_seg_size) {
> +av_log(s, AV_LOG_WARNING, "Your video bitrate is bigger than
> hls_segment_size, "
> + "%lld > %lld ( video birate > hls_segment_size ),the
> result maybe not you want.",
> + outer_st->codecpar->bit_rate, hls->max_seg_size);
%lld is the wrong type for *int64_t
The compiler should produce a warning for this, though probably not
every copiler does
please make sure your changes add no warnings
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer
Le jour du Génie, an CCXXIV, Paul B Mahol a écrit : > Why we need this hack? I think I already gave an answer. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer
On 9/17/16, Stefano Sabatini wrote: > On date Sunday 2016-09-04 23:25:56 +0200, Michael Niedermayer encoded: >> On Sun, Sep 04, 2016 at 06:24:37PM +0200, Stefano Sabatini wrote: >> > From: Nicolas George >> > >> > With several modifications and documentation by Stefano Sabatini >> > . >> > >> > Signed-off-by: Nicolas George >> > --- >> > doc/ffprobe-format.texi | 130 >> > libavformat/Makefile | 1 + >> > libavformat/allformats.c | 2 + >> > libavformat/ffprobedec.c | 397 >> > +++ >> > 4 files changed, 530 insertions(+) >> > create mode 100644 doc/ffprobe-format.texi >> > create mode 100644 libavformat/ffprobedec.c >> >> this seems not to apply cleanly >> >> can i pick this from some git repo ? (should work better than patch >> with unavailable ancestors) > > Updated, this should apply cleanly on master. Why we need this hack? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer
On date Sunday 2016-09-04 23:25:56 +0200, Michael Niedermayer encoded:
> On Sun, Sep 04, 2016 at 06:24:37PM +0200, Stefano Sabatini wrote:
> > From: Nicolas George
> >
> > With several modifications and documentation by Stefano Sabatini
> > .
> >
> > Signed-off-by: Nicolas George
> > ---
> > doc/ffprobe-format.texi | 130
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 2 +
> > libavformat/ffprobedec.c | 397
> > +++
> > 4 files changed, 530 insertions(+)
> > create mode 100644 doc/ffprobe-format.texi
> > create mode 100644 libavformat/ffprobedec.c
>
> this seems not to apply cleanly
>
> can i pick this from some git repo ? (should work better than patch
> with unavailable ancestors)
Updated, this should apply cleanly on master.
--
FFmpeg = Fast and Fast Monstrous Power Elected Game
>From bd026e67a4876cff4e50edfb7f0958c87eacbef0 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer
With several modifications and documentation by Stefano Sabatini
.
Signed-off-by: Nicolas George
---
doc/ffprobe-format.texi | 130
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/ffprobedec.c | 397 +++
4 files changed, 529 insertions(+)
create mode 100644 doc/ffprobe-format.texi
create mode 100644 libavformat/ffprobedec.c
diff --git a/doc/ffprobe-format.texi b/doc/ffprobe-format.texi
new file mode 100644
index 000..be7af15
--- /dev/null
+++ b/doc/ffprobe-format.texi
@@ -0,0 +1,130 @@
+@chapter ffprobe demuxer format
+@c man begin FFPROBE DEMUXER FORMAT
+
+The ffprobe demuxer format is inspired by the output generated by the
+ffprobe default format.
+
+It consists of several sections (FORMAT, STREAM, PACKET). Each section
+starts with a single line in the format @samp{[SECTION]} and ends with
+the corresponding line @samp{[/SECTION]}.
+
+where @samp{SECTION} is the name of the section.
+
+A well-formed file consists of an initial @samp{FORMAT} section,
+followed by several @samp{STREAM} sections (one per stream), and
+several @samp{PACKET} sections.
+
+Each section contains a sequence of lines in the form
+@sample{key=value}. In the case of data the key and the value must
+stay on different lines.
+
+Unrecognized values are discarded (this allows the demuxer to accept
+the output generated by @program{ffprobe} without further
+modifications.
+
+The following sections document the fields accepted by each section.
+
+@section FORMAT
+
+@table
+@item nb_streams
+the number of supported streams
+@end table
+
+@section STREAM
+@table
+@item index
+the index number
+@item codec_name
+the codec name (the name must be an accepted FFmpeg codec name
+@item time_base
+Specify the time_base as @samp{NUM/DEN}, this is the time base used to
+specify the timestamps in the corresponding packets
+@end table
+
+@section PACKET
+
+@table
+@item stream_index
+the stream index of the stream (must have been specified in a stream
+section). If not specified the first stream is assumed.
+
+@item pts
+the PTS expressed in the corresponding time base stream units
+
+@item pts_time
+the PTS expressed as an absolute time, using the FFmpeg time syntax
+
+@item dts
+the DTS expressed in the corresponding time base stream units
+
+@item pts_time
+the DTS expressed as an absolute time, using the FFmpeg time syntax
+
+@item duration
+the duration expressed in the corresponding time base stream units
+
+@item duration_tim
+the packet duration expressed as an absolute time, using the FFmpeg time syntax
+
+@item flags
+If the value is equal to "K" mark the packet as a key packet
+
+@item data
+specifies the data as a sequence of hexadecimal values (two
+hexadecimal values specify a byte). The data specification starts on
+the following line and can span over several lines, and must be
+terminated by an empty line. Spaces within each line are discarded.
+@end table
+
+@section Examples
+
+A ffprobe demuxer file might look like this:
+@example
+[FORMAT]
+nb_streams=1
+format_name=ffprobe_default
+[/FORMAT]
+[STREAM]
+index=0
+codec_name=timed_id3
+time_base=1/100
+[/STREAM]
+[PACKET]
+stream_index=0
+pts_time=0
+dts_time=0
+duration=N/A
+flags=K
+data=
+f000 0167 42c0 1ed9 81b1 fefc 0440
+57ff d7d1 dfff e11a 3d7e 6cbd 0001
+ce8c 4d9d 108e 25e9 fe
+
+[/PACKET]
+[PACKET]
+stream_index=0
+pts_time=1.00
+duration=N/A
+flags=K
+data=
+f000 0141 9a38 3be5 fffa
+ebc1 3782 7d5e 21e9 abf2 ea4f ed66
+ 0001 ce8c 4d9d 108e 25e9 fe
+
+[/PACKET]
+@end example
+
+The output generated by the @program{ffprobe} default format is valid
+if the following options are also specified:
+@example
+-show_packets -show_data -show_compact_data -show_format -show_streams -show_packets -show_headers_first
+@end example
+
+Thus, to generate the corresponding output from an input file you
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
On Sat, Sep 17, 2016 at 03:06:57PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-15 20:48 GMT+02:00 Michael Niedermayer :
> > On Thu, Sep 15, 2016 at 03:47:49PM +0200, Carl Eugen Hoyos wrote:
> >> 2016-09-15 15:42 GMT+02:00 Michael Niedermayer :
> >> >> -{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
> >> >> /* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID? */
> >> >> { AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
> >> >> { AV_CODEC_ID_NONE, 0 },
> >> >
> >> > does this affect adpcm_swf in nut ?
> >>
> >> Yes, indeed.
> >>
> >> Is it possible to fix adpcm_swf in wav?
> >
> > maybe if block_align is set (and is constant)
>
> Attached fixes encoding, decoding still has the issue
> that the decoder doesn't like more than one packet.
> (Iiuc, it works if I limit the packet size in the wav demuxer.)
>
> Carl Eugen
> adpcmenc.c |1 +
> 1 file changed, 1 insertion(+)
> dccfa2d54e899c17dcb57b8e37658955dfa6ea9c
> 0001-lavc-adpcmenc-Set-block_align-for-adpcm_swf.patch
> From 168bc2f828ffd7f85c0db736e6097e4198854c5d Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sat, 17 Sep 2016 15:01:19 +0200
> Subject: [PATCH] lavc/adpcmenc: Set block_align for adpcm_swf.
>
> ---
> libavcodec/adpcmenc.c |1 +
> 1 file changed, 1 insertion(+)
LGTM
can you add a fate test?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] [PATCH 2/2] mlpenc: Working MLP/TrueHD encoder
Jai Luthra wrote: * Multichannel support for TrueHD is experimental There should be downmix substreams present for 2+ channel bitstreams, but ffmpeg decoder doesn't need it. Will add support for this soon. Nice work, this is just a sort of related question really from a user who hasn't taken any notice of TrueHD for a few years. Last I looked I couldn't find much in the way of specs for TrueHD and noticed that the Decoder didn't have anything related to dynamic range control. Is there more info about now? IIRC testing decoder - (depending on content) for downmix or 2 channel sub stream the absence of DRC was a bit of a show stopper in that full range can be way too much. The AC3 version of course did have DRC meta and ffmpeg would correctly fully apply it for downmix, so for a stereo listener like me AC3 = good, TrueHD (or DTS) = bad. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: bump micro (after adding TrueHD and MLP encoders)
On 9/17/16, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/version.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/version.h b/libavcodec/version.h > index ecd48c5..ccb2890 100644 > --- a/libavcodec/version.h > +++ b/libavcodec/version.h > @@ -28,7 +28,7 @@ > #include "libavutil/version.h" > > #define LIBAVCODEC_VERSION_MAJOR 57 > -#define LIBAVCODEC_VERSION_MINOR 56 > +#define LIBAVCODEC_VERSION_MINOR 57 > #define LIBAVCODEC_VERSION_MICRO 100 > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ > -- > 2.9.3 Topic/log should be: bump minor Otherwise LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc: bump micro (after adding TrueHD and MLP encoders)
Signed-off-by: Rostislav Pehlivanov --- libavcodec/version.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/version.h b/libavcodec/version.h index ecd48c5..ccb2890 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -28,7 +28,7 @@ #include "libavutil/version.h" #define LIBAVCODEC_VERSION_MAJOR 57 -#define LIBAVCODEC_VERSION_MINOR 56 +#define LIBAVCODEC_VERSION_MINOR 57 #define LIBAVCODEC_VERSION_MICRO 100 #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
2016-09-15 20:48 GMT+02:00 Michael Niedermayer :
> On Thu, Sep 15, 2016 at 03:47:49PM +0200, Carl Eugen Hoyos wrote:
>> 2016-09-15 15:42 GMT+02:00 Michael Niedermayer :
>> >> -{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
>> >> /* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID? */
>> >> { AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
>> >> { AV_CODEC_ID_NONE, 0 },
>> >
>> > does this affect adpcm_swf in nut ?
>>
>> Yes, indeed.
>>
>> Is it possible to fix adpcm_swf in wav?
>
> maybe if block_align is set (and is constant)
Attached fixes encoding, decoding still has the issue
that the decoder doesn't like more than one packet.
(Iiuc, it works if I limit the packet size in the wav demuxer.)
Carl Eugen
From 168bc2f828ffd7f85c0db736e6097e4198854c5d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 17 Sep 2016 15:01:19 +0200
Subject: [PATCH] lavc/adpcmenc: Set block_align for adpcm_swf.
---
libavcodec/adpcmenc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 36974fd..8cf0d67 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -138,6 +138,7 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
goto error;
}
avctx->frame_size = 512 * (avctx->sample_rate / 11025);
+avctx->block_align = (256 * avctx->channels * avctx->sample_rate / 11025) + 1 + 2 * avctx->channels;
break;
default:
ret = AVERROR(EINVAL);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC][PATCH v2 2/2] mlpenc: Working MLP/TrueHD encoder
On 30 August 2016 at 11:23, Jai Luthra wrote: > * Multichannel support for TrueHD is experimental > > There should be downmix substreams present for 2+ channel bitstreams, > but ffmpeg decoder doesn't need it. Will add support for this soon. > > * There might be lossless check failures on LFE channels > > * 32-bit sample support has been removed for now, will add it later > > While testing, some samples gave lossless check failures when enforcing > s32. Probably this will also get solved with the LFE issues. > > Signed-off-by: Jai Luthra > --- > > > a fate test could also be added > > sure. i will add it in a separate patch later. > > libavcodec/Makefile|2 + > libavcodec/allcodecs.c |4 +- > libavcodec/mlp.c | 21 + > libavcodec/mlp.h | 40 + > libavcodec/mlpenc.c| 2416 ++ > ++ > 5 files changed, 2481 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/mlpenc.c > Pushed! Thanks a lot! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ass_split: improve handling of complex ASS features
On Sat, Sep 10, 2016 at 03:45:31AM -0500, Rodger Combs wrote:
> Specifically:
> - Skip writing drawings as text
> - Convert \h to a Unicode non-breaking space
> - Ignore comments and unknown tags
>
> The test references are update to reflect these changes.
> ---
> libavcodec/ass_split.c | 29 +
> tests/ref/fate/sub-textenc | 12 ++--
> tests/ref/fate/sub-webvttenc | 12 ++--
> 3 files changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c
> index beaba7e..b25a0f3 100644
> --- a/libavcodec/ass_split.c
> +++ b/libavcodec/ass_split.c
> @@ -477,30 +477,37 @@ int ff_ass_split_override_codes(const ASSCodesCallbacks
> *callbacks, void *priv,
> const char *text = NULL;
> char new_line[2];
> int text_len = 0;
> +int drawing = 0;
>
> while (buf && *buf) {
> if (text && callbacks->text &&
> -(sscanf(buf, "\\%1[nN]", new_line) == 1 ||
> - !strncmp(buf, "{\\", 2))) {
> -callbacks->text(priv, text, text_len);
> +(sscanf(buf, "\\%1[nNh]", new_line) == 1 ||
> + *buf == '{')) {
> +if (!drawing)
> +callbacks->text(priv, text, text_len);
> text = NULL;
> }
> -if (sscanf(buf, "\\%1[nN]", new_line) == 1) {
> +if (buf[0] == '\\' && buf[1] == 'h') {
> +callbacks->text(priv, "\u00A0", 2);
> +buf += 2;
> +} else if (sscanf(buf, "\\%1[nN]", new_line) == 1) {
> if (callbacks->new_line)
> callbacks->new_line(priv, new_line[0] == 'N');
> buf += 2;
> -} else if (!strncmp(buf, "{\\", 2)) {
> -buf++;
> +} else if (*buf == '{' && strchr(buf, '}')) {
> +buf += strcspn(buf, "\\}"); // skip comments
> while (*buf == '\\') {
> char style[2], c[2], sep[2], c_num[2] = "0", tmp[128] = {0};
> unsigned int color = 0x;
> -int len, size = -1, an = -1, alpha = -1;
> +int len = 2, size = -1, an = -1, alpha = -1;
> int x1, y1, x2, y2, t1 = -1, t2 = -1;
> if (sscanf(buf, "\\%1[bisu]%1[01\\}]%n", style, c, &len) >
> 1) {
> int close = c[0] == '0' ? 1 : c[0] == '1' ? 0 : -1;
> len += close != -1;
> if (callbacks->style)
> callbacks->style(priv, style[0], close);
> +} else if (sscanf(buf, "\\p%u%1[\\}]%n", &size, sep, &len) >
> 1) {
> +drawing = (size > 0);
> } else if (sscanf(buf, "\\c%1[\\}]%n", sep, &len) > 0 ||
> sscanf(buf, "\\c&H%X&%1[\\}]%n", &color, sep,
> &len) > 1 ||
> sscanf(buf, "\\%1[1234]c%1[\\}]%n", c_num, sep,
> &len) > 1 ||
> @@ -543,13 +550,11 @@ int ff_ass_split_override_codes(const ASSCodesCallbacks
> *callbacks, void *priv,
> } else if (sscanf(buf, "\\org(%d,%d)%1[\\}]%n", &x1, &y1,
> sep, &len) > 2) {
> if (callbacks->origin)
> callbacks->origin(priv, x1, y1);
> -} else {
> -len = strcspn(buf+1, "\\}") + 2; /* skip unknown code */
> }
> buf += len - 1;
> +buf += strcspn(buf, "\\}"); // skip comments
> }
> -if (*buf++ != '}')
> -return AVERROR_INVALIDDATA;
> +buf++; // skip }
is it really always certain to have a '}'?
> } else {
> if (!text) {
> text = buf;
> @@ -559,7 +564,7 @@ int ff_ass_split_override_codes(const ASSCodesCallbacks
> *callbacks, void *priv,
> buf++;
> }
> }
> -if (text && callbacks->text)
> +if (text && callbacks->text && !drawing)
> callbacks->text(priv, text, text_len);
> if (callbacks->end)
> callbacks->end(priv);
> diff --git a/tests/ref/fate/sub-textenc b/tests/ref/fate/sub-textenc
> index f7d82ce..2d7236e 100644
> --- a/tests/ref/fate/sub-textenc
> +++ b/tests/ref/fate/sub-textenc
> @@ -152,7 +152,7 @@ text 2
> 00:00:52,501 --> 00:00:54,500
> Hide these tags:
> also hide these tags:
> -but show this: {normal text}
> +but show this:
this sounds wrong
[...]
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/http: remove duplicate user-agent option
On Fri, Sep 16, 2016 at 10:43:30AM +0800, Steven Liu wrote: > From: Steven Liu > Date: Fri, 16 Sep 2016 10:42:34 +0800 > Subject: [PATCH] avformat/http: will remove option user_agent > > add a FF_OPT_FLAG_DEPRECATED define for compile. > add a new variable for user_agent to give a deprecated warning message > --- > doc/protocols.texi| 4 +++- > libavformat/http.c| 13 - > libavformat/version.h | 3 +++ > 3 files changed, 18 insertions(+), 2 deletions(-) Adjusted commit message and applied. Thanks. -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/softfloat_ieee754: make all functions inline
Am 16.09.16 um 11:44 schrieb Michael Niedermayer: > On Thu, Sep 15, 2016 at 11:08:47PM -0300, James Almer wrote: >> Removes "defined but not used" warnings >> >> Signed-off-by: James Almer >> --- >> libavutil/softfloat_ieee754.h | 14 +++--- >> 1 file changed, 7 insertions(+), 7 deletions(-) > > iam not the author/maintainer, but patch looks ok to me Most likely there is a reason but is there not the av_always_inline macro? -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VDD2016] Technical Discussion Results
Am 12.09.16 um 12:01 schrieb Paul B Mahol: > On 9/12/16, Thilo Borgmann wrote: >> Hi, >> >> these are the resulting notes we've taken during the FFmpeg technical >> discussion >> during VDD 2016. We've ended up with two slides on the board and compn took >> pictures of them. You can find them here: >> >> https://drive.google.com/drive/folders/0B53tgCAS2uUnVUpZN0U1WDE0MzQ?usp=sharing >> >> Additional info: >> >> - There were two more job offers compn forgotto write down. One from Alex at >> Comcast to implement a perceptional video filter in lavfi for 4K, along with >> mcdeint and denoise filters. Contact compn to get more information about >> this. >> Also Kodi is looking for python plugin developers. Compn also thinks that >> they >> are looking for Android devs, too. >> >> - The group working on ffv1 specification said they've also opportunities >> for >> work. However you've to contact the commission members at archivist >> conferences. >> I think we haven't got a list of these conferences, though. >> >> All the rest is on the slides, more or less in shape. In case anyone has >> interest in going for one of these tasks and/or want to start a discussion, >> feel >> free to do so by posting to the mailing list. > > What means 'Real World Metric filters', 'RGB levels' and 'waveforms'? Forwarding for compn: """ Re: Paul's question, I don't know exactly what filters were requested. I'll ask on vdd mailing list for answers. The requested filters were broadcast stuff. Maybe something like this https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=78%26section=4%26tasks=true Wow, it almost looks like that it's already here https://trac.ffmpeg.org/wiki/FancyFilteringExamples Maybe just linking the wiki examples in the docs may help people find it? """ -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvpxenc: Avaoid vp8 transparency encoding with auto-alt-ref
2016-09-17 4:44 GMT+02:00 James Zern : > Thanks for the easy repro. It may have something to do with the fact > that in vp8 the alt-ref is a separate frame, this needs a closer look. Please keep us informed. > Feel free to apply the change in the meantime. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
From: Anton Khirnov
Signed-off-by: nablet developer
---
libavutil/Makefile | 3 +
libavutil/hwcontext.c | 3 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_internal.h | 1 +
libavutil/hwcontext_qsv.c | 791 +
libavutil/hwcontext_qsv.h | 52 +++
6 files changed, 851 insertions(+)
create mode 100644 libavutil/hwcontext_qsv.c
create mode 100644 libavutil/hwcontext_qsv.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1e06176..76da7d4 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -35,6 +35,7 @@ HEADERS = adler32.h
\
hwcontext.h \
hwcontext_cuda.h \
hwcontext_dxva2.h \
+ hwcontext_qsv.h \
hwcontext_vaapi.h \
hwcontext_vdpau.h \
imgutils.h\
@@ -154,6 +155,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o
\
OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
+OBJS-$(CONFIG_QSV) += hwcontext_qsv.o
OBJS-$(CONFIG_LZO) += lzo.o
OBJS-$(CONFIG_OPENCL) += opencl.o opencl_internal.o
OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
@@ -166,6 +168,7 @@ SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
+SKIPHEADERS-$(CONFIG_QSV) += hwcontext_qsv.h
SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
SKIPHEADERS-$(HAVE_ATOMICS_GCC)+= atomic_gcc.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 1e9e913..be1d73e 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -35,6 +35,9 @@ static const HWContextType *hw_table[] = {
#if CONFIG_DXVA2
&ff_hwcontext_type_dxva2,
#endif
+#if CONFIG_QSV
+&ff_hwcontext_type_qsv,
+#endif
#if CONFIG_VAAPI
&ff_hwcontext_type_vaapi,
#endif
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 4e9da02..5e2af09 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -29,6 +29,7 @@ enum AVHWDeviceType {
AV_HWDEVICE_TYPE_CUDA,
AV_HWDEVICE_TYPE_VAAPI,
AV_HWDEVICE_TYPE_DXVA2,
+AV_HWDEVICE_TYPE_QSV,
};
typedef struct AVHWDeviceInternal AVHWDeviceInternal;
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index cf832fe..079e42b 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -101,6 +101,7 @@ struct AVHWFramesInternal {
extern const HWContextType ff_hwcontext_type_cuda;
extern const HWContextType ff_hwcontext_type_dxva2;
+extern const HWContextType ff_hwcontext_type_qsv;
extern const HWContextType ff_hwcontext_type_vaapi;
extern const HWContextType ff_hwcontext_type_vdpau;
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
new file mode 100644
index 000..13be5b0
--- /dev/null
+++ b/libavutil/hwcontext_qsv.c
@@ -0,0 +1,791 @@
+/*
+ * 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
+ */
+
+#include
+#include
+
+#include
+
+#include "config.h"
+
+#if CONFIG_VAAPI
+#include "hwcontext_vaapi.h"
+#endif
+#if CONFIG_DXVA2
+#include "hwcontext_dxva2.h"
+#endif
+
+#include "buffer.h"
+#include "common.h"
+#include "hwcontext.h"
+#include "hwcontext_internal.h"
+#include "hwcontext_qsv.h"
+#include "mem.h"
+#include "pixfmt.h"
+#include "pixdesc.h"
+#include "time.h"
+
+typedef struct QSVDevicePriv {
+AVBufferRef *child_device_ctx;
+} QSVDevicePriv;
+
+typedef struct QSVDeviceContext {
+mfxHDL handle;
+mfxHandleType handle_type;
+mfxVersion ver;
+mfxIMPL impl;
+
+enum AVHWDeviceType child_device_type;
+enum AV
[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
patch is taken from libav project, authored by Anton Khirnov https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html the only differences from original libav patch: 1) replaced CONFIG_LIBMXF with CONFIG_QSV to match the rest of ffmpeg sources 2) changed copyright headers to match ffmpeg standard this patch adds Intel QuickSync Video hardware context implementation to libavutil, in same manner as other hardware context implementations like CUDA, VAAPI, etc. this context will be used and shared by various Intel QuickSync Video decoders and encoders component (like qsv_h264), as well as VPP filter. Anton Khirnov (1): hwcontext: add a QSV implementation libavutil/Makefile | 3 + libavutil/hwcontext.c | 3 + libavutil/hwcontext.h | 1 + libavutil/hwcontext_internal.h | 1 + libavutil/hwcontext_qsv.c | 791 + libavutil/hwcontext_qsv.h | 52 +++ 6 files changed, 851 insertions(+) create mode 100644 libavutil/hwcontext_qsv.c create mode 100644 libavutil/hwcontext_qsv.h -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
