Correct opening HD AVC with Avisynth

[alexVS]

Trying to cut several fragments from AVC-h264-720p video. DSS2() opening filter works fine, but when I use trim function, about 10 first frames go with artifacts.

v1=DSS2("video.mkv",FPS=25)
v2=v1.trim(12345,23456)++v1(34567,45678)
return v2

I understand that frames 12345 and 34567 are not keyframes, but p or b frames, so directshow codec produces 12345-12355 frames (or so) incorrectly (with artifacts) and next frames go all right. The same is with the second fragment starting from frame 34567.

Is there a solution to this?

[small]When clip is small, I can write it uncompressed with lagarith or huffyuv from start through, then work with any frame, but it's not convenient with large files and take more time[/small]

[vampiredom]

DirectShowSource and DSS2 are pretty unreliable for a lot of things. I would recommend using neuron2's indexing tools for this kind of stuff. I wrote a utility and function to make this process automatic, so perhaps that would be easiest and best for you. Check out MpegAutoIndexSource()

Note: opening .mkv files with neuron2's tools requires an Nvidia graphics and license for DGDecodeNV (http://neuron2.net)

[TheRyuu]

ffmpegsource.

[alexVS]

2Vampiredom
Unfortunately, my graphics card is ATI (Radeon HD4670). And indexing with standard DGAVCIndex gives bad results. Artifacts are everywhere.

2TheRyuu
I have K-lite codec pack installed. I think ffmpeg is included in this pack, so it seems I already has libavcodec and ffmpeg codec installed. But by default decoding goes with CoreAVC. DSS2() can be used with any of this. Shoud I try to change decoder or do I have to use some another function for opening files instead DSS2() ?

[Yellow_]

You could download from the link provided, unzip into your Avisynth plugins folder and use FFmpegSource2(whatever) instead of DSS2(whatever).

Watch out for so called 'lossless' codecs like Lagarith, HuffyUV and utcodec. They maybe lossless compression but they do not appear to support full range luma in YCC and don't keep Color Matrix info either.

This may be of no issue to you with this source, but for example HD h264AVC from my Canon DSLR is full luma and BT601 color matrix so transcoding it to HuffyUV or utcodec is not lossless. :-)

I'd end up with more contrast and shift to orange hues playing back or editing in certain NLE's doing a 'lossless' transcode. :-)

[Keiyakusha]

Originally Posted by alexVS

I have K-lite codec pack installed. I think ffmpeg is included in this pack, so it seems I already has libavcodec and ffmpeg codec installed. But by default decoding goes with CoreAVC. DSS2() can be used with any of this. Shoud I try to change decoder or do I have to use some another function for opening files instead DSS2() ?

Doesn't matter what decoder you have. DSS or DSS2 suck. Solution proposed by TheRyuu is pretty much bes...t I mean recommended way to load files. Just read about it and try it before making assumptions.

[vampiredom]

And indexing with standard DGAVCIndex gives bad results. Artifacts are everywhere.

That's a bummer. Yes, TheRyuu is correct and FFMS does usually do a good job with h264 .mkv files and opening with FFVideoSource() is not the same as using ffmpeg via DSS, despite their both using libavcodec. Usually most any method is better than DSS. However, I can say at I have had fairly good results with the CoreAVC or DiAVC DirectShow decoders, though they are not free and occasional frame-inaccuracies have happened.

I have K-lite codec pack installed.

Perhaps this is my personal opinion and prejudicial but I would stay far away from such "codec packs" and they often seem to do more harm than good. I think it is wiser to only install the codecs as you need them and, when possible, to get the latest versions directly from the developer. K-Lite, et al are very suspect in my mind and I have heard some horror stories of these screwing up people's machines.

[TheRyuu]

Originally Posted by alexVS

I have K-lite codec pack installed. I think ffmpeg is included in this pack, so it seems I already has libavcodec and ffmpeg codec installed. But by default decoding goes with CoreAVC. DSS2() can be used with any of this. Shoud I try to change decoder or do I have to use some another function for opening files instead DSS2() ?

If you actually bothered to look into it ffmpegsource has nothing to do with direct show or any of the stuff you already have installed. Everything (except Haali splitter itself) it uses is compiled in statically to the plugin itself.

DirectShowSource/dss2 are pretty evil ways of sourcing something in avisynth and should only be used as a last resort when all else fails. ffmpegsource should work (and be the preferred method) for mkv's.

On a side note K-Lite is equally as evil. There are much better alternatives.

[MatLz]

I really don't the point of using a codec pack.
All are useless and maybe broken.

[2Bdecided]

Originally Posted by Yellow_

This may be of no issue to you with this source, but for example HD h264AVC from my Canon DSLR is full luma and BT601 color matrix so transcoding it to HuffyUV or utcodec is not lossless. :-)

One of us is confused, and I'm not sure it's me The lossless codec doesn't care about the colour matrix or the range - it's lossless.

If that's not what you're seeing, you must have been forcing a colour conversion (RGB<>YUV/YV12) at the input or output of the codec - and such colour conversions are never lossless, and never needed for lagarith. (For HuffYUV you can do a YUV<>YV12 lossless conversion, but it's easy to do it with loss if you're not careful.)

Most AVI codecs (including Lagarith) don't keep much metadata - aspect ratio, colour matrix, interlacing indication etc are all lost. You have to remember them yourself The same info is lost through AVIsynth, so I think it's misleading to express concern about it specifically wrt lossless codecs in the AVIsynth forum - even if the output codec does support these things, you'll have to enter them manually when processing through AVIsynth.

Cheers,
David.

[Yellow_]

You're confused, ;-) with HD the general default playback in a media player / NLE, if the matrix is not provided is BT709 on pixel resolution. Reds/Pinks go to orange as a result with BT601 sources being treated as BT709. This is when converted to RGB as you know. :-)

My comments relate to the 'lossless' file as an intermediate between source and delivery. Metadata is lost, so it's not a lossless process.

I'm not seeing it because I use an NLE and media player calibrated set up where I can set the interpretation of matrix and luma. :-)

My comment was with regard to the assumption that people take 'lossless' as 'harmless' conversion, I was suggesting where that assumption could be incorrect and lead to unnecessary degrading of a perfectly decent source. :-)

Can you suggest a lossless codec that supports full range luma when transcoding from h264 4:2:0? utcodec, huffyuv and lagarith don't appear to with ffmpeg, from tests I've done, in the case of huffy & utcodec they go to YUY2 and squeeze luma.

I don't think it's misleading to express concern over so called lossless codecs.

Here's a simple example of a codec mishandling a full luma h264 AVC 4:2:0 source as per utcodec, lagarith, huffyUV and the resulting in the conversion to RGB, again with regard to NLE / media player use.

http://forum.doom9.org/showthread.ph...23#post1525723

Now I'm sure there is stuff you can correct me on in that thread so look forward to your comments. :-)

[2Bdecided]

Originally Posted by Yellow_

Here's a simple example of a codec mishandling a full luma h264 AVC 4:2:0 source as per utcodec, lagarith, huffyUV and the resulting in the conversion to RGB, again with regard to NLE / media player use.

http://forum.doom9.org/showthread.ph...23#post1525723

Now I'm sure there is stuff you can correct me on in that thread so look forward to your comments. :-)

I think the key point is that "it's a bug in FFMS2". Working lossless video codecs preserve the video losslessly!

I don't think it's misleading to express concern over so called lossless codecs.

It's downright misleading to imply lossless codecs aren't lossless because there's a buggy release floating around.

My comments relate to the 'lossless' file as an intermediate between source and delivery. Metadata is lost, so it's not a lossless process.

Metadata is your own problem. If you don't get that colour matrix, aspect ratio, interlacing, time code, etc etc data will be lost through AVIsynth, you probably shouldn't be using it.

Can you suggest a lossless codec that supports full range luma when transcoding from h264 4:2:0?

Dropping an .avs file into VirtualDub and saving with Lagarith re-compression is fine.

My comment was with regard to the assumption that people take 'lossless' as 'harmless' conversion, I was suggesting where that assumption could be incorrect and lead to unnecessary degrading of a perfectly decent source. :-)

"unnecessary"? Do people increase the bitrate by 20x+ just for fun? I'm sure most sane people have a reason for using lossless - though it's unnecessary to use buggy software when perfectly good software exists

Cheers,
David.

[Yellow_]

I was referring to the histograms in that thread due to incorrect handling of luma in conversion to RGB not the fact that particular release of FFMS2 was buggy, give me some credit to blame that on a lossless codec would be idiotic.

What this comes down to is implementation of the codec for example, if you convert h264AVC to huffyuv lossless codec with ffmpeg stable or from git on the CLI as many do as it's the quickest way, it squeezes luma, that's not lossless. Convert h264AVC to utcodec with ffmpeg on the CLI and it squeezes luma that's not lossless. :-)

You can get a binary here: http://ffmpeg.zeranoe.com/builds/ many converters and batch scripts out there use ffmpeg CLI so it's not some odd behavior from one particular converter application. Try it on huffyuv or utcodecs.

However you show that using a system wide implementation of the lagrith codec, (not available in ffmpeg) accessed via Virtualdub there is no squeezing. Jolly good, now perhaps try that with a lossless codec like utcodec or huffyuv. What do you see? I see luma squeeze. :-)

Going back to my initial comment to the OP, I merely suggested to the OP that as he'd mentioned lossless codecs and the thread title is correct handling of AVC then not to assume using lossless codec was without error and in fact COULD BE NOT lossless. :-)

Meta data is not my problem as I explained, I'm aware of it.

I's not necessarily the case that the OP was aware of the loss of matrix info and for Avisynth dwellers who are aware, are they lining up with smug comments about I need to deal with it, no because the comment was for the OP. As I'd mentioned in the initial comment the loss of matrix and luma squeeze with certain lossless codecs I obviously am aware of it don't you think?

I was under the impression that a forum was to help people who need help, those in the know don't need to reply with smug answers.

And again your bitrate comment, is a smug misrepresentation of what I said.

That's the last I have to say, feel free to churn it out some more if you feel the need.

[poisondeathray]

Originally Posted by Yellow_

My comment was with regard to the assumption that people take 'lossless' as 'harmless' conversion, I was suggesting where that assumption could be incorrect and lead to unnecessary degrading of a perfectly decent source. :-)

Can you suggest a lossless codec that supports full range luma when transcoding from h264 4:2:0? utcodec, huffyuv and lagarith don't appear to with ffmpeg, from tests I've done, in the case of huffy & utcodec they go to YUY2 and squeeze luma.

I don't think it's misleading to express concern over so called lossless codecs.

Here's a simple example of a codec mishandling a full luma h264 AVC 4:2:0 source as per utcodec, lagarith, huffyUV and the resulting in the conversion to RGB, again with regard to NLE / media player use.

http://forum.doom9.org/showthread.ph...23#post1525723

Just to clarify, the "lossless" codecs are lossless in the same colorspace

It's not the codec author's fault if the other application treats it as RGB, incurring a Rec601/709 conversion

If you don't import into a regular NLE, and just use avisynth, you can keep the same colorspace.

Those lossless codecs (UT, huffyuv, lagarith etc... ) do accept full luma range - you're incurring a RGB conversion somewhere that is causing loss of superbrights/darks

[TheRyuu]

Originally Posted by 2Bdecided

I think the key point is that "it's a bug in FFMS2". Working lossless video codecs preserve the video losslessly!

'Was' a bug, it's been fixed for a while now (few posts down from the one linked I believe).

[Yellow_]

Originally Posted by poisondeathray

Just to clarify, the "lossless" codecs are lossless in the same colorspace

It's not the codec author's fault if the other application treats it as RGB, incurring a Rec601/709 conversion

If you don't import into a regular NLE, and just use avisynth, you can keep the same colorspace.

Those lossless codecs (UT, huffyuv, lagarith etc... ) do accept full luma range - you're incurring a RGB conversion somewhere that is causing loss of superbrights/darks

I suggested in my first comment to the OP that its not always the case using so called lossless codecs were always lossless process.

I backed that up by providing where I see the squeeze, ffmpeg on the CLI a very frequent route for batch script and apps.

There is no conversion to RGB involved in that route there is however swscale intervention as the default options from h264 to huffyuv is from YV12 to YUY2.

My comments that followed about lossless codecs not holding full luma were clearly wrong but as a result of short temper with glib remarks, I accept that was in error.

But the fact still remains that transcoding to lossless via ffmpeg can easily result in error with no conversion to RGB being involved.

Going back to my initial point just because its called lossless not to assume it is, re glib remark its LOSSLESS therfore its LOSSLESS, lossless compression yes but not necessarily lossless process with default behaviour.

I don't think that initial point I made needed the gilb remarks that followed.

[Nevilne]

Originally Posted by Yellow_

lossless

Originally Posted by Yellow_

YV12 to YUY2

Does not compute

[poisondeathray]

Originally Posted by Yellow_

I backed that up by providing where I see the squeeze, ffmpeg on the CLI a very frequent route for batch script and apps.

There is no conversion to RGB involved in that route there is however swscale intervention as the default options from h264 to huffyuv is from YV12 to YUY2.

How are you determining this? I think this is not true either

1) YV12 => YUY2 isn't lossless

2) Y' is unscaled with swscale. Fullrange Y' 0-255 will be 0-255 in the export.

Perhaps something is wrong with your binary?

Or how are you checking the levels in the export ? I just tested with ffmpeg, huffyuv it works fine (scaled to 4:2:2, but Y' is unchanged)

[Alex-Kid]

Originally Posted by alexVS

Unfortunately, my graphics card is ATI (Radeon HD4670). And indexing with standard DGAVCIndex gives bad results. Artifacts are everywhere.

I have the same ATI card and had the same problem as you. You might try neuron's DGAVCDecDI (which uses DiAVC codec, and a license for each app). I have these ones and no problems on my HD captures since then.

[TheFluff]

Originally Posted by poisondeathray

1) YV12 => YUY2 isn't lossless

What? How could it not be lossless? All you need to do is duplicate the chroma samples. No information is lost.

That aside, Yellow_'s claim that "lossless codecs sometimes aren't lossless" because of issues with unrelated software or the fact that he seems to be using certain encoding applications incorrectly is, of course, completely ridiculous.