Log in

View Full Version : CoreCodec/H.264 Codec "CoreAVC"


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 [115] 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

squid_80
23rd January 2010, 02:53
Is it reliably reproduceable (happens at the same place every time in the same streams) or does it happen at random?
Can you make it happen when the laptop is connected to AC power or does it only happen on battery?
Does it happen with other renderers?

ChronoCross
23rd January 2010, 06:52
The only weird thing I've noticed as of late is in regards to seeking. Sometimes when I seek forward or backward it emits a black screen for 5-6 seconds before restoring video. This may well be my POS machine but I wanted to see if anyone else is having anything similar.

Abradoks
24th January 2010, 07:14
CoreAVC doesn't respect AR when it's specified only in MKV header, but not in the stream. With Haali splitter it works fine, because afaik it overwrites stream AR with one from the header. But it doesn't work with Gabest's splitter. Other decoders (ffdshow, DiAVC) treat this flag correctly.
I've looked for workaround, but haven't found even description of such problem. So, is it known?

puffpio
26th January 2010, 02:07
Is it reliably reproduceable (happens at the same place every time in the same streams) or does it happen at random?
Can you make it happen when the laptop is connected to AC power or does it only happen on battery?
Does it happen with other renderers?

It is not reliably reproducible..it repeatedly happens, but in different spots if i replay the video.

I am on AC power when it happens, I have not tried on battery.

It also happens with the EVR custom renderer..but I don't really use that one since it is very slow for me (since it uses shaders and I don't really have a 3d graphics card)

horvathd
4th February 2010, 22:25
Hi!

I'm trying to encoding a video which has a dark/gray background and dimming lights using x264. When I play back the result with CoreCodec (2.0.0) it is blocky around the lights, but no problem with ffdshow.

Because of rules I don't want to post the video, so I made a small Avisynth script which also produces this bug. You can download the source avs, images, and the encoded video from here: http://www.mediafire.com/?zywom5j0dmk

I used for the encoding of ccbug_wp2 the x264-s default settings. For ccbug_wp0 I disabled the weighted p frames, but it didn't fixed the problem.

Please look into it. Thanks.

squid_80
4th February 2010, 22:33
I can't really see anything wrong when playing the clips in ccbug.zip. Could you post a screenshot of the problem?

horvathd
4th February 2010, 22:42
I got this:
http://i524.photobucket.com/albums/cc329/davhorv112/Misc/th_ccbug_wp2mkv_snapshot_0005_20100204.jpg (http://s524.photobucket.com/albums/cc329/davhorv112/Misc/?action=view&current=ccbug_wp2mkv_snapshot_0005_20100204.jpg)

squid_80
4th February 2010, 22:45
I think you have deblocking disabled. Make sure it is set to "Standard" in CoreAVC's settings.

horvathd
4th February 2010, 22:51
You're right. It was disabled.
I only use CoreCodec when ffdshow can't play the video because of it's resolution, and for the smoother playback I disabled it.

Thanks.

Jiffy
7th February 2010, 10:30
Hi,

Can we have a fix for the weightp problem for CoreAVC 1.x please? It doesn't seem reasonable that people must buy a new version to get the fix.

Thanks.

LoRd_MuldeR
7th February 2010, 20:37
Can we have a fix for the weightp problem for CoreAVC 1.x please? It doesn't seem reasonable that people must buy a new version to get the fix.

Very unlikely. Their answer to the "Weight-P" bug always was that it will be fixed in the upcoming 2.0 version. And 2.0 is out now ;)

Jiffy
7th February 2010, 22:18
Their answer to the "Weight-P" bug always was that it will be fixed in the upcoming 2.0 version. And 2.0 is out now ;)

Yes but if you sell something it has to be fit for purpose, which means that showstopper bugs are supposed to be fixed on your dime.

LoRd_MuldeR
7th February 2010, 23:26
Yes but if you sell something it has to be fit for purpose, which means that showstopper bugs are supposed to be fixed on your dime.

Sorry to disappoint you, but the licenses under which software products are sold generally contain a clause like "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE". So if their lawyers didn't fail miserably, they aren't obligated to fix anything! Furthermore commercial software developers have a complex release cycle. They usually invest a lot of manpower into QA (quality assurance) before they release a product. But once the product has passed QA and is released to market, it won't be developed actively anymore. In particular they won't waste resources (money) for adding new features into a "legacy" product. Instead they move on and put their efforts into the next major release. Maybe for you the lack of Weight-P support is a showstopper, but for them Weight-P support simply was never on the feature list for the 1.9.x release. It has been announced for version 2.0 and there it is. Mission completed...

Anyway, if you aren't willing to buy CoreAVC 2.0 for proper Weight-P support, there are various alternatives. Both, FFmpeg-MT and DivX H.264 Decoder, are available for free ;)

Disabled
7th February 2010, 23:46
the licenses under which software products are sold generally
I remember CoreAVC 1.x not being sold under ANY specific license, because they thought licenses are useless anyway.
That being said, they sold a "High Profile decoder", but didn't sell a decoder that support the full high profile. Everybody has their way to trick the customers... Just go with Divx, ffdshow or wait for DiAVC (or use the free beta), unless you need cuda support, then youre out of luck.

LoRd_MuldeR
8th February 2010, 00:12
...unless you need cuda support, then youre out of luck.

As soon as "CUDA decoding" is enabled, CoreAVC 1.9.5 will handle Weight-P perfectly fine. That's because the VP2 chip on your graphics board will take over the decoding in that case.

Keiyakusha
8th February 2010, 01:17
There is no trial version yet?

Fadeout
8th February 2010, 01:57
It only means there's space for competition.

Support for Weight-P is basically the only noticeable feature of CoreAVC 2.0

Disabled
8th February 2010, 02:01
Support for Weight-P is basically the only noticeable feature of CoreAVC 2.0
And of course closing the gap to the competition speed wise in software mode.

Jiffy
8th February 2010, 15:28
I remember CoreAVC 1.x not being sold under ANY specific license, because they thought licenses are useless anyway.
That being said, they sold a "High Profile decoder", but didn't sell a decoder that support the full high profile. Everybody has their way to trick the customers... Just go with Divx, ffdshow or wait for DiAVC (or use the free beta), unless you need cuda support, then youre out of luck.

Thanks, that's good information.

Jiffy
8th February 2010, 15:29
Sorry to disappoint you, but the licenses under which software products are sold generally contain a clause...

Did this one? It sounds like it didn't.

Furthermore commercial software developers have a complex release cycle. They usually invest a lot of manpower into QA (quality assurance) before they release a product. But once the product has passed QA and is released to market, it won't be developed actively anymore. In particular they won't waste resources (money) for adding new features into a "legacy" product. Instead they move on and put their efforts into the next major release.

Yes I'm a developer myself. Most comanpies have a disclaimer but they still make every effort to ensure that the software does work to a reasonable level, and provide bug fixes when it doesn't.

Anyway they don't need to put resources into the old branch. 1.9.6 could be a build of 2.0 with the new features disabled.

Maybe for you the lack of Weight-P support is a showstopper, but for them Weight-P support simply was never on the feature list for the 1.9.x release. It has been announced for version 2.0 and there it is. Mission completed...

It's not an optional feature. There wasn't any way to know in advance that this hadn't been implemented and a lot of people wouldn't have bought it if they had known.

Anyway, if you aren't willing to buy CoreAVC 2.0 for proper Weight-P support, there are various alternatives. Both, FFmpeg-MT and DivX H.264 Decoder, are available for free ;)

Hopefully they'll decide they've made a mistake and put things right.

ChronoCross
8th February 2010, 20:22
Did this one? It sounds like it didn't.


They do.



Yes I'm a developer myself. Most comanpies have a disclaimer but they still make every effort to ensure that the software does work to a reasonable level, and provide bug fixes when it doesn't.

Anyway they don't need to put resources into the old branch. 1.9.6 could be a build of 2.0 with the new features disabled.


Wasted time and effort. It's not as simple as "turning off features" as corecodec improved the primary design of the entire codec.


It's not an optional feature. There wasn't any way to know in advance that this hadn't been implemented and a lot of people wouldn't have bought it if they had known.


I doubt you knew that weight-p existed when you bought it. Sorry but it's highly unlikely that this feature that only x264 supports was even a glimmer in your mind when you purchased coreavc.


Hopefully they'll decide they've made a mistake and put things right.

They haven't made a mistake so there isn't really anything to correct. Just spend the $10 to upgrade or use a free codec and stop polluting this thread with useless drivel.

Disabled
8th February 2010, 21:37
I doubt you knew that weight-p existed when you bought it.
All I know is I bought a high profile decoder... do I have to know what features are in high profile?

But youre right, they won't implement it, lesson learned.

Jiffy
8th February 2010, 22:03
I doubt you knew that weight-p existed when you bought it.
Yes that was the point: "never on the feature list" huh? who knew they needed it?

Just spend the $10 to upgrade
And then again, and again. Forget it, I'd much rather work on making a faster open source codec.


stop polluting this thread with useless drivel.
whatever.

ChronoCross
9th February 2010, 06:04
All I know is I bought a high profile decoder... do I have to know what features are in high profile?

But youre right, they won't implement it, lesson learned.

Weighted prediction is not a requirement for high profile support.

Yes that was the point: "never on the feature list" huh? who knew they needed it?


Correct. Nowhere did you read "supports every feature of the h264 spec".


And then again, and again. Forget it, I'd much rather work on making a faster open source codec.
whatever.

Most people who say this are all talk. I have a feeling your exactly the same.

sneaker_ger
9th February 2010, 06:14
Weighted prediction is not a requirement for high profile support.

Not? Can you back that up?

ChronoCross
9th February 2010, 06:32
Not? Can you back that up?

Yes. It's usable in main profile or higher. Additionally it is not a requirement to claim support for either main or high profiles as x264 has supported both profiles for encoding for years while weight-p has only been around since last summer. Basically disabling weight-p does not take away the fact that a stream is either main or high profile.

sneaker_ger
9th February 2010, 06:37
Yes. It's usable in main profile or higher. Additionally it is not a requirement to claim support for either main or high profiles as x264 has supported both profiles for encoding for years while weight-p has only been around since last summer. Basically disabling weight-p does not take away the fact that a stream is either main or high profile.

Ah, ok, I agree. You're looking from an encoder side of view, while I was thinking about the decoder side of view (i.e. decoders claiming to feature h.264 high profile should be able to decode all high profile streams IMHO. Although this way of saying it could still lead to different interpretations.)

Stephen R. Savage
9th February 2010, 07:26
ChronoCross' statement is revisionist ***. By that logic, I could sell a decoder as having "FULL HIGH PROFILE SUPPORT" when it can only play streams of 320x240 with 1 reference frame, 0 bframes, and a VBV constraint of 400 kbps. After all, such a stream would still be High Profile!

ChronoCross
9th February 2010, 08:09
ChronoCross' statement is revisionist ****. By that logic, I could sell a decoder as having "FULL HIGH PROFILE SUPPORT" when it can only play streams of 320x240 with 1 reference frame, 0 bframes, and a VBV constraint of 400 kbps. After all, such a stream would still be High Profile!

Show me where their site says "Full High Profile Support" and your example might be valid. However you won't be able to cause it never said this.

Additionally the following link (which is linked to from the main page ): http://forum.corecodec.com/viewtopic.php?f=3&t=69 Indicates very clearly that it doesn't support all features and is dated "25 Feb 2007".

plonk420
9th February 2010, 08:31
Yes that was the point: "never on the feature list" huh? who knew they needed it?

seconded, but i still unhappily upgraded :/

at least i have a 1.x AND a 2.x license :P

Show me where their site says "Full High Profile Support" and your example might be valid. However you won't be able to cause it never said this.

lame example. that's like saying "you should have expected this since CoreAVC didn't list every h.264 feature it supports somewhere..."

edit: http://web.archive.org/web/20071210023944/http://www.corecodec.com/products/coreavc.html

from feb to december+, it says it supports "H.264 Baseline, Main, High profile support". i disagree that it's our fault for not reading that that wasn't "FULL High Profile Support"... but then again from a nitpicker's viewpoint, it DOESN'T say "full". but what decoder DOES? WinDVD says nothing. PowerDVD says it supports "MPEG-4 AVC (H.264)" and plays it just fine...

i'm with DS in that the h.264 spec has included x264's weightp since before CoreAVC.

all i can say is "fool me twice..."

Disabled
9th February 2010, 13:46
Imo one had to assume they support the full profile, because even under limitations they didn't write something about missing features: (*edit* They did, but only two who got fixed)
Limitations :
- Only output to YV12 and I420
- No dynamic output mediatype change
- No flushing for buffered frame at end of file
- Linked with some unnecessary code from TCPMP
- no cqm, lossless or interlacing support
link (http://web.archive.org/web/20060404210113/coreavc.corecodec.org/changelog.html)
But then again one could have guessed they don't really care because they also listed the standard edition as High profile support, but that one clearly lacked interlacing...

LoRd_MuldeR
9th February 2010, 15:37
Imo one had to assume they support the full profile, because even under limitations they didn't write something about missing features: (*edit* They did, but only two who got fixed)

link (http://web.archive.org/web/20060404210113/coreavc.corecodec.org/changelog.html)
But then again one could have guessed they don't really care because they also listed the standard edition as High profile support, but that one clearly lacked interlacing...

Back at the time when CoreAVC 1.9 was released, support for Weight-P was irrelevant because nobody needed it. That's a fact we should not forget in this discussion. It was even left out intentionally. Why make your code messier/slower for something that nobody needs? In fact 99,9% of all users didn't known what "Weighted P-Prediction" is, until it popped up on the x264 changelog a few months ago. Other H.264 decoder, such a Adobe's Flash or Apple TV didn't support it either (the latter still doesn't). Therefore it's obvious why they didn't mention the lack of support for something that nobody needed (back at that time) and that wasn't supported by the competitors either. Now, several years later, the situation has changed, indeed. But adding Weight-P support to CoreAVC 1.9 now would probably mean rewriting a lot of code - which not only requires a lot of time (money) for coding, but also for re-testing everything after those fundamental changes. Releasing a "crippled" CoreAVC 2.0 as v1.9.6 (as Jiffy suggested) probably isn't an option either, because one of the major improvements in CoreAVC 2.0 is the increased decoding performance, which they probably can't "undo" easily and won't give away for free...

Disabled
9th February 2010, 15:51
Back in the days I didn't care about weightp either, but today that its used I care about not knowing what I bought. And that makes me not buy the upgrade, because I will not know what I get for my money and if they feel like it they stop supporting new x264 features next month and I have to buy another decoder.

LoRd_MuldeR
9th February 2010, 16:03
Back in the days I didn't care about weightp either, but today that its used I care about not knowing what I bought. And that makes me not buy the upgrade, because I will not know what I get for my money and if they feel like it they stop supporting new x264 features next month and I have to buy another decoder.

Well, that applies to any product. And especially in the IT world things are outdated very soon. That's a matter of fact. We may not like it, but we have to live with it :rolleyes:

For example: If I buy a "high-end" graphic's card for 300$ today that runs all games with maximum details, I can be sure that this won't last very long. In 1 or 2 maybe 3 years it will be hopelessly outdated!

The same way you can't expect that a software, which is "state-of-the-art" today, will remain so until forever. And we talk about a 15$ software here, not some "enterprise" solution...

avivahl
9th February 2010, 16:13
If you ask me, the proper thing to do is to give 1.9.5's customers a free upgrade to 2.0.0. With every second person downloading pirated CoreAVC illegally, the company might wanna rethink before stabbing their customers in the back. And yes, not supporting weight-p, which has now become a basic feature in the world's most widely used H.264 encoder, is what I consider "stabbing the customers". I mean, it basically renders CoreAVC useless for customers who relayed on it as a software decoder. And between us, most people buy CoreAVC for its fast software decoding (not for CUDA). And I say all this as a person who uses Windows 7's internal DXVA H.264 decoder.

Disabled
9th February 2010, 16:27
Lord Mulder: Totally different thing. H264 hasn't moved since a long time - at least weightp is there since about a decade. I expect every DX11 graphics card to support every DX11 feature and every DX10 card to support every DX10 feature. And if one feature is not used today but is used tomorrow, I consider it false advertisement to advertise a DX11 card like that who does not support said feature. If the card is fast enough to run a game using that feature is a completely different story.
You know, ATI supports tesselation since its 2xxx series. Are they DX11 cards now? Or were they advertised as such?

Maccara
9th February 2010, 18:29
So when we got an order to manufacture a defibrillator according to specs (addressing some issues mentioned here (http://www.ncbi.nlm.nih.gov/pubmed/9259059)), you say it is ok for us to skip something in those specs? And when customer notices this (admittedtly, consequences are a little worse than just a failing codec) we can just say that no-one else uses that function either and we would like more money, despite we failed to provide what we got paid for the first time?

Great! I'll go tell my manager right away I found a great way to save money and ensure further revenue.

I'm glad at least some engineers have some ethics still...

And no, it's not about the money, it's about the principle. And for me personally, it's not even about the fact I'm paying for bugfixes (hell, I have software which I pay annually for just that reason), but about the ass-backwards way of handling the issue when it was found out, trying to blame it on "changing specs" (which is not true) and calling customers, who dared to complain, "ranters" and whatnot, instead of just being forthcoming about the issue in the first place.

CiNcH
9th February 2010, 18:41
Hey guys,

if I remember correctly, CoreAVC 2.0 removes the CUDA D3D dependency. Is the maximum reference frame count now 16 for 1080p?

Since you are also working on DXVA support.. guess it will have the Level 4.1 check?

ChronoCross
10th February 2010, 05:34
Did I just read a comparison between a codec and defibrillator?

The simple fact is you guys are complaining because you weren't paying attention to the fact that CoreAVC didn't claim to support the entire h264 spec.

You didn't properly evaluate the product before you purchased it and now you are upset. How many of us bought this because it allowed us to watch H264 without having to invest a grand or two into a new computer? The least you could do is be a bit great-full instead of bitching and moaning every time you get upset.

There are plenty of alternatives

1) ffdshow and ffmpeg
2) DivX
3) DiAVC (whenever it stops being a horrible piece of software)

Fadeout
10th February 2010, 10:35
3) DiAVC (whenever it stops being a horrible piece of software)
Right now it works best here. Problem is that the guy is missing.

The correct way to look at CoreAVC is that it's THANKS to the weight-P issue that it has now a reason to sell. Without it there would be absolutely no reason to buy the new version, so they were lucky that the issue came up.

I remember in June where on Twitter they said that the product was complete and they were working just on optimization (up to 20% better). Well, in November we got none of that performance both on new and old CPUs.

Maccara
10th February 2010, 11:59
Just a clarification. In general, I'm happy with CoreAVC and it gets the job done on my system, and I even bought the update as it also had other benefits for me.

Does not mean I can't criticize their marketing & their attitude to spec conformance (in the past, at least).

Did I just read a comparison between a codec and defibrillator?

Nope, just a comparison of following specs. And people defending that "it's ok not to follow specs". Just driving the point in. Of course, consequences of not following specs are an order of magnitude different between these examples, but it still does not make it right in either case.

The simple fact is you guys are complaining because you weren't paying attention to the fact that CoreAVC didn't claim to support the entire h264 spec.
Wrong. I WAS paying attention: I bought a H.264 High Profile decoder, as advertised. 1.x series never was that, and never will be. I suspect it never will be fully, and CoreCoded now has even aknowledged (somewhere in this thread) that they try to match what x264 produces featurewise and have listed what they do not support. This is ok as longs as they're forthcoming about it. This was not so in the past.

You didn't properly evaluate the product before you purchased it and now you are upset.
Sure I did. You don't expect us to write our own encoders to test every aspect of the decoder, do you? I just expect they follow the specs they claim to follow.

The least you could do is be a bit great-full instead of bitching and moaning every time you get upset.
I am as grateful as for any profit making company providing products which get the job done. It's the claims and handling discrepancies I'm criticizing.

This would be a bit different if we were talking about a free product - I'd be grateful for anything useful I get.

When I have to pay, I expect a bit more disclosure and some respect towards customers (not the other way around).

All-in-all. This IS a good product, and I'm happy it exists at all. I'm just not too happy about how they've handled business. At least now it seems they're more forthcoming about shortcomings.

Keiyakusha
11th February 2010, 16:31
Some peoples telling me that for lossless streams encoded with x264 --crf 0 --preset ultrafast, ffmpeg-mt is up to 35% faster than CoreAVC 2.0. Does anyone have any benchmarks for lossless?

ChronoCross
11th February 2010, 21:22
Some peoples telling me that for lossless streams encoded with x264 --crf 0 --preset ultrafast, ffmpeg-mt is up to 35% faster than CoreAVC 2.0. Does anyone have any benchmarks for lossless?

This is entirely possible however I haven't seen any benchmarks as almost no one uses lossless. I would imagine primarily that CoreAVC is more optimized for situations where higher compression is used whereas --ultrafast disables a good majority of the H264 specs in exchange for encoding speed. If your interested in running tests I would compare ---ultrafast vs. --placebo to test the two sides of the spectrum to see how each decoder fares.

twazerty
11th February 2010, 23:45
I am the developer of AVCHDCoder and found a very big problem when I use CoreAVC. (found the problem 3-4 weeks ago) This is the problem:

When the encoding pass 1 starts in AVCHDCoder the encoder and CoreAVC will be started. After it is started and I open a window or do something with setVisible(true) (Java GUI) AVCHDCoder will hang (Not responing). On this point AVCHDCoder's GUI is not responding. But when Pass 1 is complete CoreAVC is ready and my GUI is working again. So while CoreAVC is running by a process launched with AVCHDCoder the GUI will hang. Same problem with second pass. But it is even stranger, not only AVCHDCoder will hang but most times my IDE (Netbeans 6.8) is not responding too !!! the same problem as my app. Gets back to normal when CoreAVC is done.

This is what AVCHDCoder does when it starts the encoding process:

create avisynth script
create bat file with x264 commandline instructions
run batfile with ProcessBuilder (Java lib)


23:12:03 Creating AVS file: DirectShowsource("input.m2ts",fps=25.000,audio=false).ConvertToYV12().addborders(0,0,0,0)
23:12:03 Encoding Pass 1: "C:\Program Files (x86)\AVCHDCoder\Tools\X264\32bit\x264.exe"
--pass 1 --vbv-bufsize 18000 --vbv-maxrate 18000 --bitrate 17808 --level 4.1
--stats "K:\AVCHDCoder Temp\Test - item 1\Test.stats" --keyint 24 --min-keyint 2
--ipratio 1.1 --pbratio 1.1 --fps 25.000 --sar 1:1 --weightp 0 --nal-hrd --interlaced --aud
--output NUL "K:\AVCHDCoder Temp\Test - item 1\Test.avs"
23:12:39 Encoding Pass 2: "C:\Program Files (x86)\AVCHDCoder\Tools\X264\32bit\x264.exe"
--pass 2 --vbv-bufsize 18000 --vbv-maxrate 18000 --bitrate 17808 --level 4.1
--stats "K:\AVCHDCoder Temp\Test - item 1\Test.stats" --keyint 24 --min-keyint 2 --me umh
--direct auto --psy-rd 1.0:0.25 --ipratio 1.1 --pbratio 1.1 --fps 25.000
--sar 1:1 --weightp 0 --nal-hrd --aud --interlaced
--output "K:\AVCHDCoder Temp\Test - item 1\Test.264" "K:\AVCHDCoder Temp\Test - item 1\Test.avs"


This is my code to run the bat file and parse the output (Java):


FileWriter fw = new FileWriter(bat);
BufferedWriter bw = new BufferedWriter(fw);

bw.write(commandLine);
bw.close();

ProcessBuilder processBuilder = new ProcessBuilder(bat.getAbsolutePath());
processBuilder.redirectErrorStream(true);

process = processBuilder.start();

InputStream is = process.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
br = new BufferedReader(isr);

while ((line = br.readLine()) != null) {
//Write output to model.
}
br.close();


My app is multiThreaded (offcource) my GUI runs in it's own Thread. It works perfectly when I use ffdshow. In some strange way CoreAVC is messing with Java. I tracked down the problem as far as I could do. Every time I came back to standard java library. To be more specific the setVisible method of a Swing element like a JDialog. (For example opening the Settings window)

Also tried different versions of x264 and ffdshow and I have the same problem on my other computer. Both Windows 7 64 bit. Are you known with this problem???

Blue_MiSfit
12th February 2010, 01:43
Please parse that x264 command line so that it doesn't extend several pages to the right. Quite illegible :)

Thanks!

~MiSfit

roozhou
12th February 2010, 02:48
I am the developer of AVCHDCoder and found a very big problem when I use CoreAVC. (found the problem 3-4 weeks ago) This is the problem:

When the encoding pass 1 starts in AVCHDCoder the encoder and CoreAVC will be started. After it is started and I open a window or do something with setVisible(true) (Java GUI) AVCHDCoder will hang (Not responing).

Did you disable CoreAVC's trayicon?

twazerty
12th February 2010, 14:41
Did you disable CoreAVC's trayicon?

I think I didn't disable the icon. (always enable icons for testing) Could that really be the problem?? sounds strange. Anyway I will going to test it

lych_necross
13th February 2010, 07:54
Betaboy hasn't been on in a while... I wonder if all of the fighting in this thread has scared him off. :confused:

lnatan25
19th February 2010, 22:39
Betaboy hasn't been on in a while... I wonder if all of the fighting in this thread has scared him off. :confused:
If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:

ChronoCross
19th February 2010, 23:34
If we've learned anything about BetaBoy, it's that he has learned to ignore any piece of criticism that doesn't paint his software in the best possible way, and call it off topic, trolling, etc. :devil:

More likely is he's tired of answering the same questions/criticism 5000 times in the same thread.

He of course loves if you find a technical problem.....however none have come up in this thread in quite some time.