Re: [PATCH] vf_overlay: add logic for avoiding overlaying frames with PTS > main frame PTS

On 1/10/12, Stefano Sabatini <stefasab <at> gmail.com> wrote:
> On date Tuesday 2012-01-10 00:30:12 +0000, Paul B Mahol encoded:
>> On 1/10/12, Stefano Sabatini <stefasab <at> gmail.com> wrote:
>> > Also add debug logging messages for helping tracking down similar
>> > issues.
>> >
>> > Fix trac ticket #467.
>> > ---
>> >  libavfilter/vf_overlay.c |   41
>> > +++++++++++++++++++++++++++++------------
>> >  1 files changed, 29 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
>> > index 062783e..9600061 100644
>> > --- a/libavfilter/vf_overlay.c
>> > +++ b/libavfilter/vf_overlay.c
>> > @@ -25,6 +25,8 @@
>> >   * overlay one video on top of another
>> >   */
>> >
>> > +/* #define DEBUG */
>>
>> Is this really needed?
>
> It's handy for me since I need just a few keystrokes for
> enabling/disabling it. Also it shows that there is debug code in the
> file.
>
>> > +
>> >  #include "avfilter.h"

Re: [PATCH] avidec: Mark first frame as keyframe incase there are no keyframes.

>>> This fixes seeking in filecopy.avi of Ticket504

>> This doesn't seem right to me to handle at demuxer level.
>> For example for an auto-generated index the demuxer will not even be able 
>> to do such a hack.
>> It seems more sensible for me for the seeking function to validate the 
>> index and have some fallback behaviour if it does not make sense.

> well, that would make seeking O(n) while its O(log n) ATM, we at least
> have to validate during adding index entries

> and iam not sure if doing this for non avi makes sense (cut mpg surely
> can start with non keyframes)

This might make sense:

If the decoder->read_seek function has failed, go ahead in av_seek_frame 
after read_seek has failed and seek to the byte position of the first of the 
index_entries if there are any. If there are no index_entries, then seek to 
the byte position of whatever the first packet position would be for the 
stream which should be the same as the first of the index_entries if there 
are any.

At this failure point, I don't think we care if the first frame is marked as 
a keyframe or not and the above seems reasonable. Initially there are some 
cases where there are no index_entries. Thats fine and normally these will 
be built as the file is read or when seeking.

The thing about avformat_seek_file failing is you don't know why it failed 
internally. (log messages yes ,but these don't do you any good internally) 

Re: [PATCH] avidec: Mark first frame as keyframeincase there are no keyframes.

>>>> This fixes seeking in filecopy.avi of Ticket504
>
>>> This doesn't seem right to me to handle at demuxer level.
>>> For example for an auto-generated index the demuxer will not even be 
>>> able to do such a hack.
>>> It seems more sensible for me for the seeking function to validate the 
>>> index and have some fallback behaviour if it does not make sense.
>
>> well, that would make seeking O(n) while its O(log n) ATM, we at least
>> have to validate during adding index entries
>
>> and iam not sure if doing this for non avi makes sense (cut mpg surely
>> can start with non keyframes)
>
> This might make sense:
>
> If the decoder->read_seek function has failed, go ahead in av_seek_frame 
> after read_seek has failed and seek to the byte position of the first of 
> the index_entries if there are any. If there are no index_entries, then 
> seek to the byte position of whatever the first packet position would be 
> for the stream which should be the same as the first of the index_entries 
> if there are any.
>
> At this failure point, I don't think we care if the first frame is marked 
> as a keyframe or not and the above seems reasonable. Initially there are 
> some cases where there are no index_entries. Thats fine and normally these 
> will be built as the file is read or when seeking.
>
> The thing about avformat_seek_file failing is you don't know why it failed 
> internally. (log messages yes ,but these don't do you any good internally) 

[PATCH 1/2] ffv1enc: PIX_FMT_YUV440P support

Signed-off-by: Paul B Mahol <onemda <at> gmail.com>
---
 libavcodec/ffv1.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/libavcodec/ffv1.c b/libavcodec/ffv1.c
index 3f69910..874697a 100644
--- a/libavcodec/ffv1.c
+++ b/libavcodec/ffv1.c
@@ -929,6 +929,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
         }
         s->version= FFMAX(s->version, 1);
     case PIX_FMT_YUV444P:
+    case PIX_FMT_YUV440P:
     case PIX_FMT_YUV422P:
     case PIX_FMT_YUV420P:
     case PIX_FMT_YUV411P:
@@ -1815,7 +1816,7 @@ AVCodec ff_ffv1_encoder = {
     .encode         = encode_frame,
     .close          = common_end,
     .capabilities = CODEC_CAP_SLICE_THREADS,
-    .pix_fmts= (const enum PixelFormat[]){PIX_FMT_YUV420P, PIX_FMT_YUVA420P, PIX_FMT_YUV444P,
PIX_FMT_YUVA444P, PIX_FMT_YUV422P, PIX_FMT_YUV411P, PIX_FMT_YUV410P, PIX_FMT_0RGB32,
PIX_FMT_RGB32, PIX_FMT_YUV420P16, PIX_FMT_YUV422P16, PIX_FMT_YUV444P16, PIX_FMT_YUV420P9,
PIX_FMT_YUV420P10, PIX_FMT_YUV422P10, PIX_FMT_NONE},
+    .pix_fmts= (const enum PixelFormat[]){PIX_FMT_YUV420P, PIX_FMT_YUVA420P, PIX_FMT_YUV444P,
PIX_FMT_YUVA444P, PIX_FMT_YUV440P, PIX_FMT_YUV422P, PIX_FMT_YUV411P, PIX_FMT_YUV410P,
PIX_FMT_0RGB32, PIX_FMT_RGB32, PIX_FMT_YUV420P16, PIX_FMT_YUV422P16, PIX_FMT_YUV444P16,
PIX_FMT_YUV420P9, PIX_FMT_YUV420P10, PIX_FMT_YUV422P10, PIX_FMT_NONE},

[PATCH 2/2] ffv1dec: PIX_FMT_YUV440P support

Signed-off-by: Paul B Mahol <onemda <at> gmail.com>
---
 libavcodec/ffv1.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/libavcodec/ffv1.c b/libavcodec/ffv1.c
index 874697a..0ab2b5c 100644
--- a/libavcodec/ffv1.c
+++ b/libavcodec/ffv1.c
@@ -1578,6 +1578,7 @@ static int read_header(FFV1Context *f){
         if(f->avctx->bits_per_raw_sample<=8 && !f->transparency){
             switch(16*f->chroma_h_shift + f->chroma_v_shift){
             case 0x00: f->avctx->pix_fmt= PIX_FMT_YUV444P; break;
+            case 0x01: f->avctx->pix_fmt= PIX_FMT_YUV440P; break;
             case 0x10: f->avctx->pix_fmt= PIX_FMT_YUV422P; break;
             case 0x11: f->avctx->pix_fmt= PIX_FMT_YUV420P; break;
             case 0x20: f->avctx->pix_fmt= PIX_FMT_YUV411P; break;
--

-- 
1.7.7

[PATCH] Fraps: restore old behavior regarding P frames

Recently there have been several commits by Reimar changing the Fraps
decoder behavior regarding P frames, this one being the first one (
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a9b565e0a238b475e036c2e0a77b991cb0a3efb).
These frames are not skip frames, but repeat frames, as seen here (
http://wiki.multimedia.cx/index.php?title=Fraps) and confirmed by looking
at the reference decoder's output. Since Fraps is both a screen capture
codec and a CFR codec, when it records something with a refresh rate slower
than the target fps specified in its settings it adds these repeat frames
to achieve the target framerate.

By removing reget_buffer and outputting nothing when a P frame is reached,
the decoder is now VFR and not compliant because of the reasons explained
above. There can be files with 1 I frame at the beginning and the rest
being P frames, in this situation ffmpeg now outputs only 1 frame for the
entire duration of the sample. I've been talking to Reimar, but he thinks
that since visually a repeated frame and a skip frame are the same, the
current behavior is correct and saves processing power. The problem is that
it renders the output unusable depending on the number of these repeated
frames and it's completely different from the reference decoder's output.
I've written a patch that fixes the regression by outputting these repeated
frames when it should as before, but needs review as the changes required
to do this and MT at the same time are quite large.

When frame multithreading reget_buffer cannot be used, so in order to have
the previous frame available when a repeat frame comes, a 2 frame buffer is
used: the current one and the previous one. This implementation of MT is
almost the same as the one used in the mimic decoder.
 frapsMTv2.patch is attached.

rtpdec_h264.c RTP to annex-b patch

Excuse me if i'm missing something, This is my first time submitting a patch to this group.
This patch formats h264 RTP streams as annex-b format. This allows for transmuxing without transcoding
(e.g "-vcodec copy") RTP and RTSP streams.

 By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        Signed-off-by: Matthew Szatmary <szatmary <at> gmail.com>

Re: [PATCH 1/2] ffv1enc: PIX_FMT_YUV440P support

On Wed, Feb 01, 2012 at 01:54:17AM +0000, Paul B Mahol wrote:
> 
> Signed-off-by: Paul B Mahol <onemda <at> gmail.com>
> ---
>  libavcodec/ffv1.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)

applied, thx

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [PATCH 2/2] ffv1dec: PIX_FMT_YUV440P support

On Wed, Feb 01, 2012 at 01:54:18AM +0000, Paul B Mahol wrote:
> 
> Signed-off-by: Paul B Mahol <onemda <at> gmail.com>
> ---
>  libavcodec/ffv1.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

applied, thx

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [PATCH] Fraps: restore old behavior regarding P frames

On Wed, Feb 01, 2012 at 03:16:47AM +0100, Javier Cabezas wrote:
> Recently there have been several commits by Reimar changing the Fraps
> decoder behavior regarding P frames, this one being the first one (
> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a9b565e0a238b475e036c2e0a77b991cb0a3efb).
> These frames are not skip frames, but repeat frames, as seen here (
> http://wiki.multimedia.cx/index.php?title=Fraps) and confirmed by looking
> at the reference decoder's output. Since Fraps is both a screen capture
> codec and a CFR codec, when it records something with a refresh rate slower
> than the target fps specified in its settings it adds these repeat frames
> to achieve the target framerate.
> 
> By removing reget_buffer and outputting nothing when a P frame is reached,
> the decoder is now VFR and not compliant because of the reasons explained
> above. There can be files with 1 I frame at the beginning and the rest
> being P frames, in this situation ffmpeg now outputs only 1 frame for the
> entire duration of the sample. I've been talking to Reimar, but he thinks
> that since visually a repeated frame and a skip frame are the same, the
> current behavior is correct and saves processing power. The problem is that
> it renders the output unusable depending on the number of these repeated
> frames and it's completely different from the reference decoder's output.
> I've written a patch that fixes the regression by outputting these repeated
> frames when it should as before, but needs review as the changes required
> to do this and MT at the same time are quite large.

It would be alot easier to duplicate the frames in the application
like ffmpeg. Which actually, it should do already when needed.

Also do we have a maintainer for fraps? Or someone who volunteers to
maintain it (maintainer == someone with a git tree who reviews patches
and applies them to his tree and fixes regressions)