[FFmpeg-devel] MJPEG FPS
Hi guys, I'm trying to lower the latency when playing mjpeg multipart http stream and I came to this line: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpjpegdec.c#L157 Does it mean each mjpeg stream is decoded as 25FPS? Is this desired feature? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
po 20. 5. 2019 o 21:12 James Almer napísal(a):
>
> On 5/20/2019 4:01 PM, Marton Balint wrote:
> >
> > On Mon, 20 May 2019, Carl Eugen Hoyos wrote:
> >
> >> Marton,
> >>
> >> Am Mo., 13. Mai 2019 um 13:42 Uhr schrieb Daniel Kucera
> >> :
> >>>
> >>> From: Daniel Kucera
> >>>
> >>> Signed-off-by: Daniel Kucera
> >>> ---
> >>> doc/ffplay.texi | 2 ++
> >>> fftools/ffplay.c | 8
> >>> 2 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> >>> index c305465078..a487c0de8d 100644
> >>> --- a/doc/ffplay.texi
> >>> +++ b/doc/ffplay.texi
> >>> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using
> >>> left/right keys. Default is 1
> >>> Disable graphical display.
> >>> @item -noborder
> >>> Borderless window.
> >>> +@item -alwaysontop
> >>> +Window always on top. Available on: X11 with SDL >= 2.0.5, Windows
> >>> SDL >= 2.0.6.
> >>> @item -volume
> >>> Set the startup volume. 0 means silence, 100 means no volume
> >>> reduction or
> >>> amplification. Negative values are treated as 0, values above 100
> >>> are treated
> >>> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> >>> index 8f050e16e6..8fb8faeb06 100644
> >>> --- a/fftools/ffplay.c
> >>> +++ b/fftools/ffplay.c
> >>> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
> >>> static float seek_interval = 10;
> >>> static int display_disable;
> >>> static int borderless;
> >>> +static int alwaysontop;
> >>> static int startup_volume = 100;
> >>> static int show_status = 1;
> >>> static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> >>> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
> >>> { "seek_interval", OPT_FLOAT | HAS_ARG, { &seek_interval }, "set
> >>> seek interval for left/right keys, in seconds", "seconds" },
> >>> { "nodisp", OPT_BOOL, { &display_disable }, "disable graphical
> >>> display" },
> >>> { "noborder", OPT_BOOL, { &borderless }, "borderless window" },
> >>> +{ "alwaysontop", OPT_BOOL, { &alwaysontop }, "window always on
> >>> top" },
> >>> { "volume", OPT_INT | HAS_ARG, { &startup_volume}, "set startup
> >>> volume 0=min 100=max", "volume" },
> >>> { "f", HAS_ARG, { .func_arg = opt_format }, "force format",
> >>> "fmt" },
> >>> { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg =
> >>> opt_frame_pix_fmt }, "set pixel format", "format" },
> >>> @@ -3722,6 +3724,12 @@ int main(int argc, char **argv)
> >>>
> >>> if (!display_disable) {
> >>> int flags = SDL_WINDOW_HIDDEN;
> >>> +if (alwaysontop)
> >>> +#if SDL_VERSION_ATLEAST(2,0,5)
> >>> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;
> >>> +#else
> >>> +av_log(NULL, AV_LOG_WARNING, "Your SDL version doesn't
> >>> support SDL_WINDOW_ALWAYS_ON_TOP. Feature will be inactive.\n");
> >>> +#endif
> >>
> >> Is there any reason you are against this patch?
> >
> > I am not against it, it looks good to me.
>
> Is the flag available in 2.0.5 for Windows, or only since 2.0.6 as the
> doxy addition mentions?
The flag is available generally in the library since 2.0.5, but the
windows implementation is there since 2.0.6 only.
https://github.com/SDL-mirror/SDL/commit/a60edd403816eb8d7f77f18320b76d27c1db2973
https://github.com/SDL-mirror/SDL/commit/76adc80cafd9f83dcfb36ada4b2b028487f7e1d8
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa ne 19. 5. 2019, 16:14 James Almer napísal(a): > On 5/19/2019 6:43 AM, Daniel Kučera wrote: > > Dňa pi 17. 5. 2019, 21:12 Daniel Kučera > > napísal(a): > > > >> > >> > >> Dňa št 16. 5. 2019, 12:04 Daniel Kučera > >> napísal(a): > >> > >>> > >>> > >>> Dňa st 15. 5. 2019, 11:14 Daniel Kučera > >>> napísal(a): > >>> > >>>>> > >>>>> Ping. > >>>>> > >>>>> -- > >>>>> > >>>>> S pozdravom / Best regards > >>>>> Daniel Kucera. > >>>> > >>>> Ping. > >>>> > >>>> -- > >>>> > >>>> S pozdravom / Best regards > >>>> Daniel Kucera. > >>>> > >>> > >>> Ping. > >>> > >> > >> Ping. > >> > > > > Ping. I can to this every day. > > Daily pings will not make it more likely for someone familiar with > ffplay to see and review your patch. Especially during a weekend. > > Try to be a bit more patient, please. Wait five days before pinging a > patch. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". It's been 7 days already. And the patch is under 10 simple lines... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa pi 17. 5. 2019, 21:12 Daniel Kučera napísal(a): > > > Dňa št 16. 5. 2019, 12:04 Daniel Kučera > napísal(a): > >> >> >> Dňa st 15. 5. 2019, 11:14 Daniel Kučera >> napísal(a): >> >>> > >>> > Ping. >>> > >>> > -- >>> > >>> > S pozdravom / Best regards >>> > Daniel Kucera. >>> >>> Ping. >>> >>> -- >>> >>> S pozdravom / Best regards >>> Daniel Kucera. >>> >> >> Ping. >> > > Ping. > Ping. I can to this every day. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa št 16. 5. 2019, 12:04 Daniel Kučera napísal(a): > > > Dňa st 15. 5. 2019, 11:14 Daniel Kučera > napísal(a): > >> > >> > Ping. >> > >> > -- >> > >> > S pozdravom / Best regards >> > Daniel Kucera. >> >> Ping. >> >> -- >> >> S pozdravom / Best regards >> Daniel Kucera. >> > > Ping. > Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa st 15. 5. 2019, 11:14 Daniel Kučera napísal(a): > > > > Ping. > > > > -- > > > > S pozdravom / Best regards > > Daniel Kucera. > > Ping. > > -- > > S pozdravom / Best regards > Daniel Kucera. > Ping. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
> > Ping. > > -- > > S pozdravom / Best regards > Daniel Kucera. Ping. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
po 13. 5. 2019 o 13:42 Daniel Kucera napísal(a):
>
> From: Daniel Kucera
>
> Signed-off-by: Daniel Kucera
> ---
> doc/ffplay.texi | 2 ++
> fftools/ffplay.c | 8
> 2 files changed, 10 insertions(+)
>
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index c305465078..a487c0de8d 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using
> left/right keys. Default is 1
> Disable graphical display.
> @item -noborder
> Borderless window.
> +@item -alwaysontop
> +Window always on top. Available on: X11 with SDL >= 2.0.5, Windows SDL >=
> 2.0.6.
> @item -volume
> Set the startup volume. 0 means silence, 100 means no volume reduction or
> amplification. Negative values are treated as 0, values above 100 are treated
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 8f050e16e6..8fb8faeb06 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
> static float seek_interval = 10;
> static int display_disable;
> static int borderless;
> +static int alwaysontop;
> static int startup_volume = 100;
> static int show_status = 1;
> static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
> { "seek_interval", OPT_FLOAT | HAS_ARG, { &seek_interval }, "set seek
> interval for left/right keys, in seconds", "seconds" },
> { "nodisp", OPT_BOOL, { &display_disable }, "disable graphical display"
> },
> { "noborder", OPT_BOOL, { &borderless }, "borderless window" },
> +{ "alwaysontop", OPT_BOOL, { &alwaysontop }, "window always on top" },
> { "volume", OPT_INT | HAS_ARG, { &startup_volume}, "set startup volume
> 0=min 100=max", "volume" },
> { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
> { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg =
> opt_frame_pix_fmt }, "set pixel format", "format" },
> @@ -3722,6 +3724,12 @@ int main(int argc, char **argv)
>
> if (!display_disable) {
> int flags = SDL_WINDOW_HIDDEN;
> +if (alwaysontop)
> +#if SDL_VERSION_ATLEAST(2,0,5)
> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;
> +#else
> +av_log(NULL, AV_LOG_WARNING, "Your SDL version doesn't support
> SDL_WINDOW_ALWAYS_ON_TOP. Feature will be inactive.\n");
> +#endif
> if (borderless)
> flags |= SDL_WINDOW_BORDERLESS;
> else
> --
> 2.17.1
>
Ping.
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
> > I can at least confirm that 2.0.4, which I have installed on one > machine, doesn't define this in the provided headers, and that ffmpeg > doesn't build against 2.0.4 with this patch. So there should be an > #ifdef SDL_WINDOW_ALWAYS_ON_TOP guard around this, and possibly around > the options definition. (And the docs should mention it?) > > https://hg.libsdl.org/SDL/annotate/3beca914a2ad/include/SDL_video.h > > Not sure how Windows behaves if compiled against 2.0.5 with > availability of the flag, but not the feature. ;-) [*] > > BTW, would this also be an option which could go into the "sdl2" output > device? (I'm not happy with separate code bases for these, personally.) > > Moritz > Thanks Moritz, I submited a new patch according to your recommendations. This patch compiles with 2.0.5 on Windows but doesn't have any effect (tested). I updated the docs to make this clear. Regarding libavdevice/sdl2 - this doesn't share the implementation of windows creation (which is shame) so this is a separate task to implement. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
>> >> Is qualified as 'X11 only, >= SDL 2.0.5' at >> https://wiki.libsdl.org/SDL_WindowFlags >> >> Gyan > > > Since 2.0.6 it works on Windows too. Ping. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
Dňa so 11. 5. 2019, 18:00 Gyan napísal(a):
>
>
> On 11-05-2019 09:03 PM, Michael Niedermayer wrote:
> > On Fri, May 10, 2019 at 12:12:17PM +0200, Daniel Kucera wrote:
> >> From: Daniel Kucera
> >>
> >> Signed-off-by: Daniel Kucera
> >> ---
> >> doc/ffplay.texi | 2 ++
> >> fftools/ffplay.c | 4
> >> 2 files changed, 6 insertions(+)
> >>
> >> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> >> index c305465078..a37c02dc0d 100644
> >> --- a/doc/ffplay.texi
> >> +++ b/doc/ffplay.texi
> >> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using
> left/right keys. Default is 1
> >> Disable graphical display.
> >> @item -noborder
> >> Borderless window.
> >> +@item -alwaysontop
> >> +Window always on top.
> >> @item -volume
> >> Set the startup volume. 0 means silence, 100 means no volume
> reduction or
> >> amplification. Negative values are treated as 0, values above 100 are
> treated
> >> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> >> index 8f050e16e6..931dc08e2d 100644
> >> --- a/fftools/ffplay.c
> >> +++ b/fftools/ffplay.c
> >> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
> >> static float seek_interval = 10;
> >> static int display_disable;
> >> static int borderless;
> >> +static int alwaysontop;
> >> static int startup_volume = 100;
> >> static int show_status = 1;
> >> static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> >> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
> >> { "seek_interval", OPT_FLOAT | HAS_ARG, { &seek_interval }, "set
> seek interval for left/right keys, in seconds", "seconds" },
> >> { "nodisp", OPT_BOOL, { &display_disable }, "disable graphical
> display" },
> >> { "noborder", OPT_BOOL, { &borderless }, "borderless window" },
> >> +{ "alwaysontop", OPT_BOOL, { &alwaysontop }, "window always on
> top" },
> >> { "volume", OPT_INT | HAS_ARG, { &startup_volume}, "set startup
> volume 0=min 100=max", "volume" },
> >> { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt"
> },
> >> { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg =
> opt_frame_pix_fmt }, "set pixel format", "format" },
> >> @@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
> >>
> >> if (!display_disable) {
> >> int flags = SDL_WINDOW_HIDDEN;
> >> +if (alwaysontop)
> >> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;
> > fails to build
> >
> > fftools/ffplay.c: In function ‘main’:
> > fftools/ffplay.c:3728:22: error: ‘SDL_WINDOW_ALWAYS_ON_TOP’ undeclared
> (first use in this function)
> > flags |= SDL_WINDOW_ALWAYS_ON_TOP;
>
> Is qualified as 'X11 only, >= SDL 2.0.5' at
> https://wiki.libsdl.org/SDL_WindowFlags
>
> Gyan
>
Since 2.0.6 it works on Windows too.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
> Can you also add a keypress event to make it switchable during play? > > Thanks, > Gyan I haven't found a function which would allow to modify window flags after creation: https://wiki.libsdl.org/SDL_GetWindowFlags -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add android_capture indev
2017-11-07 18:47 GMT+01:00 Felix Matouschek : > >> Am 07.11.2017 um 16:17 schrieb Daniel Kučera : >> >> It's used like here: >> https://github.com/danielkucera/ZidoStreamer/blob/master/app/src/main/java/eu/danman/zidostreamer/zidostreamer/StreamService.java#L62 >> >> If I open standard streaming or camera app, no camera is listed. > > Note that your application uses the Camera Java API, this indev uses the > Camera2 NDK API. > You are probably right. My device has Android 4.4.2 only without any hope for update so it won't work anyway. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add android_capture indev
2017-11-07 15:25 GMT+01:00 Felix Matouschek : > Am 02.11.2017 16:20, schrieb Daniel Kučera: > >> some devices have cameras which are unlisted - this condition makes >> them unusable. > > > How does one use unlisted devices? As far as I understood all supported > devices are listed. If the Camera2 API does not support the camera > it cannot be used. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel It's used like here: https://github.com/danielkucera/ZidoStreamer/blob/master/app/src/main/java/eu/danman/zidostreamer/zidostreamer/StreamService.java#L62 If I open standard streaming or camera app, no camera is listed. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add android_capture indev
2017-11-02 13:42 GMT+01:00 Felix Matouschek :
> Hello,
>
> I've written an indev for Android devices to allow capturing their builtin
> cameras.
> What needs to be done to merge this?
>
> Greetings,
> Felix
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Looking forrward to this to be included. Just one note:
+if (ctx->video_device_number < camera_ids->numCameras) {
+ctx->camera_id = av_strdup(
+camera_ids->cameraIds[ctx->video_device_number]);
+} else {
+av_log(avctx, AV_LOG_ERROR, "No camera with number %d available.\n",
+ctx->video_device_number);
+return AVERROR(ENXIO);
+}
some devices have cameras which are unlisted - this condition makes
them unusable.
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF
2017-10-21 13:36 GMT+02:00 Jan Ekstrom : > > This seems to have broken seeking and files ending. FLAC was > experienced yesterday but it seems like it's more general. This was > reported on the mpv users' channel by sfan5, but I feel like this > might be more general than related to just mpv. At first this was > thought to be limited to HTTP, but later was found out to be > applicable to local files as well. > Hi Jan, please post a test case, ideally as an issue into trac. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF libavformat/aviobuf: don't treat 0 as EOF libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
> > This changes: > ./ffmpeg -y -i 'concat:matrixbench_mpeg2.mpg|matrixbench_mpeg2.mpg' -vsync 0 > -an file.avi > fixed, sending new patch. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF libavformat/aviobuf: don't treat 0 as EOF libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
> This changes: > ./ffmpeg -y -i 'concat:matrixbench_mpeg2.mpg|matrixbench_mpeg2.mpg' -vsync 0 -an file.avi In case he doesn't have this sample: http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg Basically, with the patch applied the above command doesn't concatenate the input as requested. Is there a reason why this test is not included in fate? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
> > If one patch introduces a problem that gets fixed by a subsequent patch > then yes, both should be squashed into one to make sure the problem is > never introduced. > > The idea is that no patch/commit on its own should generate a fate > failure of any kind, as it would make bisecting unrelated future issues > harder. Thank you for explaining. I've sent squashed patch. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
2017-10-14 19:16 GMT+02:00 Daniel Kučera : > 2017-10-14 17:46 GMT+02:00 Michael Niedermayer : >> On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: >>> breaks fate-indeo3-2 >>> >>> [...] >>> -- >>> >>> >>> You need to apply the whole set. It passed all fate tests on my machine. >> >> I applied the whole set and bisected to find which patch caused the >> failure >> >> also the i-th patch of a set must pass fate with it and the 0th to ith >> patches applied, otherwise there would be checkouts that fail some tests >> > > So should I reorder them and post again? > > What if they don't pass fate in any order? should I post them as one patch? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
2017-10-14 17:46 GMT+02:00 Michael Niedermayer : > On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: >> breaks fate-indeo3-2 >> >> [...] >> -- >> >> >> You need to apply the whole set. It passed all fate tests on my machine. > > I applied the whole set and bisected to find which patch caused the > failure > > also the i-th patch of a set must pass fate with it and the 0th to ith > patches applied, otherwise there would be checkouts that fail some tests > So should I reorder them and post again? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
breaks fate-indeo3-2 [...] -- You need to apply the whole set. It passed all fate tests on my machine. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/wtvdec: return AVERROR_EOF on EOF
bump.
2017-06-15 10:22 GMT+02:00 Nicolas George :
> Le septidi 17 prairial, an CCXXV, Daniel Kucera a écrit :
>> Signed-off-by: Daniel Kucera
>> ---
>> libavformat/wtvdec.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
>> index 3ac4501306..ee19fd84da 100644
>> --- a/libavformat/wtvdec.c
>> +++ b/libavformat/wtvdec.c
>> @@ -65,7 +65,7 @@ static int64_t seek_by_sector(AVIOContext *pb, int64_t
>> sector, int64_t offset)
>> }
>>
>> /**
>> - * @return bytes read, 0 on end of file, or <0 on error
>> + * @return bytes read, AVERROR_EOF on end of file, or <0 on error
>> */
>> static int wtvfile_read_packet(void *opaque, uint8_t *buf, int buf_size)
>> {
>> @@ -76,7 +76,7 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf,
>> int buf_size)
>> if (wf->error || pb->error)
>> return -1;
>> if (wf->position >= wf->length || avio_feof(pb))
>> -return 0;
>> +return AVERROR_EOF;
>>
>> buf_size = FFMIN(buf_size, wf->length - wf->position);
>> while(nread < buf_size) {
>> --
>> 2.11.0
>
> LGTM, but I do not maintain that file.
>
> Regards,
>
> --
> Nicolas George
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
> > The good approach is to fix the bugs. You do not need to fix all of > them, just fix the one or two instances that break things for you: in > your use case, there is one line of code in the whole project that gets > ret=0 and thinks it means EOF: find it and fix it, and you should be > good. Other instance, if any, can be fixed as needed. > I tried this approach but when I changed that one critical line, 10 other things got broken according to fate. Even if I fixed them and posted patches here in list, I was sugested to thorougouhly test all other protocol modules to make sure it doesn't break anything else but that's not possible (at least I'm not able to). So what other option I have than trying to submit a workaround? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
Waiting for review. Dňa 6. 10. 2017 10:32 dopoludnia používateľ "Daniel Kučera" < daniel.kuc...@gmail.com> napísal: > > And since empty packets are valid and can be used by applications (and > > are actually used by protocols out there), the workaround of dropping > > them is not acceptable. > > > > I'm not sure if you mean this patch is unacceptable but if so, I want > to note, that this patch is not the same as I submitted before: this > one adds cmdlne option to ignore empty packets and it doesn't ignore > them when not explicitly enabled. > > > -- > > S pozdravom / Best regards > Daniel Kucera. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
> And since empty packets are valid and can be used by applications (and > are actually used by protocols out there), the workaround of dropping > them is not acceptable. > I'm not sure if you mean this patch is unacceptable but if so, I want to note, that this patch is not the same as I submitted before: this one adds cmdlne option to ignore empty packets and it doesn't ignore them when not explicitly enabled. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: added option to ignore empty UDP packets
Dňa 5. 10. 2017 10:19 odpoludnia používateľ "Carl Eugen Hoyos" < ceffm...@gmail.com> napísal: 2017-10-05 16:26 GMT+02:00 Daniel Kucera : > Time to time some devices send UDP packets without payload. > ffmpeg previously exited on receiving such packet Just curious: Is it useful at all to exit on an empty packet? Carl Eugen No, It's a bug and it's so deep that it would require fixing many modules but I'm not able to do it and noone other cares. So I'm proposing this workaround. Daniel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf: don't treat 0 as EOF
2017-06-19 16:34 GMT+02:00 Michael Niedermayer : > On Mon, Jun 19, 2017 at 11:15:27AM -0300, James Almer wrote: >> On 6/19/2017 11:09 AM, Michael Niedermayer wrote: >> > On Sun, Jun 18, 2017 at 09:14:21PM +0200, Daniel Kucera wrote: >> >> Signed-off-by: Daniel Kucera >> >> --- >> >> libavformat/aviobuf.c | 20 >> >> 1 file changed, 12 insertions(+), 8 deletions(-) >> > >> > This causes fate-swr-resample-s32p-2626-44100 to infinite loop >> >> Why would that one be specifically affected out of the ~50 swr tests? Or >> is it that you didn't try others after that one stalled? > > almost every test gets stuck, i just picked a random one > It requires following patch to be applied: libavformat/avio: fix retry_transfer_wrapper return value on error -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/avio: fix retry_transfer_wrapper return value on error
2017-06-12 12:31 GMT+02:00 Michael Niedermayer : > On Fri, Jun 09, 2017 at 03:51:30PM +0200, Daniel Kucera wrote: >> Signed-off-by: Daniel Kucera >> --- >> libavformat/avio.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) > > causes fate to infinte loop > for example fate-filter-volume > Please test on latest master. For me it passed. S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF
2017-06-05 21:18 GMT+02:00 Daniel Kucera :
> Signed-off-by: Daniel Kucera
> ---
> libavformat/cache.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/cache.c b/libavformat/cache.c
> index 6aabca2e78..66bbbf54c9 100644
> --- a/libavformat/cache.c
> +++ b/libavformat/cache.c
> @@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
> int size)
> }
>
> r = ffurl_read(c->inner, buf, size);
> -if (r == 0 && size>0) {
> +if (r == AVERROR_EOF && size>0) {
> c->is_true_eof = 1;
> av_assert0(c->end >= c->logical_pos);
> }
> @@ -263,7 +263,7 @@ resolve_eof:
> if (whence == SEEK_SET)
> size = FFMIN(sizeof(tmp), pos - c->logical_pos);
> ret = cache_read(h, tmp, size);
> -if (ret == 0 && whence == SEEK_END) {
> +if (ret == AVERROR_EOF && whence == SEEK_END) {
> av_assert0(c->is_true_eof);
> goto resolve_eof;
> }
> --
> 2.11.0
>
Reminding for review.
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-04 12:25 GMT+02:00 Nicolas George :
> Le sextidi 16 prairial, an CCXXV, Daniel Kucera a écrit :
>> Signed-off-by: Daniel Kucera
>> ---
>> libavformat/avio.c| 2 +-
>> libavformat/aviobuf.c | 20
>> libavformat/cache.c | 4 ++--
>> libavformat/file.c| 2 ++
>> libavformat/subfile.c | 2 +-
>> libavformat/wtvdec.c | 4 ++--
>> 6 files changed, 20 insertions(+), 14 deletions(-)
>
> I have several qualms about this patch.
>
> Firs, there are several direct calls to read_packet, I am not sure it
> addresses all of them. I think it would be better to have a single
> low-level wrapper for read_packet and use only it.
>
> Second, these changes do not handle packet protocols. For packet
> protocols, read returning 0 means an empty packet, and that must be
> returned to the application. It does not mean EOF.
>
> I suggest the following check around read_packet :
>
> av_assert2(ret || url->max_packet_size);
> if (!ret && !url->max_packet_size)
> ret = AVERROR_EOF;
>
> The av_assert2() allows debug builds to crash whenever an invalid return
> value happens, making it easier to detect them. The second check allows
> normal builds to run, same as before. And of course, you should be
> working and running FATE at assert level 2.
>
> It leaves a small problem for stream protocols that are thin wrappers
> around another protocol that may or may not be packet : they must all
> check 0 and ignore it. Fortunately, we have only a handful of thin
> wrappers.
>
> See comments below for a few details.
>
>>
>> diff --git a/libavformat/avio.c b/libavformat/avio.c
>> index 1e79c9dd5c..bf803016b7 100644
>> --- a/libavformat/avio.c
>> +++ b/libavformat/avio.c
>> @@ -394,7 +394,7 @@ static inline int retry_transfer_wrapper(URLContext *h,
>> uint8_t *buf,
>> av_usleep(1000);
>> }
>> } else if (ret < 1)
>> -return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
>> +return (ret < 0) ? ret : len;
>> if (ret) {
>> fast_retries = FFMAX(fast_retries, 2);
>> wait_since = 0;
>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>> index 1667e9f08b..3705e406d9 100644
>> --- a/libavformat/aviobuf.c
>> +++ b/libavformat/aviobuf.c
>> @@ -556,13 +556,14 @@ static void fill_buffer(AVIOContext *s)
>> if (s->read_packet)
>> len = s->read_packet(s->opaque, dst, len);
>> else
>> -len = 0;
>> -if (len <= 0) {
>> +len = AVERROR_EOF;
>> +if (len == AVERROR_EOF) {
>> /* do not modify buffer if EOF reached so that a seek back can
>> be done without rereading data */
>> s->eof_reached = 1;
>> -if (len < 0)
>> -s->error = len;
>> +} else if (len < 0) {
>> +s->eof_reached = 1;
>> +s->error= len;
>> } else {
>> s->pos += len;
>> s->buf_ptr = dst;
>> @@ -630,13 +631,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
>> size)
>> // bypass the buffer and read data directly into buf
>> if(s->read_packet)
>> len = s->read_packet(s->opaque, buf, size);
>> -
>> -if (len <= 0) {
>> + else
>> +len = AVERROR_EOF;
>> +if (len == AVERROR_EOF) {
>> /* do not modify buffer if EOF reached so that a seek
>> back can
>> be done without rereading data */
>> s->eof_reached = 1;
>> -if(len<0)
>> -s->error= len;
>> +break;
>> +} else if (len < 0) {
>> +s->eof_reached = 1;
>> +s->error= len;
>> break;
>> } else {
>> s->pos += len;
>> diff --git a/libavformat/cache.c b/libavformat/cache.c
>> index 6aabca2e78..66bbbf54c9 100644
>> --- a/libavformat/cache.c
>> +++ b/libavformat/cache.c
>> @@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
>> int size)
>> }
>>
>> r = ffurl_read(c->inner, buf, size);
>> -if (r == 0 && size>0) {
>> +if (r == AVERROR_EOF && size>0) {
>> c->is_true_eof = 1;
>> av_assert0(c->end >= c->logical_pos);
>> }
>> @@ -263,7 +263,7 @@ resolve_eof:
>> if (whence == SEEK_SET)
>> size = FFMIN(sizeof(tmp), pos - c->logical_pos);
>> ret = cache_read(h, tmp, size);
>> -if (ret == 0 && whence == SEEK_END) {
>> +if (ret == AVERROR_EOF && whence == SEEK_END) {
>> av_assert0(c->is_true_eof);
>> goto resolve_eof;
>> }
>> diff --git a/libavformat/file.c b/libavformat/file.c
>> index 264542a36a..1fb83851c0 100644
>> --- a/libavformat/file.c
>> +++ b/libavformat/file.c
>> @@ -112,6 +112,8 @@ static
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-03 23:04 GMT+02:00 James Almer : > On 6/3/2017 5:31 PM, Daniel Kučera wrote: >> 2017-06-03 21:54 GMT+02:00 Michael Niedermayer : >>> On Sat, Jun 03, 2017 at 10:16:59AM +0200, Daniel Kucera wrote: >>>> Signed-off-by: Daniel Kucera >>>> --- >>>> libavformat/avio.c| 2 +- >>>> libavformat/aviobuf.c | 18 ++ >>>> libavformat/cache.c | 2 +- >>>> libavformat/file.c| 2 ++ >>>> libavformat/subfile.c | 2 +- >>>> libavformat/wtvdec.c | 4 ++-- >>>> 6 files changed, 17 insertions(+), 13 deletions(-) >>> >>> looses Duration in output in: >>> cat ~/videos/matrixbench_mpeg2.mpg | ./ffprobe -read_ahead_limit -1 >>> cache:pipe:0 >>> >> >> I fixed that RTP issue, I'll send updated patch. What does it mean >> "looses Duration" ? > > The reported duration (and bitrate it seems) for the input file is lost, > and N/A is shown instead. > > Without your patch: > > [cache @ 00ecac40] Inner protocol failed to seekback end : -40 > [mpeg @ 024f3740] start time for stream 0 is not set in > estimate_timings_from_pts > [cache @ 00ecac40] Inner protocol failed to seekback end : -40 > Last message repeated 2 times > Input #0, mpeg, from 'cache:pipe:0': > Duration: 00:03:07.66, start: 0.22, bitrate: 5633 kb/s > Stream #0:0[0x1bf]: Data: dvd_nav_packet > Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, > bt470bg/bt470m/bt470m, bottom first), 720x576 [SAR 16:15 DAR 4:3], 25 > fps, 25 tbr, 90k tbn, 50 tbc > Stream #0:2[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s > Unsupported codec with id 100357 for input stream 0 > [cache @ 00ecac40] Statistics, cache hits:16 cache misses:4033 > > > With it: > > [cache @ 010aac40] Inner protocol failed to seekback end : -40 > Last message repeated 1 times > Input #0, mpeg, from 'cache:pipe:0': > Duration: N/A, start: 0.22, bitrate: N/A > Stream #0:0[0x1bf]: Data: dvd_nav_packet > Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, > bt470bg/bt470m/bt470m, bottom first), 720x576 [SAR 16:15 DAR 4:3], 25 > fps, 25 tbr, 90k tbn, 50 tbc > Stream #0:2[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s > Unsupported codec with id 100357 for input stream 0 > [cache @ 010aac40] Statistics, cache hits:0 cache misses:4033 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Is it with the latest version I sent half an hour ago? It seems to be working for me. Can you please provide your testing file and command? cat fate-suite/mpeg2/matrixbench_mpeg2.lq1.mpg | ./ffprobe -read_ahead_limit -1 cache:pipe:0 ffprobe version N-86331-gae37d3a1c4 Copyright (c) 2007-2017 the FFmpeg developers built with gcc 6.3.0 (Ubuntu 6.3.0-12ubuntu2) 20170406 configuration: --enable-debug=3 --enable-gpl --enable-libx264 libavutil 55. 63.100 / 55. 63.100 libavcodec 57. 96.101 / 57. 96.101 libavformat57. 72.101 / 57. 72.101 libavdevice57. 7.100 / 57. 7.100 libavfilter 6. 90.100 / 6. 90.100 libswscale 4. 7.101 / 4. 7.101 libswresample 2. 8.100 / 2. 8.100 libpostproc54. 6.100 / 54. 6.100 [cache @ 0x55e680107560] Inner protocol failed to seekback end : -38 Last message repeated 3 times Input #0, mpeg, from 'cache:pipe:0': Duration: 00:00:00.96, start: 0.54, bitrate: 1757 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, progressive), 716x236 [SAR 1:1 DAR 179:59], 25 fps, 25 tbr, 90k tbn, 50 tbc [cache @ 0x55e680107560] Statistics, cache hits:10 cache misses:7 -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-03 21:54 GMT+02:00 Michael Niedermayer : > On Sat, Jun 03, 2017 at 10:16:59AM +0200, Daniel Kucera wrote: >> Signed-off-by: Daniel Kucera >> --- >> libavformat/avio.c| 2 +- >> libavformat/aviobuf.c | 18 ++ >> libavformat/cache.c | 2 +- >> libavformat/file.c| 2 ++ >> libavformat/subfile.c | 2 +- >> libavformat/wtvdec.c | 4 ++-- >> 6 files changed, 17 insertions(+), 13 deletions(-) > > looses Duration in output in: > cat ~/videos/matrixbench_mpeg2.mpg | ./ffprobe -read_ahead_limit -1 > cache:pipe:0 > I fixed that RTP issue, I'll send updated patch. What does it mean "looses Duration" ? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-03 8:58 GMT+02:00 Daniel Kučera : >> >> breaks: >> ffmpeg -i subfile,,start,1,end,40,,:matrixbench_mpeg2.mpg >> subfile.avi >> >> (infnite loop) >> >> > > Where can I get that matrixbench_mpeg2.mpg test file? If I run it > against fate-suite/mpeg2/matrixbench_mpeg2.lq1.mpg it works: > Ok, I've found it, sending updated patch in new email. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
> > breaks: > ffmpeg -i subfile,,start,1,end,40,,:matrixbench_mpeg2.mpg subfile.avi > > (infnite loop) > > Where can I get that matrixbench_mpeg2.mpg test file? If I run it against fate-suite/mpeg2/matrixbench_mpeg2.lq1.mpg it works: ./ffmpeg -i subfile,,start,1,end,40,,:fate-suite/mpeg2/matrixbench_mpeg2.lq1.mpg subfile.avi ffmpeg version N-86331-gec2a3962af Copyright (c) 2000-2017 the FFmpeg developers built with gcc 6.3.0 (Ubuntu 6.3.0-12ubuntu2) 20170406 configuration: --enable-debug=3 --enable-gpl --enable-libx264 libavutil 55. 63.100 / 55. 63.100 libavcodec 57. 96.101 / 57. 96.101 libavformat57. 72.101 / 57. 72.101 libavdevice57. 7.100 / 57. 7.100 libavfilter 6. 90.100 / 6. 90.100 libswscale 4. 7.101 / 4. 7.101 libswresample 2. 8.100 / 2. 8.100 libpostproc54. 6.100 / 54. 6.100 [mpeg2video @ 0x55a3295e43a0] Invalid frame dimensions 0x0. Last message repeated 9 times Input #0, mpeg, from 'subfile,,start,1,end,40,,:fate-suite/mpeg2/matrixbench_mpeg2.lq1.mpg': Duration: 00:00:00.88, start: 0.62, bitrate: 3545 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bottom first), 716x236 [SAR 1:1 DAR 179:59], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> mpeg4 (native)) Press [q] to stop, [?] for help Output #0, avi, to 'subfile.avi': Metadata: ISFT: Lavf57.72.101 Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 716x236 [SAR 1:1 DAR 179:59], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc57.96.101 mpeg4 Side data: cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1 frame= 13 fps=0.0 q=10.7 Lsize= 73kB time=00:00:00.92 bitrate= 650.1kbits/s speed=33.9x video:67kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 9.237288% S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-02 15:43 GMT+02:00 Daniel Kučera : > 2017-06-02 15:08 GMT+02:00 Daniel Kučera : >> 2017-06-02 15:02 GMT+02:00 Nicolas George : >>> Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : >>>> Now I'm trying to pass fate. I've fixed some problems but don't have >>>> an idea why it won't pass following test. Does anyone have idea? >>> >>> I suspect you need to fix lavf/file.c to actually return AVERROR_EOF. >>> > > problem is that cache_seek is calling ffurl_seek, but > h->prot->url_seek is zero so it returns AVERROR(ENOSYS) > > I'm little bit lost... > Ok, I've found it and successfully passed fate. I'll send updated patch in separate e-mail. S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-02 15:08 GMT+02:00 Daniel Kučera :
> 2017-06-02 15:02 GMT+02:00 Nicolas George :
>> Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit :
>>> Now I'm trying to pass fate. I've fixed some problems but don't have
>>> an idea why it won't pass following test. Does anyone have idea?
>>
>> I suspect you need to fix lavf/file.c to actually return AVERROR_EOF.
>>
problem is that cache_seek is calling ffurl_seek, but
h->prot->url_seek is zero so it returns AVERROR(ENOSYS)
I'm little bit lost...
Breakpoint 3, cache_seek (h=0x56ea08e0, pos=0, whence=65536) at
libavformat/cache.c:222
222{
(gdb) break ffurl_seek
Note: breakpoint 2 also set at pc 0x5577ccd0.
Breakpoint 4 at 0x5577ccd0: file libavformat/avio.c, line 438.
(gdb) c
Continuing.
Breakpoint 2, ffurl_seek (h=0x56ea0aa0, pos=0, whence=65536) at
libavformat/avio.c:438
438if (!h->prot->url_seek)
(gdb) p h->prot->url_seek
$2 = (int64_t (*)(URLContext *, int64_t, int)) 0x0
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-02 15:02 GMT+02:00 Nicolas George : > Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : >> Now I'm trying to pass fate. I've fixed some problems but don't have >> an idea why it won't pass following test. Does anyone have idea? > > I suspect you need to fix lavf/file.c to actually return AVERROR_EOF. > I already did: +++ b/libavformat/file.c @@ -112,6 +112,8 @@ static int file_read(URLContext *h, unsigned char *buf, int size) ret = read(c->fd, buf, size); if (ret == 0 && c->follow) return AVERROR(EAGAIN); +if (ret == 0) +return AVERROR_EOF; return (ret == -1) ? AVERROR(errno) : ret; } S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF
2017-06-02 3:31 GMT+02:00 Michael Niedermayer : > On Thu, Jun 01, 2017 at 01:12:13PM +0200, Daniel Kucera wrote: >> Signed-off-by: Daniel Kucera >> --- >> libavformat/aviobuf.c | 18 ++ >> 1 file changed, 10 insertions(+), 8 deletions(-) > > breaks fate (infinte loops) > example fate-swr-resample-s32p-2626-8000 > Thanks Michael. Now I'm trying to pass fate. I've fixed some problems but don't have an idea why it won't pass following test. Does anyone have idea? TESTseek-cache-pipe ./tests/fate-run.sh fate-seek-cache-pipe "fate-suite/" "" "/home/danman/FFmpeg" 'cat fate-suite//gapless/gapless.mp3 | run libavformat/tests/seek cache:pipe:0 -read_ahead_limit -1' '' './tests/ref/seek/cache-pipe' '' '3' '' '' '' '' '' '' '' '' '' /home/danman/FFmpeg/libavformat/tests/seek cache:pipe:0 -read_ahead_limit -1 --- ./tests/ref/seek/cache-pipe2017-05-23 17:02:08.517401755 +0200 +++ tests/data/fate/seek-cache-pipe2017-06-02 14:30:41.555138153 +0200 @@ -6,21 +6,19 @@ ret: 0 st: 0 flags:0 ts: 0.788334 ret: 0 st: 0 flags:1 dts: 0.809796 pts: 0.809796 pos: 14407 size: 418 ret:-1 st: 0 flags:1 ts:-0.317499 -ret: 0 st:-1 flags:0 ts: 2.576668 -ret: 0 st: 0 flags:1 dts: 2.586122 pts: 2.586122 pos: 42828 size: 418 +ret:-1 st:-1 flags:0 ts: 2.576668 ret: 0 st:-1 flags:1 ts: 1.470835 ret: 0 st: 0 flags:1 dts: 1.462857 pts: 1.462857 pos: 24856 size: 418 ret: 0 st: 0 flags:0 ts: 0.365002 ret: 0 st: 0 flags:1 dts: 0.365714 pts: 0.365714 pos: 7302 size: 418 ret:-1 st: 0 flags:1 ts:-0.740831 -ret: 0 st:-1 flags:0 ts: 2.153336 -ret: 0 st: 0 flags:1 dts: 2.168163 pts: 2.168163 pos: 36141 size: 418 +ret:-1 st:-1 flags:0 ts: 2.153336 ret: 0 st:-1 flags:1 ts: 1.047503 ret: 0 st: 0 flags:1 dts: 1.044898 pts: 1.044898 pos: 18169 size: 418 ret: 0 st: 0 flags:0 ts:-0.058330 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 1451 size: 417 ret: 0 st: 0 flags:1 ts: 2.835837 -ret: 0 st: 0 flags:1 dts: 2.821224 pts: 2.821224 pos: 46590 size: 418 +ret: 0 st: 0 flags:1 dts: 1.933061 pts: 1.933061 pos: 32380 size: 388 ret: 0 st:-1 flags:0 ts: 1.730004 ret: 0 st: 0 flags:1 dts: 1.750204 pts: 1.750204 pos: 29454 size: 418 ret: 0 st:-1 flags:1 ts: 0.624171 @@ -28,7 +26,7 @@ ret: 0 st: 0 flags:0 ts:-0.481662 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 1451 size: 417 ret: 0 st: 0 flags:1 ts: 2.412505 -ret: 0 st: 0 flags:1 dts: 2.403265 pts: 2.403265 pos: 39903 size: 418 +ret: 0 st: 0 flags:1 dts: 1.933061 pts: 1.933061 pos: 32380 size: 388 ret: 0 st:-1 flags:0 ts: 1.306672 ret: 0 st: 0 flags:1 dts: 1.332245 pts: 1.332245 pos: 22766 size: 418 ret: 0 st:-1 flags:1 ts: 0.200839 @@ -36,12 +34,11 @@ ret: 0 st: 0 flags:0 ts:-0.904994 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 1451 size: 417 ret: 0 st: 0 flags:1 ts: 1.989173 -ret: 0 st: 0 flags:1 dts: 1.985306 pts: 1.985306 pos: 33215 size: 418 +ret: 0 st: 0 flags:1 dts: 1.933061 pts: 1.933061 pos: 32380 size: 388 ret: 0 st:-1 flags:0 ts: 0.883340 ret: 0 st: 0 flags:1 dts: 0.888163 pts: 0.888163 pos: 15661 size: 418 ret:-1 st:-1 flags:1 ts:-0.222493 -ret: 0 st: 0 flags:0 ts: 2.671674 -ret: 0 st: 0 flags:1 dts: 2.690612 pts: 2.690612 pos: 44500 size: 418 +ret:-1 st: 0 flags:0 ts: 2.671674 ret: 0 st: 0 flags:1 ts: 1.565841 ret: 0 st: 0 flags:1 dts: 1.541224 pts: 1.541224 pos: 26110 size: 418 ret: 0 st:-1 flags:0 ts: 0.460008 Test seek-cache-pipe failed. Look at tests/data/fate/seek-cache-pipe.err for details. [cache @ 0x56224fd448e0] Inner protocol failed to seekback end : -38 [cache @ 0x56224fd448e0] Inner protocol failed to seekback end : -38 [mp3 @ 0x56224fd44040] invalid concatenated file detected - using bitrate for duration [cache @ 0x56224fd448e0] Inner protocol failed to seekback end : -38 [cache @ 0x56224fd448e0] Inner protocol failed to seekback end : -38 [cache @ 0x56224fd448e0] Inner protocol failed to seekback end : -38 [cache @ 0x56224fd448e0] Statistics, cache hits:0 cache misses:8 tests/Makefile:221: recipe for target 'fate-seek-cache-pipe' failed make: *** [fate-seek-cache-pipe] Error 1 Thank you. S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: ignore UDP packets without payload
2017-05-23 20:44 GMT+02:00 Daniel Kucera :
> Time to time some devices send UDP packets without payload.
> ffmpeg previously exited on receiving such packet, this patch
> fixes this behaviour.
>
> Signed-off-by: Daniel Kucera
> ---
> libavformat/udp.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 3835f989c4..28fa7b2354 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -1039,7 +1039,11 @@ static int udp_read(URLContext *h, uint8_t *buf, int
> size)
> av_fifo_generic_read(s->fifo, buf, avail, NULL);
> av_fifo_drain(s->fifo, AV_RL32(tmp) - avail);
> pthread_mutex_unlock(&s->mutex);
> -return avail;
> +if (avail > 0){
> +return avail;
> +} else {
> +continue;
> +}
> } else if(s->circular_buffer_error){
> int err = s->circular_buffer_error;
> pthread_mutex_unlock(&s->mutex);
> --
> 2.11.0
>
Can anyone please review my patch?
Thank you.
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: ignore UDP packets without payload
2017-05-24 9:02 GMT+02:00 Nicolas George : > Le quartidi 4 prairial, an CCXXV, Daniel Kucera a écrit : >> Time to time some devices send UDP packets without payload. >> ffmpeg previously exited on receiving such packet, this patch >> fixes this behaviour. >> >> Signed-off-by: Daniel Kucera >> --- >> libavformat/udp.c | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) > > I do not think this is correct: UDP is a packetized protocol, packet > with empty payload are still packets, and meaningful for some protocols. > > Regards, > > -- > Nicolas George If we return 0, then it is considered as EOF by calling functions (e.g. avio_read). So returning 0 means: "this is end of stream" and not: "we received zero length packet, but more data may be coming" and thus the stream processing ends. I need to fix this behavior, example errors are described here: https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/#comment-478 S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: ignore UDP packets without payload
2017-05-24 10:10 GMT+02:00 Daniel Kučera :
> 2017-05-24 9:02 GMT+02:00 Nicolas George :
>>
>> Le quartidi 4 prairial, an CCXXV, Daniel Kucera a écrit :
>> > Time to time some devices send UDP packets without payload.
>> > ffmpeg previously exited on receiving such packet, this patch
>> > fixes this behaviour.
>> >
>> > Signed-off-by: Daniel Kucera
>> > ---
>> > libavformat/udp.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> I do not think this is correct: UDP is a packetized protocol, packet
>> with empty payload are still packets, and meaningful for some protocols.
>>
>> Regards,
>>
>> --
>> Nicolas George
>
>
> Maybe, but in libavformat/async.c is zero treated as EOF:
>
> ret = ring_generic_write(ring, (void *)h, to_copy, wrapped_url_read);
> pthread_mutex_lock(&c->mutex);
> if (ret <= 0) {
> c->io_eof_reached = 1;
> if (c->inner_io_error < 0)
> c->io_error = c->inner_io_error;
> }
>
> So what do you suggest?
>
>
> S pozdravom / Best regards
> Daniel Kucera.
Even this patch works for me, do you think it's more suitable?
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 1667e9f08b..eeb229d45d 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -631,7 +631,7 @@ int avio_read(AVIOContext *s, unsigned char *buf, int size)
if(s->read_packet)
len = s->read_packet(s->opaque, buf, size);
-if (len <= 0) {
+if (len < 0) {
/* do not modify buffer if EOF reached so that a
seek back can
be done without rereading data */
s->eof_reached = 1;
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] udp: ignore UDP packets without payload
2017-05-24 9:02 GMT+02:00 Nicolas George :
>
> Le quartidi 4 prairial, an CCXXV, Daniel Kucera a écrit :
> > Time to time some devices send UDP packets without payload.
> > ffmpeg previously exited on receiving such packet, this patch
> > fixes this behaviour.
> >
> > Signed-off-by: Daniel Kucera
> > ---
> > libavformat/udp.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> I do not think this is correct: UDP is a packetized protocol, packet
> with empty payload are still packets, and meaningful for some protocols.
>
> Regards,
>
> --
> Nicolas George
Maybe, but in libavformat/async.c is zero treated as EOF:
ret = ring_generic_write(ring, (void *)h, to_copy, wrapped_url_read);
pthread_mutex_lock(&c->mutex);
if (ret <= 0) {
c->io_eof_reached = 1;
if (c->inner_io_error < 0)
c->io_error = c->inner_io_error;
}
So what do you suggest?
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
