On Mon, Jan 12, 2015 at 01:11:21AM +0530, Anshul wrote:
On 01/06/2015 12:29 PM, Anshul Maheshwari wrote:
On Tue, Jan 6, 2015 at 5:47 AM, Michael Niedermayer michae...@gmx.at
mailto:michae...@gmx.at wrote:
On Mon, Jan 05, 2015 at 06:20:15PM +0530, Anshul wrote:
On 01/04/2015
no, there where some comments on IRC but IIRC they where along the
lines of future improvments not objections/blocking
Has any work been done on whether this implementation matches the
reference vectors as I mentioned on IRC?
Kieran
___
ffmpeg-devel
On Sun, Jan 11, 2015 at 10:21:16PM +, Kieran Kunhya wrote:
no, there where some comments on IRC but IIRC they where along the
lines of future improvments not objections/blocking
Has any work been done on whether this implementation matches the
reference vectors as I mentioned on IRC?
On Tue, Jan 6, 2015 at 5:47 AM, Michael Niedermayer michae...@gmx.at
wrote:
On Mon, Jan 05, 2015 at 06:20:15PM +0530, Anshul wrote:
On 01/04/2015 10:17 PM, Michael Niedermayer wrote:
the table is constant and does not change, theres no need to have
a copy of it in each context or to make
On 01/04/2015 10:17 PM, Michael Niedermayer wrote:
the table is constant and does not change, theres no need to have
a copy of it in each context or to make it every time decode is
called
a simple static uint8_t parity_table[256];
or even
static const uint8_t parity_table[256] = {...}
done
On Mon, Jan 05, 2015 at 06:20:15PM +0530, Anshul wrote:
On 01/04/2015 10:17 PM, Michael Niedermayer wrote:
the table is constant and does not change, theres no need to have
a copy of it in each context or to make it every time decode is
called
a simple static uint8_t parity_table[256];
On 01/03/2015 08:40 PM, Michael Niedermayer wrote:
On Sat, Jan 03, 2015 at 12:57:04PM +0530, Anshul wrote:
On 01/03/2015 01:42 AM, Michael Niedermayer wrote:
On Wed, Dec 31, 2014 at 07:09:33PM +0530, Anshul wrote:
[..]
Makefile |1
allcodecs.c|1
ccaption_dec.c | 361
On Sun, Jan 04, 2015 at 08:21:51PM +0530, Anshul wrote:
On 01/03/2015 08:40 PM, Michael Niedermayer wrote:
On Sat, Jan 03, 2015 at 12:57:04PM +0530, Anshul wrote:
On 01/03/2015 01:42 AM, Michael Niedermayer wrote:
On Wed, Dec 31, 2014 at 07:09:33PM +0530, Anshul wrote:
[..]
Makefile
On Sun, 4 Jan 2015 17:47:20 +0100
Michael Niedermayer michae...@gmx.at wrote:
+};
+
+
+typedef struct CCaptionSubContext {
+AVClass *class;
+int parity_table[256];
this can be a static uint8_t table
I don't think static variable in structure are allowed in c
On Sun, Jan 4, 2015 at 6:41 PM, wm4 nfx...@googlemail.com wrote:
On Sun, 4 Jan 2015 17:47:20 +0100
Michael Niedermayer michae...@gmx.at wrote:
+};
+
+
+typedef struct CCaptionSubContext {
+AVClass *class;
+int parity_table[256];
this can be a static uint8_t
On Sun, 4 Jan 2015 22:49:16 +0100
Hendrik Leppkes h.lepp...@gmail.com wrote:
On Sun, Jan 4, 2015 at 6:41 PM, wm4 nfx...@googlemail.com wrote:
On Sun, 4 Jan 2015 17:47:20 +0100
Michael Niedermayer michae...@gmx.at wrote:
+};
+
+
+typedef struct CCaptionSubContext {
On Sat, Jan 03, 2015 at 12:57:04PM +0530, Anshul wrote:
On 01/03/2015 01:42 AM, Michael Niedermayer wrote:
On Wed, Dec 31, 2014 at 07:09:33PM +0530, Anshul wrote:
[..]
Makefile |1
allcodecs.c|1
ccaption_dec.c | 361
On Wed, Dec 31, 2014 at 07:09:33PM +0530, Anshul wrote:
[...]
+static void build_parity_table(int *parity_table)
+{
+unsigned int byte;
+int parity_v;
+for (byte = 0; byte = 127; byte++) {
+parity_v = av_popcount(byte) 1;
+parity_table[byte] = parity_v;
+
On 01/03/2015 01:42 AM, Michael Niedermayer wrote:
On Wed, Dec 31, 2014 at 07:09:33PM +0530, Anshul wrote:
[...]
+static void build_parity_table(int *parity_table)
+{
+unsigned int byte;
+int parity_v;
+for (byte = 0; byte = 127; byte++) {
+parity_v = av_popcount(byte)
On 12/12/2014 04:23 PM, Anshul wrote:
On 12/06/2014 04:24 PM, Anshul wrote:
On 12/06/2014 04:22 PM, Anshul wrote:
On 12/05/2014 07:56 PM, Nicolas George wrote:
Hi. I had time to look at the code with some more details. Comments are
below.
From 31f69ccfb45247a7cc203084a931b8523284aa13 Mon
On Tue, Dec 30, 2014 at 07:46:29PM +0530, Anshul wrote:
On 12/12/2014 04:23 PM, Anshul wrote:
On 12/06/2014 04:24 PM, Anshul wrote:
On 12/06/2014 04:22 PM, Anshul wrote:
On 12/05/2014 07:56 PM, Nicolas George wrote:
Hi. I had time to look at the code with some more details. Comments are
On 12/05/2014 07:56 PM, Nicolas George wrote:
Hi. I had time to look at the code with some more details. Comments are
below.
From 31f69ccfb45247a7cc203084a931b8523284aa13 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date: Wed, 3 Dec 2014 23:37:22 +0530
Subject:
On 12/06/2014 04:22 PM, Anshul wrote:
On 12/05/2014 07:56 PM, Nicolas George wrote:
Hi. I had time to look at the code with some more details. Comments are
below.
From 31f69ccfb45247a7cc203084a931b8523284aa13 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date:
Hi. I had time to look at the code with some more details. Comments are
below.
From 31f69ccfb45247a7cc203084a931b8523284aa13 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date: Wed, 3 Dec 2014 23:37:22 +0530
Subject: [PATCH 2/2] Adding Closed caption Decoder
---
Le quartidi 14 frimaire, an CCXXIII, Anshul a écrit :
It would be valid, c708 is backward compatible as far as
I have seen while working with ccextractor.
C708 is made in such a way that people dont have to throw there older TV
sets or device.
if any decoder is not able to decode c708 part,
Furthermore, I do not see any ASS styling in the decoder, that would be a
good test case.
Captions shouldn't be ASS styled - they should be styled as per the
specification (see VLC).
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Thu, Dec 04, 2014 at 11:32:40AM +, Kieran Kunhya wrote:
Furthermore, I do not see any ASS styling in the decoder, that would be a
good test case.
Captions shouldn't be ASS styled - they should be styled as per the
specification (see VLC).
I'd be surprised if you can't get close
Le quartidi 14 frimaire, an CCXXIII, Kieran Kunhya a écrit :
Captions shouldn't be ASS styled - they should be styled as per the
specification (see VLC).
You are certainly right, but we are talking about a decoder, and FFmpeg's
internal format for decoded text subtitles is still ASS. If
Le quartidi 14 frimaire, an CCXXIII, Anshul a écrit :
Yes while doing that only I realized, if we use i then cc must be in
first stream.
When I had multiple stream(with audio), then I was not able to map subcc
to my video stream.
using stream_idx , we are saying that if we can use
On Thu, Dec 4, 2014 at 5:43 PM, Nicolas George geo...@nsup.org wrote:
Le quartidi 14 frimaire, an CCXXIII, Anshul a écrit :
Yes while doing that only I realized, if we use i then cc must be in
first stream.
When I had multiple stream(with audio), then I was not able to map subcc
to my
Le quartidi 14 frimaire, an CCXXIII, Anshul Maheshwari a écrit :
while with stream_idx, even if I you dont know where is video and audio it
works.
I do not think so, I suspect it only worked by chance. You may as well end
up trying to extract subcc from audio, or in a completely random order.
From: Anshul Maheshwari anshul.ffm...@gmail.com
---
I did implement lots of other thing, with respect to older patch.
like multi screen and rollup feature.
This implementation is working well with srt output format.
As of now ffplay is not able to show the decoded frames on screen.
I dont know
Le tridi 13 frimaire, an CCXXIII, anshul.ffm...@gmail.com a écrit :
Subject: Re: [FFmpeg-devel] [PATCH 2/2] Adding closed caption decoder
Very good news!
I did implement lots of other thing, with respect to older patch.
like multi screen and rollup feature.
This implementation is working
On 12/03/2014 10:19 PM, Clément Bœsch wrote:
unless i'm mistaken, i think you just want:
return av_popcount(val 0x7f) 1;
Thanks I was searching for this, even I asked for same on Irc.
Nicolas: The changes from your pair of patch,
1) I removed c708 part (whole) since both are same, 708
Le tridi 13 frimaire, an CCXXIII, Anshul a écrit :
Thanks I was searching for this, even I asked for same on Irc.
Nicolas: The changes from your pair of patch,
1) I removed c708 part (whole) since both are same, 708 just have some
extra feature then 608.
In your first patch it was just
On 12/04/2014 02:33 AM, Nicolas George wrote:
Le tridi 13 frimaire, an CCXXIII, Anshul a écrit :
Thanks I was searching for this, even I asked for same on Irc.
Nicolas: The changes from your pair of patch,
1) I removed c708 part (whole) since both are same, 708 just have some
extra feature
31 matches
Mail list logo
