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? :thanks:

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

[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() (http://forum.doom9.org/showthread.php?t=162930)

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

[TheRyuu]

ffmpegsource (http://code.google.com/p/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]

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]

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. (http://www.cccp-project.net/)

[MatLz]

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

[2Bdecided]

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.php?p=1525723#post1525723

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

[2Bdecided]

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.php?p=1525723#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]

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.php?p=1525723#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]

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_]

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]

lossless

YV12 to YUY2


Does not compute

[poisondeathray]

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]

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]

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.

[poisondeathray]

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


But you cannot go back to YV12 without loss (or deviation from the original), there are rounding errors when you use standard methods like avisynth or ffmpeg swscle. You can used difference masks to demonstrate the loss incurred

It depends also on the scaling algorithm used for the chroma. I think avisynth uses bicubic resizer by default, not sure about swscale; chroma samples are not duplicated.

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

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. :-)HuffYUV is lossless (but the version I used doesn't support YV12). I've never used utcodec.

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.It's not that - it's that when you embark down the "lossless isn't really lossless so BEWARE" route, you lead people into the snake oil and science-free world where no one is certain of anything, and people are trying to sell you $499 gold plated HDMI cables ;)

I think it's extremely helpful to define the situations where lossless is lossless (as well as point out any pitfalls).

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....especially in the AVIsynth forum.

Cheers,
David.

[2Bdecided]

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.

[Gavino]

It depends also on the scaling algorithm used for the chroma. I think avisynth uses bicubic resizer by default, not sure about swscale; chroma samples are not duplicated.
The basic default for YV12<->YUY2 conversion is equivalent to bilinear resizing - see http://avisynth.org/mediawiki/Sampling, sections 2.2.2, 2.2.3, 2.3.2 and 2.3.3.

In Avisynth 2.60, you can specify the method via the chromaresample argument to the ConvertXXX (http://avisynth.org/mediawiki/Convert) functions. This defaults to bicubic, but the old (bilinear-equivalent) method is still used for YV12<->YUY2 unless at least one of the new parameters (ChromaInPlacement, ChromaOutPlacement, chromaresample) is specified.

[TheFluff]

But you cannot go back to YV12 without loss (or deviation from the original)

Of course you can, you only need to know the original chroma siting and use that information on both up- and downscaling to properly duplicate or delete the appropriate samples. You don't actually need to do a full bilinear or bicubic interpolation in order to resample the chroma plane vertically (in fact, I believe it is technically incorrect to do so since I think it will result in chroma samples that don't really "belong" to a given 2x2 square of luma influencing the YUY2 chroma of said square).

Both Avisynth and swscale most likely do this wrong (since nobody really gives a shit about chroma siting), but it's definitely theoretically possible to convert YV12 to YUY2 and back again without losing or misplacing any chroma precision.

[Guest]

Getting a bit OT here, it seems to me. Should I break out this discussion?

[Yellow_]

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.


Not wishing to prolong this discussion but I would like to respond to this, I didn't say that the CODEC was not always lossless but the PROCESS.

I made it quite clear where I see this. Using ffmpeg on the CLI.

Could I request a little guidance from you, considering your knowledge of ffmpeg, on the correct CLI command for taking a full luma h264AVC HD file and losslessly transcoding to huffyUV? Due to my inability to use certain encoding applications correctly?

Your help would be very much appreciated.

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

You need to demux the video first using mp4box, for example
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_]

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:

You need to demux the video first using mp4box, for example
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 :-)