gmane.comp.video.ffmpeg.devel

[PATCH] libopenjpegdec: decode images with bpcbetween 10 and 16

Jean First — 2012-05-22T16:53:32

Signed-off-by: Jean First <jeanfirst< at >gmail.com>
---
 libavcodec/libopenjpegdec.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 9928adb..5aeb265 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
< at >< at > -80,6 +80,14 < at >< at > static inline int libopenjpeg_matches_pix_fmt(const opj_image_t *image, enum Pix
         break;
     }
 
+    if (descriptor.nb_components == 3) {
+        if (descriptor.comp[2].depth_minus1 == 15 && image->comps[2].prec > 10 && image->comps[2].prec < 16 &&
+            1 << descriptor.log2_chroma_w == image->comps[2].dx &&
+            1 << descriptor.log2_chroma_h == image->comps[2].dy) {
+            match = 1;
+        }
+    }
+
     return match;
 }

Re: DVBSUBS and TXTSUBS

Clément Bœsch — 2012-05-22T16:52:54

This comment from Nicolas in the Trac summarizes pretty well the
situation: https://ffmpeg.org/trac/ffmpeg/ticket/1305#comment:2

Now that things seem to calm down with the audio in lavfi, we might want
to consider working again on subtitles to do the burning in lavfi (and
various other changes).

But before I start working on "architecture" stuff like this, I'd like to
check if Libav won't plan to rewrite everything differently in a few
months, like they did for the audio processing, audio filtering and now
writers in ffprobe.

[...]

Re: [PATCH] libopenjpegdec: decode images with bpc between 10 and 16

Jean First — 2012-05-22T16:52:01

this patch hase some cosmetic glitches - I'll send a new one in a minute.

Re: FFV1.3

Peter B. — 2012-05-22T16:51:29

Oh, and: how can I test the new features of ffv1.3's bitstream, like CRC
and so?

Thanks again,
Pb

Re: FFV1.3

Peter B. — 2012-05-22T16:50:59

Oh, yes: I'm also looking forward to see how 2-pass mode performs
compression-wise.

Just so I understood you correctly:
Are you saying to generate pass-statistics for one file (e.g.
video_01.avi) and then use these statistics for *another* (?) file (e.g.
video_02.avi)?

From how I understand multi-pass encoding, I was assuming that each
2nd-pass requires the statistics for exactly the file to be encoded, but
your message sounds like these stats could be re-used generally somehow?
If so: How does that work? These stats are generated from the content,
so I thought they are highly content-specific?

Thanks,
Pb

[PATCH] libopenjpegdec: decode images with bpcbetween 10 and 16

Jean First — 2012-05-22T16:49:17

regression since b7a928b2d1563575a8d9ec5aa606f735620b38ab

Signed-off-by: Jean First <jeanfirst< at >gmail.com>
---
 libavcodec/libopenjpegdec.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 9928adb..6654e5a 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
< at >< at > -80,6 +80,14 < at >< at > static inline int libopenjpeg_matches_pix_fmt(const opj_image_t *image, enum Pix
         break;
     }
 
+    if ( descriptor.nb_components == 3 ) {
+        if ( descriptor.comp[2].depth_minus1 == 15 && image->comps[2].prec > 10 && image->comps[2].prec < 16  &&
+             1 << descriptor.log2_chroma_w == image->comps[2].dx &&
+             1 << descriptor.log2_chroma_h == image->comps[2].dy ) {
+            match = 1;
+        }
+    }
+
     return match;
 }

Re: Static Link library exception to LGPL

Don Moir — 2012-05-22T16:37:12

----- Original Message ----- 
From: "Carl Eugen Hoyos" <cehoyos< at >ag.or.at>
To: <ffmpeg-devel< at >ffmpeg.org>
Sent: Tuesday, May 22, 2012 4:47 AM
Subject: Re: [FFmpeg-devel] Static Link library exception to LGPL

Should point 2 be changed to mention if you static link, you need to provide 
the lib files for relinking? As it stands, using dlls reads as a 
requirement.

Re: [PATCH] Optimization of AMR NB and WBdecodersfor MIPS

Michael Niedermayer — 2012-05-22T15:31:44

Hi

On Mon, May 21, 2012 at 03:12:58PM +0000, Babic, Nedeljko wrote:

that is a shitty design, i would suggest that this is fixed either
in kernel or hardware so that theres a portable way to get this
information from user space at least in the medium term future.



for functions that could be optimized in SIMD SSE* easily, structures
with function pointers should be added. Because SSE is runtime
detectable and once SSE optimizations for them are written there will
be function pointers in structures for them. It would be quite
inconvenient if we had a different system for these cases for MIPS in
place at that point.



what kind of maintaince burden do you see with this case here ?


[...]

Re: [PATCH] matroska: Identify S_TEXT/UTF-8 tracks as SRT and not TEXT.

Nicolas George — 2012-05-22T14:59:49

Le tridi 3 prairial, an CCXX, Philip Langdale a écrit :

Before that, we have to ask: What is a decoded subtitle?

We know what a decoded video frame is: array(s) of pixel values. We know
what a decoded audio frame is: array(s) or PCM sample values.

But we do not have consensus on what decoded data is supposed to look like
for text-based subtitles format. Surely it consists mostly of text. But what
about markup?

Once there is a clear policy about that, we can start worrying about what is
the role of the demuxer and what is the role of the decoder.

My opinion:

* Decoded text subtitles should be in a structure where the time and
  duration is stored as a number, and the text in a string without the
  timing information.

* The text should always be in Unicode (probably UTF-8, but using ints
  instead of chars is also a reasonable option (wchar_t is not)).

* For the markup, two options:

  - Choose / invent a universal markup syntax and always convert to/from it.

  - Handle markup syntax more or less th

Re: DVBSUBS and TXTSUBS

Michael Niedermayer — 2012-05-22T14:45:43

i think there where no major changes, but maybe ubitux, iive or some
other subtitle experts could comment ?


[...]

Re: vf_pts and pts jumps

Michael Niedermayer — 2012-05-22T14:07:09

maybe see:
dts_delta_threshold and dts_error_threshold and related code
in ffmpeg.c

[...]

Re: looping input and pts rollover

Michael Niedermayer — 2012-05-22T14:03:26

I consider rollovers a special case of timestamp discontinuities
(resets to 0 are not uncommon)

If you want to handle them in a fixpts filter, this filter will have to
correct all the streams together because if its done independantly
for audio and video each could get a slightly different correction
offset and end with AV desync

also one disadvantage of removing the discontinuities before the
filters is that it becomes impossible to preserve them. There was
at least 1 user who wanted that though i dont remember the exact
reason why. (it was somthing with cuting and concatenating of mpegs)

[...]

Re: looping input and pts rollover

Robert Nagy — 2012-05-22T13:48:18

Right, sorry, I forgot about that,

Re: vf_pts and pts jumps

Robert Nagy — 2012-05-22T13:47:46

I guess this could also be handled by the fixpts filter Nicolas George suggests.

REQUEST: Thread-safe avfilter_yyy_buffer

Robert Nagy — 2012-05-22T13:40:56

I would like to request that avfilter_ref_buffer and
avfilter_unref_buffer would be thread-safe. As it is now it is a bit
complicated to use lavfi in third party applications where I either
have to copy the buffer data or make sure that all buffers are
deallocated on the same thread as the graph is running (which is not
always trivial).

Right now I solve this by wrapping AVFilterBufferRef objects into
another thread safe reference counted object which on ref == 0 puts
instances into a thread safe queue which is emptied everytime the
graph is called (correct thread). I feel this is a bit overly complex.

Re: looping input and pts rollover

Nicolas George — 2012-05-22T13:38:38

Le quartidi 4 prairial, an CCXX, Robert Nagy a écrit :

I told you my opinion about this last time you raised it, and it has not
changed yet: rollovers should be corrected before entry into the filter
system, or at words just after with a fixpts filter.

That way, no need for anything, no reinit, no review, no duplicated code.

Regards,

vf_pts and pts jumps

Robert Nagy — 2012-05-22T13:35:25

I've noticed that sometimes when during the first second of playing
mpegts streams a pts jump can occur which can pretty much mess up
playback.

e.g.

pts

8000000
8500000
8501000
8502000

Maybe we should add a configurable threshold for the max pts delta,
and if this threshold is exceeded reset the origin pts?

looping input and pts rollover

Robert Nagy — 2012-05-22T13:33:10

We had a short discussion on IRC regarding looping input.

The problem today is that lavfi does not guarantee proper handling of
rollover pts (which happens with e.g. looping input), which means that
either the filter graph needs to be flushed and reinit at the same
time as avcodec_flush_buffers.

From the discussion I think the general consensus was that graph
reinit would be to complicated, thus I believe we need to review the
filters.

As far as I know vf_yadif and vf_fps needs to be updated for this. Not
sure about other filters, e.g. aresample?

Re: [PATCH 4/4] rawdec: force timestamps from codecto be used

Michael Niedermayer — 2012-05-22T13:17:09

applied

[...]

Re: [PATCH 2/4] mpeg4videoparser: support usingtimestamps from codec.

Michael Niedermayer — 2012-05-22T13:16:52

applied

[...]

Re: [PATCH 3/4] avformat: add needs_parsing type toenable codec TS use.

Michael Niedermayer — 2012-05-22T13:16:37

applied

[...]