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. :-)

[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.

[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

[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.

[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.

[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.

[MatLz]

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

[vampiredom]

All you need to do is duplicate the chroma samples. No information is lost.

I believe it interpolates rather than simply duplicating them. It is not lossless because YV12->YUY2->YV12 will be a slightly different result than the original.

[2Bdecided]

Originally Posted by vampiredom

I believe it interpolates rather than simply duplicating them. It is not lossless because YV12->YUY2->YV12 will be a slightly different result than the original.

The standard conversions aren't lossless, but if you want to use a lossless codec that doesn't support YV12 to store YV12, there are lossless ways of getting it in there and out again. I think you can split the colour planes to Y, use pointresize, and then stitch it back together in YUV in AVIsynth if you must.

Cheers,
David.

[poisondeathray]

Yellow_ - You're probably dealing with Canon DSLR (Quicktime) footage, which is a specific case. Y' levels are preserved in huffyuv transcoded by ffmpeg from AVC sources, just not in MOV container.

If you are using ffmpeg with quicktime AVC , MOV wrapped footage, you need to re-wrap the video to something else first (e.g. MP4 container), otherwise you will get levels clamp (just like quicktime decoder). I suspect that is what you are experiencing.

Also, if you don't want the slight loss from chroma sampling, you can use YV12 natively supported intermediates like ffvhuff, ffv1 , although sometimes it is better to upsample in other programs, even ffmpeg, because things like most NLE's do very poor upsampling from YV12 sources


EDIT: yes, it's something peculiar about QT AVC files, that ffmpeg/ffmbc don't like. Something has changed in ffmpeg behaviour as well - you used to be able to rewrap them to get around the levels clamp when encoding to intermediates, but I just tried it and it didn't work with a recent ffmpeg binary. Another workaround I used to use is ffvideosource in avisynth. Other non quicktime AVC files work fine with this procedure (levels preserved).

EDIT#2 : I think it has to do with the full range flag
QT AVC MOV's are detected as yuvj420p for the pix_fmt , but when using something like huffyuv, swscale will scale to yuv422p . Since it thinks source is full range and it's scaling to limited range, you get a clamp to Y' 16-235. You would need to scale using yuvj422p , but I don't think you can specify that for huffyuv. Non-flagged YV12 AVC files with full levels (or not) are detected as yuv420p , and are scaled to yuv422p with full levels intact . So if you can re-write the flag, maybe with roozhou's ffmpeg tool it might work

EDIT:3: yes it works. I couldn't get roozhou's tool working properly so I stripped the flag with eac3to, and ffmpeg detects video stream as yuv420p now, and conversion to huffyuv with ffmpeg retains levels

[Yellow_]

PD, thanks for the time confirming ffmpeg's handling. From the QTInput 'saga' thread mp4box is another method to strip the flag.

But I've been using 'lossless' h264 rather than huffyuv etc on the occasions I've needed 'lossless', also via avs2yuv or avs2pipemod rather than directly on the CLI when avisynth processing is required, that all works without problems, as is of coarse.

[vampiredom]

PD, thanks for the time confirming ffmpeg's handling. From the QTInput 'saga' thread mp4box is another method to strip the flag.

Have you tried using DGIndexNV or DGAVCIndexDI (or even the old DGAVCIndex)? From what I can recall, they handle the Canon DSLR (Quicktime) footage fine ... well, "fine", with some caveats:

1. You need to demux the video first using mp4box, for example
2. Sometimes the framerate gets lost (defaulting to 25fps) when demuxed. If you don't know the exact framerate of the source, it can be calculated by frames/seconds, which you can get using mp4box -info on the .mov file [the seconds are accurate to .001, so you can determine fps pretty accurate from this.])

[Yellow_]

Originally Posted by vampiredom

Have you tried using DGIndexNV or DGAVCIndexDI (or even the old DGAVCIndex)? From what I can recall, they handle the Canon DSLR (Quicktime) footage fine ... well, "fine", with some caveats:

1. You need to demux the video first using mp4box, for example
2. Sometimes the framerate gets lost (defaulting to 25fps) when demuxed. If you don't know the exact framerate of the source, it can be calculated by frames/seconds, which you can get using mp4box -info on the .mov file [the seconds are accurate to .0001, I believe, so you can determine fps pretty accurate from this.])

hehe, your workflow / tools use these :-). You've asked me this already, on a couple of threads, must try it out :-)