[FFmpeg-devel] Reorganizing Cookies (was Re: [PATCH] Replace old cookies with new cookies of the same name)
On 18/08/14 21:36, Nicolas George wrote:
Le primidi 1er fructidor, an CCXXII, Micah Galizia a écrit :
Yes no. I agree its not an ideal implementation (it actually was
mine to begin with) to just use a string full of cookies. But we can't
pass around complex structures through avopts, which is where we would
really see the benefit. As you Mark pointed out, we need to maintain
compatibility with the current format, so why why go through parsing
the cookie list each time if 1 in 100 requests actually sends back an
updated cookie, and even then you'd have to dump it back out to a
string and parse it again to pass it between http requests all
this considered, I'd say I'm definitely leaning to no unless there
is something I've overlooked.
First, a small nitpick: if you read the option to get the updated values of
the cookies after the request, then you are abusing the API, as the option
does not have AV_OPT_FLAG_EXPORT. But for the sake of discussion we can
assume it should be there and always was.
But that does not mean that the string must be the authoritative value used
internally. A lot of your code is spent updating the middle of the string
while keeping the prefix and suffix constant. That makes a lot of tricky
code, with reallocations and possible integer overflows everywhere.
I am convinced that parsing the string as a whole, manipulating an internal
data structure and rebuilding the string as a whole would give much simpler
code. The parsing is needed for the actual Set-Cookie header; line-splitting
is relatively easy. As for the rebuilding of the string, we have utilities
that can take care of the reallocations and integer overflow for you; I
think especially of AVBPrint. Here is a snippet of code:
av_bprint_init(bp, 0, AV_BPRINT_SIZE_UNLIMITED);
for (i = 0; i http-nb_cookies; i++) {
Cookie *c = http-cookie[i];
if (i)
av_bprintf(bp, \n);
av_bprintf(bp, %s=%s, c-name, c-value);
if (c-domain)
av_bprintf(bp, ; domain=%s, c-domain);
if (c-path)
av_bprintf(bp, ; path=%s, c-path);
if (c-extra)
av_bprintf(bp, ; %s, c-extra);
}
if (!av_bprint_is_complete(bp))
return AVERROR(ENOMEM);
return av_bprint_finalize(bp, http-cookies);
Another point: I believe that having a callback on some options values may
also be quite useful. That could be done as AV_OPT_FLAG_CALLBACK with a
function pointer in AVClass. In this particular case, the callback could
parse the string on the fly and re-generate it only when necessary.
You lost me on the callback bit. I'm not sure I get how it'd really help.
What do people think about that?
I'd like to reorganize the cookies. Where I come up short is how to
store them once they're parsed. Ideally, whatever their structure, they
should be tied into the AVOption array for http so hls can copy them
back and forth. That doesn't really leave me with a lot of choice for
data structures -- and I'd rather not create a new AV_OPT_TYPE.
Using what is available now I could keep the existing cookies option
(newline delimited string) to allow external apps to set the cookies
initially. After they are passed in I could break them into a second
dictionary option (with the export flag) keyed by cookie name so at
least replacement is easier. I'd probably unset the original cookie
string too once they're broken into a dict so that there is no ambiguity
over where they are stored. Then, hls (or any other code) could pass
around the dict option instead of the string.
I'm open to suggestions if I've overlooked an obvious way to tie generic
structs into the AVOptions though. Alternatively, if the dictionary
method is enough of an improvement I'll put in patchs to get it done
that way.
--
Micah
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not add extradata size to bitmapinfoheader size
On Sat, Sep 27, 2014 at 10:51:25AM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch is one of two patches necessary to fix ticket #1304. The MSDN documentation indicates that the palette is not part of the bitmapinfoheader but the bitmapinfoheader is part of the bitmapinfo structure that also contains the palette. An alternative is to add the extradata_size except if it is a palette but imo, attached is more correct. biSize must be calculated so that it points to the palette, so if you have both extradata and palette you absolutely need to add the extradata size: An application should use the information stored in the biSize member to locate the color table in a BITMAPINFO structure, as follows. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not add extradata size to bitmapinfoheader size
On Sun, Sep 28, 2014 at 09:50:43AM +0200, Reimar Döffinger wrote: On Sat, Sep 27, 2014 at 10:51:25AM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch is one of two patches necessary to fix ticket #1304. The MSDN documentation indicates that the palette is not part of the bitmapinfoheader but the bitmapinfoheader is part of the bitmapinfo structure that also contains the palette. An alternative is to add the extradata_size except if it is a palette but imo, attached is more correct. biSize must be calculated so that it points to the palette, so if you have both extradata and palette you absolutely need to add the extradata size: An application should use the information stored in the biSize member to locate the color table in a BITMAPINFO structure, as follows. Also, we currently do not set biClrUsed, so I can't see how anything that uses palette could work at all. Otherwise it would have been correct to set biSize = extradata_size - 4*biClrUsed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, Sep 28, 2014 at 03:50:11AM +0200, Michael Niedermayer wrote: On Sun, Sep 21, 2014 at 10:17:16AM +0100, Reimar Döffinger wrote: Should should fix seeking in some blurays in combination with e.g. MPlayer. Not yet tested due to no bluray at hand. Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de --- libavformat/mpegts.c | 8 1 file changed, 8 insertions(+) should be ok if it works According to user reports it does not, no idea why yet though. To be honest I don't really know how this actually works. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not add extradata size to bitmapinfoheader size
Reimar Döffinger Reimar.Doeffinger at gmx.de writes: On Sun, Sep 28, 2014 at 09:50:43AM +0200, Reimar Döffinger wrote: On Sat, Sep 27, 2014 at 10:51:25AM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch is one of two patches necessary to fix ticket #1304. The MSDN documentation indicates that the palette is not part of the bitmapinfoheader but the bitmapinfoheader is part of the bitmapinfo structure that also contains the palette. An alternative is to add the extradata_size except if it is a palette but imo, attached is more correct. I still believe that my original patch is correct but I will send one that only changes the bisize for palette so that the MPlayer demuxer will not break. biSize must be calculated so that it points to the palette, so if you have both extradata and palette you absolutely need to add the extradata size: This is wrong afaict. Or do we misunderstand each other? Currently, the size of the palette is added, I sincerely hope no other extradata is used for pal8 rawvideo. So when I wrote above do not add extradata size I of course meant the size of the palette. But I did test with different versions of WMP that all extradata (WMV2 extradata) size does not have to be part of the bitmapinfoheader size: WMP reads the extradata no matter the size of the bitmapinfoheader. MPlayer's avi demuxer is the only one that only reads the extradata if it is part of the size of the bitmapinfoheader. An application should use the information stored in the biSize member to locate the color table in a BITMAPINFO structure, as follows. This is exactly what is currently broken in FFmpeg. The MPlayer demuxer is the only one that needs the extradata size added to the bitmapinfoheader size, this should be fixed there. Also, we currently do not set biClrUsed, so I can't see how anything that uses palette could work at all. Otherwise it would have been correct to set biSize = extradata_size - 4*biClrUsed Setting it to zero as we do seems correct or do I miss something? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
Should should fix seeking in some blurays in combination with
e.g. MPlayer.
Not yet tested due to no bluray at hand.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavformat/mpegts.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 3434341..c04e156 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2659,6 +2659,12 @@ void ff_mpegts_parse_close(MpegTSContext *ts)
av_free(ts);
}
+static int mpegts_read_seek(AVFormatContext *s, int stream_index,
+int64_t ts, int flags)
+{
+return avio_seek_time(s-pb, stream_index, ts, flags);
+}
+
AVInputFormat ff_mpegts_demuxer = {
.name = mpegts,
.long_name = NULL_IF_CONFIG_SMALL(MPEG-TS (MPEG-2 Transport
Stream)),
@@ -2668,6 +2674,7 @@ AVInputFormat ff_mpegts_demuxer = {
.read_packet= mpegts_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegts_class,
};
@@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
.read_packet= mpegts_raw_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegtsraw_class,
};
IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!
And in general, this seems useless: if you want to fix MPlayer, what
stops you from redirecting seeks to the stream layer if needed
directly in demux_lavf.c's seek function? In general, the application
can decide much better whether it wants to seek using the packet
timestamps or the stream layer's special seek function. Also, in the
context of MPlayer, your patch might actually trigger slow operations
when playing a .ts file with cache enabled: it will have to do a
synchronous call through the stream cache layer to call the seek
function.
If we want to fix FFmpeg's native libbluray support, I think we should
export it as demuxer, which opens a .ts demuxer as slave, and
redirects the seek operations correctly to libbluray properly. It also
could rewrite the timestamps to reflect actual playback time, so that
seeking to a time actually works as expected. (Plus removes horrible
hacks from players to display the playback time correctly.)
In general, this avio_read_seek() thing seems to be a somewhat
misguided attempt to coerce high level streaming protocols into the low
level byte-oriented protocol layer. Apparently it's only used by
rtmp, which does scary thing like remuxing the received data to flv,
just to bypass the protocol/demuxer separation. Newer protocol
implementations like HLS don't do this anymore, and just put everything
into the demuxer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not add extradata size to bitmapinfoheader size
On Sun, Sep 28, 2014 at 08:06:40AM +, Carl Eugen Hoyos wrote: biSize must be calculated so that it points to the palette, so if you have both extradata and palette you absolutely need to add the extradata size: This is wrong afaict. Or do we misunderstand each other? Currently, the size of the palette is added, I sincerely hope no other extradata is used for pal8 rawvideo. Not for pal8 rawvideo, but that function isn't only used for that? So when I wrote above do not add extradata size I of course meant the size of the palette. But you do not add any extradata, not just not the palette (if both would exist). So for a codec that has both extradata and palette the size must include the other extradata, otherwise the palette cannot be found properly. But I did test with different versions of WMP that all extradata (WMV2 extradata) size does not have to be part of the bitmapinfoheader size: WMP reads the extradata no matter the size of the bitmapinfoheader. That might be a matter of lack of error checking/handling, in that it just dumps the whole chunk to the decoder, and the decoder doesn't actually validate the data it gets but just assumes it is in the right format. If so, there's a good chance that this might change in the future. MPlayer's avi demuxer is the only one that only reads the extradata if it is part of the size of the bitmapinfoheader. Does it? It thought it falls back to the size of the chunk? An application should use the information stored in the biSize member to locate the color table in a BITMAPINFO structure, as follows. This is exactly what is currently broken in FFmpeg. Yes, but after your change it is broken the other way. If the palette does not start directly after the bitmapinfoheader it still will not conform to that. Not to mention the incorrect biClrUsed. Also, we currently do not set biClrUsed, so I can't see how anything that uses palette could work at all. Otherwise it would have been correct to set biSize = extradata_size - 4*biClrUsed Setting it to zero as we do seems correct or do I miss something? Only if the only thing we append is the palette, in which case calling it extradata is rather idiotic. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
.read_packet= mpegts_raw_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegtsraw_class,
};
IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!
If you combine a stream layer with different timestamps, yes.
And in general, this seems useless: if you want to fix MPlayer, what
stops you from redirecting seeks to the stream layer if needed
directly in demux_lavf.c's seek function?
I want to fix FFmpeg. If it has a function to seek based on the
stream timestamps it should be using it!
In general, the application
can decide much better whether it wants to seek using the packet
timestamps or the stream layer's special seek function.
It can do that very easily: just return an error from the stream's
seek function/do not implement it at all.
Also, in the
context of MPlayer, your patch might actually trigger slow operations
when playing a .ts file with cache enabled: it will have to do a
synchronous call through the stream cache layer to call the seek
function.
How is that in any way different from your proposal that fixes it
in MPlayer?
Also that operation isn't any slower than normal seeking (assuming
the seek is not within the cache).
If we want to fix FFmpeg's native libbluray support, I think we should
export it as demuxer, which opens a .ts demuxer as slave, and
redirects the seek operations correctly to libbluray properly. It also
could rewrite the timestamps to reflect actual playback time, so that
seeking to a time actually works as expected. (Plus removes horrible
hacks from players to display the playback time correctly.)
This fixes only one specific single case and it doesn't help an
application that wants to combine its own bluray handling (for example
using something other than libbluray) with FFmpeg's demuxer, they
still need to hack up their own seeking code for that and then
beat FFmpeg it not seeking on its own, and manually reset the demuxer
etc.
In general, this avio_read_seek() thing seems to be a somewhat
misguided attempt to coerce high level streaming protocols into the low
level byte-oriented protocol layer. Apparently it's only used by
rtmp, which does scary thing like remuxing the received data to flv,
just to bypass the protocol/demuxer separation. Newer protocol
implementations like HLS don't do this anymore, and just put everything
into the demuxer.
And instead don't allow for any kind of proper caching.
Not exactly my definition of a better design.
Either way the read_seek is there, and until such time someone removes
it I am not inclined to consider it a good idea to keep it broken!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Set large address aware.
On Sun, Sep 21, 2014 at 10:17:15AM +0100, Reimar Döffinger wrote: Allows 32 bit version of FFmpeg to use up to 4 GB of RAM instead of just 2 GB on Windows if the OS can provide it. Any other comments? Note the documentation for that option: The /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. This flag is _only_ used to signal that an application can deal with addresses that use more than 31 address bits. I.e. it is only for those horribly misdesigned programs that thought oh, let's store some extra stuff in that unused high bit of the address. Which FFmpeg definitely does not. There is no indication that ptrdiff_t limitations or similar have any relevance to whether one should set this or not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: read reel_name and source timecode from physical source package
On Thu, 2014-09-25 at 16:13 -0700, Mark Reid wrote:
---
libavformat/mxfdec.c | 118
++-
1 file changed, 97 insertions(+), 21 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 7a4633f..3a1889f 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -188,6 +188,7 @@ typedef struct {
int tracks_count;
MXFDescriptor *descriptor; /* only one */
UID descriptor_ref;
+char *name;
} MXFPackage;
typedef struct {
@@ -731,6 +732,27 @@ static int mxf_read_sequence(void *arg, AVIOContext *pb,
int tag, int size, UID
return 0;
}
+static int mxf_read_utf16_string(AVIOContext *pb, int size, char** str)
+{
+int ret;
+size_t buf_size;
+
+if (size 0)
+return AVERROR(EINVAL);
+
+buf_size = size + size / 2 + 1;
This should be a function, like ff_utf16_buflen() or something. I see
that this hunk is just moving the function though, so don't let that
hold this patch up.
+*str = av_malloc(buf_size);
+if (!*str)
+return AVERROR(ENOMEM);
+
+if ((ret = avio_get_str16be(pb, size, *str, buf_size)) 0) {
+av_freep(str);
+return ret;
+}
+
+return ret;
+}
+static int mxf_parse_physical_source_package(MXFContext *mxf, MXFTrack
*source_track, AVStream *st)
+{
[...]
+
+for (k = 0; k
physical_track-sequence-structural_components_count; k++) {
+component = mxf_resolve_strong_ref(mxf,
physical_track-sequence-structural_components_refs[k], TimecodeComponent);
+if (!component)
+continue;
+
+mxf_tc = (MXFTimecodeComponent*)component;
+flags = mxf_tc-drop_frame == 1 ? AV_TIMECODE_FLAG_DROPFRAME
: 0;
+/* scale sourceclip start_position to match physical track
edit rate */
+start_position = av_rescale_q(sourceclip-start_position,
av_inv_q(source_track-edit_rate), av_inv_q(physical_track-edit_rate));
av_rescale()
+
+if (av_timecode_init(tc, mxf_tc-rate, flags,
start_position + mxf_tc-start_frame, mxf-fc) == 0) {
+mxf_add_timecode_metadata(st-metadata, timecode,
tc);
+return 0;
+}
+}
+}
+}
+
+return 0;
+}
+
Looks OK otherwise. Did you try fuzzing (zzuf) with a few files too?
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, 28 Sep 2014 10:40:18 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
.read_packet= mpegts_raw_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegtsraw_class,
};
IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!
If you combine a stream layer with different timestamps, yes.
That's not how the libavformat seeking API works. If you want a
different layer, use something from the different layer. E.g. seek avio
directly, and flush the demuxer's buffers.
And in general, this seems useless: if you want to fix MPlayer, what
stops you from redirecting seeks to the stream layer if needed
directly in demux_lavf.c's seek function?
I want to fix FFmpeg. If it has a function to seek based on the
stream timestamps it should be using it!
But it doesn't work! If you seek to a timestamp using libbluray, the
resulting mpeg-ts packets can have a completely different timestamp. I
see something like a layering violation here.
In general, the application
can decide much better whether it wants to seek using the packet
timestamps or the stream layer's special seek function.
It can do that very easily: just return an error from the stream's
seek function/do not implement it at all.
Also, in the
context of MPlayer, your patch might actually trigger slow operations
when playing a .ts file with cache enabled: it will have to do a
synchronous call through the stream cache layer to call the seek
function.
How is that in any way different from your proposal that fixes it
in MPlayer?
Also that operation isn't any slower than normal seeking (assuming
the seek is not within the cache).
Huh? With your patch, MPlayer would send a seek stream ctrl to the
cache, and would have to do a blocking wait for the cache process. It
can't know whether the implementation is even implemented before
sending the stream ctrl.
Anyway, if this patch is applied, I can easily workaround this in my
own code by checking whether rtmp is used to avoid this situation, so
it's not a blocker for me.
If we want to fix FFmpeg's native libbluray support, I think we should
export it as demuxer, which opens a .ts demuxer as slave, and
redirects the seek operations correctly to libbluray properly. It also
could rewrite the timestamps to reflect actual playback time, so that
seeking to a time actually works as expected. (Plus removes horrible
hacks from players to display the playback time correctly.)
This fixes only one specific single case and it doesn't help an
application that wants to combine its own bluray handling (for example
using something other than libbluray) with FFmpeg's demuxer, they
still need to hack up their own seeking code for that and then
beat FFmpeg it not seeking on its own, and manually reset the demuxer
etc.
Absolutely nothing stops the application from doing its own seeking for
formats like mpeg-ts. Though what you need is a function that flushes
internal libavformat buffers to make sure no old data is read after the
stream-level seek was performed. (Currently I execute a byte seek to
the current position to achieve this flushing.)
In general, this avio_read_seek() thing seems to be a somewhat
misguided attempt to coerce high level streaming protocols into the low
level byte-oriented protocol layer. Apparently it's only used by
rtmp, which does scary thing like remuxing the received data to flv,
just to bypass the protocol/demuxer separation. Newer protocol
implementations like HLS don't do this anymore, and just put everything
into the demuxer.
And instead don't allow for any kind of proper caching.
You can cache packets.
Not exactly my definition of a better design.
I'm inclined to claim that remuxing to FLV makes a pretty terrible
implementation. Why not return the packets directyly!?
Either way the read_seek is there, and until such time someone removes
it I am not inclined to consider it a good idea to keep it broken!
It's not broken. If the fact that mpeg-ts doesn't use it means it's
broken, you're going to have to apply the same patch to a lot of
demuxers.
And again, I don't understand why you can't just redirect the seek in
demux_lavf.c. This would be an easy fix for the MPlayer problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/srtdec: use AVBPrint API
---
Can only be applied after timed SRT is dropped.
---
libavcodec/srtdec.c | 78 -
1 file changed, 35 insertions(+), 43 deletions(-)
diff --git a/libavcodec/srtdec.c b/libavcodec/srtdec.c
index cc17486..d9cc16a 100644
--- a/libavcodec/srtdec.c
+++ b/libavcodec/srtdec.c
@@ -47,8 +47,14 @@ typedef struct {
char param[PARAM_NUMBER][128];
} SrtStack;
-static const char *srt_to_ass(AVCodecContext *avctx, char *out, char *out_end,
- const char *in, int x1, int y1, int x2, int y2)
+static void rstrip_spaces_buf(AVBPrint *buf)
+{
+while (buf-len 0 buf-str[buf-len - 1] == ' ')
+buf-str[--buf-len] = 0;
+}
+
+static void srt_to_ass(AVCodecContext *avctx, AVBPrint *dst,
+ const char *in, int x1, int y1, int x2, int y2)
{
char *param, buffer[128], tmp[128];
int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0;
@@ -61,14 +67,12 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
if (x1 = 0 y1 = 0) {
if (x2 = 0 y2 = 0 (x2 != x1 || y2 != y1))
-snprintf(out, out_end-out,
-{\\an1}{\\move(%d,%d,%d,%d)}, x1, y1, x2, y2);
+av_bprintf(dst, {\\an1}{\\move(%d,%d,%d,%d)}, x1, y1, x2, y2);
else
-snprintf(out, out_end-out, {\\an1}{\\pos(%d,%d)}, x1, y1);
-out += strlen(out);
+av_bprintf(dst, {\\an1}{\\pos(%d,%d)}, x1, y1);
}
-for (; out out_end !end *in; in++) {
+for (; !end *in; in++) {
switch (*in) {
case '\r':
break;
@@ -77,15 +81,13 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
end = 1;
break;
}
-while (out[-1] == ' ')
-out--;
-snprintf(out, out_end-out, \\N);
-if(outout_end) out += strlen(out);
+rstrip_spaces_buf(dst);
+av_bprintf(dst, \\N);
line_start = 1;
break;
case ' ':
if (!line_start)
-*out++ = *in;
+av_bprint_chars(dst, *in, 1);
break;
case '{':/* skip all {\xxx} substrings except for {\an%d}
and all microdvd like styles such as {Y:xxx} */
@@ -95,7 +97,7 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
(len = 0, sscanf(in, {%*1[CcFfoPSsYy]:%*[^}]}%n, len) = 0
len 0)) {
in += len - 1;
} else
-*out++ = *in;
+av_bprint_chars(dst, *in, 1);
break;
case '':
tag_close = in[1] == '/';
@@ -115,9 +117,7 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
if (stack[sptr-1].param[i][0])
for (j=sptr-2; j=0; j--)
if (stack[j].param[i][0]) {
-snprintf(out, out_end-out,
-%s,
stack[j].param[i]);
-if(outout_end) out += strlen(out);
+av_bprintf(dst, %s,
stack[j].param[i]);
break;
}
} else {
@@ -151,16 +151,11 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
param++;
}
for (i=0; iPARAM_NUMBER; i++)
-if (stack[sptr].param[i][0]) {
-snprintf(out, out_end-out,
-%s,
stack[sptr].param[i]);
-if(outout_end) out += strlen(out);
-}
+if (stack[sptr].param[i][0])
+av_bprintf(dst, %s,
stack[sptr].param[i]);
}
} else if (!buffer[1] strspn(buffer, bisu) == 1) {
-snprintf(out, out_end-out,
-{\\%c%d}, buffer[0], !tag_close);
-if(outout_end) out += strlen(out);
+av_bprintf(dst, {\\%c%d}, buffer[0], !tag_close);
} else {
unknown = 1;
snprintf(tmp, sizeof(tmp), /%s, buffer);
@@ -169,7 +164,7 @@ static const char *srt_to_ass(AVCodecContext *avctx, char
*out, char *out_end,
sptr--;
} else if (unknown !strstr(in, tmp)) {
in -= len + tag_close;
-*out++ =
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, 28 Sep 2014 10:40:18 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote: On Sun, 21 Sep 2014 10:17:16 +0100 Reimar Döffinger reimar.doeffin...@gmx.de wrote: In general, this avio_read_seek() thing seems to be a somewhat misguided attempt to coerce high level streaming protocols into the low level byte-oriented protocol layer. Apparently it's only used by rtmp, which does scary thing like remuxing the received data to flv, just to bypass the protocol/demuxer separation. Newer protocol implementations like HLS don't do this anymore, and just put everything into the demuxer. And instead don't allow for any kind of proper caching. Not exactly my definition of a better design. Either way the read_seek is there, and until such time someone removes it I am not inclined to consider it a good idea to keep it broken! PS: besides, you could implement a generic caching muxer, which automatically reads packets from a slave demuxer, and writes them as byte stream. So basically similar to what rtmp does, but generic and useable with any demuxer. This way you could e.g. use a byte cache for HLS. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Set large address aware.
On 28.09.2014, at 11:12, Matt Oliver protogo...@gmail.com wrote: On 28 September 2014 18:49, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Sep 21, 2014 at 10:17:15AM +0100, Reimar Döffinger wrote: Allows 32 bit version of FFmpeg to use up to 4 GB of RAM instead of just 2 GB on Windows if the OS can provide it. Any other comments? Note the documentation for that option: The /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. This flag is _only_ used to signal that an application can deal with addresses that use more than 31 address bits. I.e. it is only for those horribly misdesigned programs that thought oh, let's store some extra stuff in that unused high bit of the address. Which FFmpeg definitely does not. There is no indication that ptrdiff_t limitations or similar have any relevance to whether one should set this or not. There shouldnt be any problem with this at all as it basically just sets a flag in the output dll/exe (which can be manually set after compilation anyway). LARGEADDRESSAWARE should probably be added for msvc/icl as well. Patch welcome. I don't want to add things I can't easily test. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, 28 Sep 2014 13:37:59 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On 28.09.2014, at 11:05, wm4 nfx...@googlemail.com wrote:
On Sun, 28 Sep 2014 10:40:18 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
.read_packet= mpegts_raw_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegtsraw_class,
};
IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!
If you combine a stream layer with different timestamps, yes.
That's not how the libavformat seeking API works. If you want a
different layer, use something from the different layer. E.g. seek avio
directly, and flush the demuxer's buffers.
Which as you mention later is only possible with messy hacks.
All you need is something like av_format_flush(ctx).
Also, in the
context of MPlayer, your patch might actually trigger slow operations
when playing a .ts file with cache enabled: it will have to do a
synchronous call through the stream cache layer to call the seek
function.
How is that in any way different from your proposal that fixes it
in MPlayer?
Also that operation isn't any slower than normal seeking (assuming
the seek is not within the cache).
Huh? With your patch, MPlayer would send a seek stream ctrl to the
cache, and would have to do a blocking wait for the cache process. It
can't know whether the implementation is even implemented before
sending the stream ctrl.
That is in no way different from implementing it in MPlayer, unless you
compared doing a hack of only calling stream seek if the stream type is
bluray but not doing that optimization in the read_seek function.
The difference is that libavformat does NOT know if you're using
libbluray somewhere, while the application does.
On the other hand, handling read_seek might be absolutely required by
someone who implements avio callbacks for use with a demuxer, because
else seeking will break with obscure formats (like rtmp).
So the question is: what do you do if your ts (or anything else) is
actually in a seekable file, and you don't want libavformat to invoke
the read_seek callback? This is not possible without having full
knowledge which formats call read_seek just because, and which really
need it for working seeking.
But then the speed difference is because you compare different
implementations.
Also this only applies to cases where the read_seek is not supported.
In other cases the performance is unchanged.
But this is the more common case...
Also it only doubles the round-trip latency which if that really is
significant is an issue that needs to be fixed at the source.
Probably, but note that MPlayer-style byte caches can be read and
seeked even if the underlying stream is stuck and blocked. And if that
is not an issue, why have a cache at all?
This fixes only one specific single case and it doesn't help an
application that wants to combine its own bluray handling (for example
using something other than libbluray) with FFmpeg's demuxer, they
still need to hack up their own seeking code for that and then
beat FFmpeg it not seeking on its own, and manually reset the demuxer
etc.
Absolutely nothing stops the application from doing its own seeking for
formats like mpeg-ts. Though what you need is a function that flushes
internal libavformat buffers to make sure no old data is read after the
stream-level seek was performed. (Currently I execute a byte seek to
the current position to achieve this flushing.)
And this horribly broken, unreliable, crappy hack is supposed to be a better
solution?
The absolute minimum for me to consider that acceptable would be a working,
tested, official resync function (we really don't have that yet for
demuxers?).
What are you talking about? My MPlayer fork uses libavformat with
libbluray just fine, while MPlayer doesn't and _can't_.
The only hack about this is that libavformat doesn't provide a proper
flush function. It could be easily added.
Either way the read_seek is there, and until such time someone removes
it I am not inclined to consider it a good idea to keep it broken!
It's not broken. If the fact that mpeg-ts doesn't use it means it's
broken, you're going to have to apply the same patch to a lot of
demuxers.
And again, I don't understand why you can't just redirect the seek in
demux_lavf.c. This would be an easy fix for the MPlayer problem.
Because I want FFmpeg to work well, not make both projects a crap
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: enable psnr reporting when requested by the user
On 9/28/2014 3:46 AM, Michael Niedermayer wrote: applied Sorry I missed that, been very busy lately. Luckily the patch seems OK. Is there a similar flag for SSIM? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, Sep 28, 2014 at 10:15:51AM +0200, wm4 wrote:
On Sun, 21 Sep 2014 10:17:16 +0100
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 3434341..c04e156 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2659,6 +2659,12 @@ void ff_mpegts_parse_close(MpegTSContext *ts)
av_free(ts);
}
+static int mpegts_read_seek(AVFormatContext *s, int stream_index,
+int64_t ts, int flags)
+{
+return avio_seek_time(s-pb, stream_index, ts, flags);
+}
+
AVInputFormat ff_mpegts_demuxer = {
.name = mpegts,
.long_name = NULL_IF_CONFIG_SMALL(MPEG-TS (MPEG-2 Transport
Stream)),
@@ -2668,6 +2674,7 @@ AVInputFormat ff_mpegts_demuxer = {
.read_packet= mpegts_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegts_class,
};
@@ -2680,6 +2687,7 @@ AVInputFormat ff_mpegtsraw_demuxer = {
.read_packet= mpegts_raw_read_packet,
.read_close = mpegts_read_close,
.read_timestamp = mpegts_get_dts,
+.read_seek = mpegts_read_seek,
.flags = AVFMT_SHOW_IDS | AVFMT_TS_DISCONT,
.priv_class = mpegtsraw_class,
};
IMO this is not a good idea. Seeking should seek the stream to a
timestamp; but the demuxer will output mismatching timestamps with a
different offset!
Oh well.
This is actually what makes it not work in MPlayer.
Plus I think it's a bug that MPlayer ends up calling the demuxer
seek code in the first place.
So thanks for making me think once more.
I still think all this is a mess that needs to be improved
on _FFmpeg_ side, but I am not quite sure how anymore.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, Sep 28, 2014 at 01:52:45PM +0200, wm4 wrote: On Sun, 28 Sep 2014 13:37:59 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: That's not how the libavformat seeking API works. If you want a different layer, use something from the different layer. E.g. seek avio directly, and flush the demuxer's buffers. Which as you mention later is only possible with messy hacks. All you need is something like av_format_flush(ctx). To be honest I'm kind of shocked we don't have it. I am bit surprised that things even work as well as they do, MPlayer kind of assumes such a function is implemented in the demuxer. So the question is: what do you do if your ts (or anything else) is actually in a seekable file, and you don't want libavformat to invoke the read_seek callback? This is not possible without having full knowledge which formats call read_seek just because, and which really need it for working seeking. I admit I would have assumed that you'd always want them to use read_seek if the stream layer provides one, including when they can seek (mostly?) fine without. But then the speed difference is because you compare different implementations. Also this only applies to cases where the read_seek is not supported. In other cases the performance is unchanged. But this is the more common case... Yes, but it wasn't what I thought you were referring to, so misunderstanding here. Also it only doubles the round-trip latency which if that really is significant is an issue that needs to be fixed at the source. Probably, but note that MPlayer-style byte caches can be read and seeked even if the underlying stream is stuck and blocked. And if that is not an issue, why have a cache at all? Because it is quite important for formats like MOV/MP4 where you constantly seek during playback, there every millisecond matters. For the seek itself I assumed that a few milliseconds extra are not a big deal. Absolutely nothing stops the application from doing its own seeking for formats like mpeg-ts. Though what you need is a function that flushes internal libavformat buffers to make sure no old data is read after the stream-level seek was performed. (Currently I execute a byte seek to the current position to achieve this flushing.) And this horribly broken, unreliable, crappy hack is supposed to be a better solution? The absolute minimum for me to consider that acceptable would be a working, tested, official resync function (we really don't have that yet for demuxers?). What are you talking about? My MPlayer fork uses libavformat with libbluray just fine, while MPlayer doesn't and _can't_. Actually I think MPlayer works mostly fine with it now, and admittedly without this patch. Except for it missing that one hack for flushing. Am I missing something why you claim it can't? The only hack about this is that libavformat doesn't provide a proper flush function. It could be easily added. Do you volunteer? :-) Either way the read_seek is there, and until such time someone removes it I am not inclined to consider it a good idea to keep it broken! It's not broken. If the fact that mpeg-ts doesn't use it means it's broken, you're going to have to apply the same patch to a lot of demuxers. And again, I don't understand why you can't just redirect the seek in demux_lavf.c. This would be an easy fix for the MPlayer problem. Because I want FFmpeg to work well, not make both projects a crap heap by adding workarounds in one around issues in the other. I just suggested a clean solution. If you don't want to listen, fine, pursue your shitty hacks to keep an aging codebase working. See, that's where our disagreement comes from: I considered your approach the shitty hack (well, not quite that much, but a bit). I'll not completely revise that until we have a proper flush function. :) I also still think it kind of would be nice if anyone could implement a protocol that can help with seeking just by providing a time seek function instead of hacking every single application to manually call a stream seek. But with the problems you mention and it being pointless for MPlayer on top it might be better to deal with it when someone has a use for it. So I'll retract the patch. Btw.: mmsh.c seems to have a read_seek, too. Reimar P.S.: I hope you forgive me for the flinging of terms like crap and hack, I think I was too extreme there, even ignoring the parts where I was wrong. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: enable psnr reporting when requested by the user
On Sun, Sep 28, 2014 at 01:06:17PM +0100, Derek Buitenhuis wrote: On 9/28/2014 3:46 AM, Michael Niedermayer wrote: applied Sorry I missed that, been very busy lately. Luckily the patch seems OK. Is there a similar flag for SSIM? i dont think so, also libxvid and libx264 use private AVOptions for ssim, [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: enable psnr reporting when requested by the user
On 9/28/2014 2:26 PM, Michael Niedermayer wrote: i dont think so, also libxvid and libx264 use private AVOptions for ssim, OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/lls: Make unchanged function arguments const
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavutil/lls.c |4 ++--
libavutil/lls.h |4 ++--
libavutil/x86/lls_init.c |6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavutil/lls.c b/libavutil/lls.c
index 06fe423..f77043b 100644
--- a/libavutil/lls.c
+++ b/libavutil/lls.c
@@ -32,7 +32,7 @@
#include version.h
#include lls.h
-static void update_lls(LLSModel *m, double *var)
+static void update_lls(LLSModel *m, const double *var)
{
int i, j;
@@ -100,7 +100,7 @@ void avpriv_solve_lls(LLSModel *m, double threshold,
unsigned short min_order)
}
}
-static double evaluate_lls(LLSModel *m, double *param, int order)
+static double evaluate_lls(LLSModel *m, const double *param, int order)
{
int i;
double out = 0;
diff --git a/libavutil/lls.h b/libavutil/lls.h
index 46f9606..5635b5b 100644
--- a/libavutil/lls.h
+++ b/libavutil/lls.h
@@ -47,14 +47,14 @@ typedef struct LLSModel {
*32-byte aligned, and any padding elements must be initialized
*(i.e not denormal/nan).
*/
-void (*update_lls)(struct LLSModel *m, double *var);
+void (*update_lls)(struct LLSModel *m, const double *var);
/**
* Inner product of var[] and the LPC coefs.
* @param m this context
* @param var training samples, excluding the value to be predicted.
unaligned.
* @param order lpc order
*/
-double (*evaluate_lls)(struct LLSModel *m, double *var, int order);
+double (*evaluate_lls)(struct LLSModel *m, const double *var, int order);
} LLSModel;
void avpriv_init_lls(LLSModel *m, int indep_count);
diff --git a/libavutil/x86/lls_init.c b/libavutil/x86/lls_init.c
index 181ca38..f531904 100644
--- a/libavutil/x86/lls_init.c
+++ b/libavutil/x86/lls_init.c
@@ -23,9 +23,9 @@
#include libavutil/lls.h
#include libavutil/x86/cpu.h
-void ff_update_lls_sse2(LLSModel *m, double *var);
-void ff_update_lls_avx(LLSModel *m, double *var);
-double ff_evaluate_lls_sse2(LLSModel *m, double *var, int order);
+void ff_update_lls_sse2(LLSModel *m, const double *var);
+void ff_update_lls_avx(LLSModel *m, const double *var);
+double ff_evaluate_lls_sse2(LLSModel *m, const double *var, int order);
av_cold void ff_init_lls_x86(LLSModel *m)
{
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.
On Sun, 28 Sep 2014 14:45:33 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Sep 28, 2014 at 01:52:45PM +0200, wm4 wrote: On Sun, 28 Sep 2014 13:37:59 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: That's not how the libavformat seeking API works. If you want a different layer, use something from the different layer. E.g. seek avio directly, and flush the demuxer's buffers. Which as you mention later is only possible with messy hacks. All you need is something like av_format_flush(ctx). To be honest I'm kind of shocked we don't have it. I am bit surprised that things even work as well as they do, MPlayer kind of assumes such a function is implemented in the demuxer. The builtin demuxers apparently simply didn't need it. With libavformat, there's data buffered for parsing at least. So the question is: what do you do if your ts (or anything else) is actually in a seekable file, and you don't want libavformat to invoke the read_seek callback? This is not possible without having full knowledge which formats call read_seek just because, and which really need it for working seeking. I admit I would have assumed that you'd always want them to use read_seek if the stream layer provides one, including when they can seek (mostly?) fine without. But then the speed difference is because you compare different implementations. Also this only applies to cases where the read_seek is not supported. In other cases the performance is unchanged. But this is the more common case... Yes, but it wasn't what I thought you were referring to, so misunderstanding here. Also it only doubles the round-trip latency which if that really is significant is an issue that needs to be fixed at the source. Probably, but note that MPlayer-style byte caches can be read and seeked even if the underlying stream is stuck and blocked. And if that is not an issue, why have a cache at all? Because it is quite important for formats like MOV/MP4 where you constantly seek during playback, there every millisecond matters. For the seek itself I assumed that a few milliseconds extra are not a big deal. True enough. Though... I don't know well enough about mp4 seek access patterns (just that they're inefficient), but you can run into trouble even with a large seekback cache. Absolutely nothing stops the application from doing its own seeking for formats like mpeg-ts. Though what you need is a function that flushes internal libavformat buffers to make sure no old data is read after the stream-level seek was performed. (Currently I execute a byte seek to the current position to achieve this flushing.) And this horribly broken, unreliable, crappy hack is supposed to be a better solution? The absolute minimum for me to consider that acceptable would be a working, tested, official resync function (we really don't have that yet for demuxers?). What are you talking about? My MPlayer fork uses libavformat with libbluray just fine, while MPlayer doesn't and _can't_. Actually I think MPlayer works mostly fine with it now, and admittedly without this patch. Except for it missing that one hack for flushing. Am I missing something why you claim it can't? You just implemented passing through the stream PTS stuff, so it should probably be mostly fine now. The only hack about this is that libavformat doesn't provide a proper flush function. It could be easily added. Do you volunteer? :-) Sure. I was already wondering how to implement it. One issue is with which formats such an API makes sense at all, and whether there is a need for a AVInputFormat.flush callback. Currently, I'm thinking it would be fine if the implementation only drops buffers, with no further sanity checks. (It would just break the data stream when used with formats which don't/can't support it.) I'm wondering whether the function should make efforts to flush the AVIOContext too. Either way the read_seek is there, and until such time someone removes it I am not inclined to consider it a good idea to keep it broken! It's not broken. If the fact that mpeg-ts doesn't use it means it's broken, you're going to have to apply the same patch to a lot of demuxers. And again, I don't understand why you can't just redirect the seek in demux_lavf.c. This would be an easy fix for the MPlayer problem. Because I want FFmpeg to work well, not make both projects a crap heap by adding workarounds in one around issues in the other. I just suggested a clean solution. If you don't want to listen, fine, pursue your shitty hacks to keep an aging codebase working. See, that's where our disagreement comes from: I considered your approach the shitty hack (well, not quite that much, but a bit). I'll not completely revise that until we have a proper flush function. :) I also
Re: [FFmpeg-devel] [PATCH] avutil/lls: Make unchanged function arguments const
On 9/28/14, Michael Niedermayer michae...@gmx.at wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/lls.c |4 ++-- libavutil/lls.h |4 ++-- libavutil/x86/lls_init.c |6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compiling on MAC OSX10.9 crashes on =10.85
thanks for the answer, I tried this, and it's still crashing on 10.85 (I did not even test 10.7) is there a general hint how to configure this correct (as shared libs), I only need the standard codec's while I only read a hls/apple http stream form the net and write it to a mpegts file Georg -Ursprüngliche Nachricht- Von: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag von Hendrik Leppkes Gesendet: Samstag, 27. September 2014 09:29 An: FFmpeg development discussions and patches Betreff: Re: [FFmpeg-devel] compiling on MAC OSX10.9 crashes on =10.85 On Sat, Sep 27, 2014 at 5:45 AM, Georg Stein georg_st...@t-online.de wrote: Hello, i compiled ffmpeg under macosx 10.9 and had to find out, that my app what uses libavformat is crashing on mac osx up to 10.85 Use --extra-cflags=-mmacosx-version-min=10.8 .. or 10.6, or whatever is your minimal target. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/lls: Make unchanged function arguments const
On Sun, Sep 28, 2014 at 04:16:36PM +, Paul B Mahol wrote: On 9/28/14, Michael Niedermayer michae...@gmx.at wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/lls.c |4 ++-- libavutil/lls.h |4 ++-- libavutil/x86/lls_init.c |6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) probably ok applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Do not add palette size to the bitmapheader size
Hi! Attached patch is the first part of the fix for ticket #1304. Please comment, Carl Eugen diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c index 2eb2ae1..cf235c1 100644 --- a/libavformat/riffenc.c +++ b/libavformat/riffenc.c @@ -212,6 +212,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc, int keep_height = enc-extradata_size = 9 !memcmp(enc-extradata + enc-extradata_size - 9, BottomUp, 9); int extradata_size = enc-extradata_size - 9*keep_height; +if (enc-pix_fmt == AV_PIX_FMT_PAL8 extradata_size = AVPALETTE_SIZE) +extradata_size -= AVPALETTE_SIZE; /* size */ avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size)); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Set the rawvideo image size to 0 in the bitmapinfoheader
Hi!
Attached patch fixes ticket #1304: biSizeImage may be 0 for images with codec
tag 0, if the size is set too small, WMP refuses to play the file.
Please comment, Carl Eugen
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 2eb2ae1..9e30f64 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -224,7 +224,11 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext
*enc,
avio_wl16(pb, enc-bits_per_coded_sample ? enc-bits_per_coded_sample :
24);
/* compression type */
avio_wl32(pb, enc-codec_tag);
+if (!enc-codec_tag) {
+avio_wl32(pb, 0);
+} else {
avio_wl32(pb, (enc-width * enc-height * (enc-bits_per_coded_sample ?
enc-bits_per_coded_sample : 24)+7) / 8);
+}
avio_wl32(pb, 0);
avio_wl32(pb, 0);
avio_wl32(pb, 0);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix 32bit pcm audio in mov
Hi! Attached patch fixes decoding 32bit pcm audio in mov as written by the Convergent Design's Odyssey 7Q recorder. Please comment, Carl Eugen diff --git a/libavformat/mov.c b/libavformat/mov.c index ae48c02..8070b4d 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -1422,6 +1422,10 @@ static void mov_parse_stsd_audio(MOVContext *c, AVIOContext *pb, st-codec-codec_id = st-codec-codec_id == AV_CODEC_ID_PCM_S16BE ? AV_CODEC_ID_PCM_S24BE : AV_CODEC_ID_PCM_S24LE; +else if (st-codec-bits_per_coded_sample == 32) + st-codec-codec_id = +st-codec-codec_id == AV_CODEC_ID_PCM_S16BE ? +AV_CODEC_ID_PCM_S32BE : AV_CODEC_ID_PCM_S32LE; break; /* set values for old format before stsd version 1 appeared */ case AV_CODEC_ID_MACE3: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/put_bits: Add rebase_put_bits()
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/put_bits.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 8081fb9..f16d04a 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -63,6 +63,23 @@ static inline void init_put_bits(PutBitContext *s, uint8_t
*buffer,
}
/**
+ * Rebase the bit writer onto a reallocted buffer.
+ *
+ * @param buffer the buffer where to put bits
+ * @param buffer_size the size in bytes of buffer
+ */
+static inline void rebase_put_bits(PutBitContext *s, uint8_t *buffer,
+ int buffer_size)
+{
+av_assert0(8*buffer_size s-size_in_bits);
+
+s-buf_end = buffer + buffer_size;
+s-buf_ptr = buffer + (s-buf_ptr - s-buf);
+s-buf = buffer;
+s-size_in_bits = 8 * buffer_size;
+}
+
+/**
* @return the total number of bits written to the bitstream.
*/
static inline int put_bits_count(PutBitContext *s)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/utils: Fix off by 1 error causing unneeded allocation in ff_fast_malloc()
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/utils.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index b27f918..9eb2b5b 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -122,7 +122,7 @@ static void *avformat_mutex;
static inline int ff_fast_malloc(void *ptr, unsigned int *size, size_t
min_size, int zero_realloc)
{
void **p = ptr;
-if (min_size *size)
+if (min_size = *size *p)
return 0;
min_size = FFMAX(17 * min_size / 16 + 32, min_size);
av_free(*p);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/mpegvideo_enc: Allocate only a small buffer and reallocate as needed
This should reduce the memory requirement
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/mpegvideo_enc.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 81298c8..045ef3d 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1701,7 +1701,11 @@ int ff_mpv_encode_picture(AVCodecContext *avctx,
AVPacket *pkt,
/* output? */
if (s-new_picture.f-data[0]) {
-if ((ret = ff_alloc_packet2(avctx, pkt,
s-mb_width*s-mb_height*(MAX_MB_BYTES+100)+1)) 0)
+int growing_buffer = context_count == 1 !pkt-data
!s-data_partitioning;
+int pkt_size = growing_buffer ?
FFMAX(s-mb_width*s-mb_height*64+1, avctx-internal-byte_buffer_size) -
FF_INPUT_BUFFER_PADDING_SIZE
+ :
+
s-mb_width*s-mb_height*(MAX_MB_BYTES+100)+1;
+if ((ret = ff_alloc_packet2(avctx, pkt, pkt_size)) 0)
return ret;
if (s-mb_info) {
s-mb_info_ptr = av_packet_new_side_data(pkt,
@@ -1726,7 +1730,13 @@ int ff_mpv_encode_picture(AVCodecContext *avctx,
AVPacket *pkt,
if (ret 0)
return ret;
vbv_retry:
-if (encode_picture(s, s-picture_number) 0)
+ret = encode_picture(s, s-picture_number);
+if (growing_buffer) {
+av_assert0(s-pb.buf == avctx-internal-byte_buffer);
+pkt-data = s-pb.buf;
+pkt-size = avctx-internal-byte_buffer_size;
+}
+if (ret 0)
return -1;
avctx-header_bits = s-header_bits;
@@ -2770,6 +2780,28 @@ static int encode_thread(AVCodecContext *c, void *arg){
int dmin= INT_MAX;
int dir;
+if ( s-pb.buf_end - s-pb.buf - (put_bits_count(s-pb)3)
MAX_MB_BYTES
+ s-slice_context_count == 1
+ s-pb.buf == s-avctx-internal-byte_buffer) {
+int new_size = s-avctx-internal-byte_buffer_size
+ + s-avctx-internal-byte_buffer_size/4
+ + s-mb_width*MAX_MB_BYTES;
+int lastgob_pos = s-ptr_lastgob - s-pb.buf;
+int vbv_pos = s-vbv_delay_ptr - s-pb.buf;
+
+uint8_t *new_buffer = NULL;
+int new_buffer_size = 0;
+
+av_fast_padded_malloc(new_buffer, new_buffer_size, new_size);
+if (new_buffer) {
+memcpy(new_buffer, s-avctx-internal-byte_buffer,
s-avctx-internal-byte_buffer_size);
+s-avctx-internal-byte_buffer = new_buffer;
+s-avctx-internal-byte_buffer_size = new_buffer_size;
+rebase_put_bits(s-pb, new_buffer, new_buffer_size);
+s-ptr_lastgob = s-pb.buf + lastgob_pos;
+s-vbv_delay_ptr = s-pb.buf + vbv_pos;
+}
+}
if(s-pb.buf_end - s-pb.buf - (put_bits_count(s-pb)3)
MAX_MB_BYTES){
av_log(s-avctx, AV_LOG_ERROR, encoded frame too large\n);
return -1;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
