Not sure I'm posting this on the correct section of the forum, but it seems a good place to start, since I'm using Avidemux on Windows 7. Please move it if necessary.
So, I'm using avidemux to cut and reencode some DVB originated streams in TS files captured by my USB-enabled tuner, and I noticed that when I reencode (as opposed to copying) HD streams, which come encoded in h264, the colors are different than when I play the TS files directly.
After fiddling around with a bunch of other programs, I've come to the conclusion that somehow AviDemux incorrectly decodes those video streams as if they were rec601, while it should treat them as rec709.
The decoded video doesn't look wrong at first glance, but when you make the comparison, it becomes undeniable.
I don't seem to find any way to coherce Avidemux to force 709 decoding, so I'm guessing there isn't one readily available.
Any ideas?
First of all, please verify that the issue you experience persists with the latest available nightly build (https://avidemux.org/nightly/win64/) (currently from Aug 23) and specify what filter chain and what encoder you use and its configuration (please provide a project script).
https:// mega.nz /folder/Dh00QQoD#qTBi98Q-A5keYyDLVJnMEQ
Here's a 2 GOP sample of the original video stream, and a zip with one of the frames as decoded by several programs. Two of them generated by both my current and your suggested latest version of avidemux, saved with the "save as image" function just right after loading the original video file, in copy mode, without applying any filters or anything else, in order to reflect just what avidemux decodes the video as.
The others are generated by MPC-HC, SMPlayer, VLC, and, last, VirtualDub2, which offers the possibility of manually telling the decoder to interpret the YUV values as either BT 601 or 709 (defaults to 709 for this file).
As you'll be able to see, tools like MediaInfo will also identify the h264 stream as BT.709. Since VirtualDub allows selecting the decoded pixel format, when select 709, the colors match every other program I tested. But if I select 601, then it matches Avidemux.
Therefore I conclude that Avidemux is decoding the colors as rec 601 when it seems it should be decoding as rec709.
It may so be that it's Avidemux that's right and every other program I tried is wrong. I don't know enough to definitelly say that's not the case, but chances seem to be on the side of everyone else. Just my honest assessment.
I don't see the point of providing any filter chain or encoder settings since it seems pretty clear that the problem here is with the decoding, before any filtering or encoding happens.
Quote from: radorn on August 25, 2021, 03:44:34 PMI don't see the point of providing any filter chain or encoder settings since it seems pretty clear that the problem here is with the decoding
No, this is by no means clear. The filter chain and encoder is essential.
By the way, the link, when manually assembled, redirects me to the Mega homepage (/start). It would be still helpful to get a sample (100 MiB should be enough) of the original, unaltered, unedited MPEG-TS stream.
"Save as image" = encode the current picture using the MJPEG encoder in the bundled libavformat libavcodec, applying colorspace and color range conversions when necessary.
Sorry about the url. This one should work https:// mega.nz /folder/Dh00QQoD#qTBi98Q-A5keYyDLVJnMEQ
The file found there is a copy-mode excrept cut with Avidemux. It's just two GOPs. I can't afford to provide 100MB because I currently am on a very limited data plan (hence why I'm going through the trouble of recording stuff off the air instead of just downloading it or watching online). The results with that MKV and the original TS are the same in all the tested programs.
When I load that video on avidemux and the other programs, the view in the avidemux window already has different colors than all the others. The file generated by the "save as image" function matches the colors in the main avidemux window.
All this is done with the file freshly loaded into Avidemux. Copy mode. No encoder selected. No Filters selected. Nothing. I really don't understand what exactly you expect me to provide in terms of encoder and filter settings.
I'll give you a project script file, if you insist. I'll put it in that same folder along with the other files.
I see, we don't have infrastructure to convey colorspace information from the decoder, just the color range. When saving the current picture as JPEG, we have to leave the colorspace field in AVFrame at its default value (AVCOL_SPC_UNSPECIFIED = 2). We also don't have any means to tell some encoders like x264 what color properties it should use.
What if the decoder itself did the conversion from 709 to 601.
Ideally you would be able to work with all those colorspaces and even let the user do the conversion through filters if necessary, but, if avidemux is fixed on working with bt601, can't you have the decoder do the conversion before delivering the frames to avidemux? That way at least the colors would be correct.
Quote from: radorn on August 25, 2021, 04:29:35 PMI can't afford to provide 100MB because I currently am on a very limited data plan
Would it be possible for you to provide just ~20 MiB of the original stream? Two GOPs are too short for my purposes and it must be MPEG-TS or MP4, but not MKV.
Your sample has revealed an unrelated, very serious issue which needs to be understood and fixed on the spot. Many thanks in advance.
Quote from: radorn on August 25, 2021, 05:50:10 PMWhat if the decoder itself did the conversion from 709 to 601.
At the present time, Avidemux knows nothing about bt709 vs 601, in doesn't do 601, it simply doesn't care (it cares about the range and pixel format, that's it). There is nothing wrong with the decoder, in the future Avidemux might become aware of colorspace details.
How do I do that, just chop a chunk off with a hex editor?
What's the smallest size that would be usable to you?
If if helps, this is the full MediaInfo report on that .TS stream
General
ID : 18 (0x12)
Complete name : D:\DVB\_dump\rm-2021-07-18 21-30-40.ts
Format : MPEG-TS
File size : 4.00 GiB
Duration : 2 h 1 min
Overall bit rate mode : Variable
Overall bit rate : 4 716 kb/s
Video
ID : 301 (0x12D)
Menu ID : 103 (0x67)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Format settings, GOP : M=4, N=32
Codec ID : 27
Duration : 2 h 1 min
Bit rate : 4 159 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.080
Stream size : 3.53 GiB (88%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio #1
ID : 303 (0x12F)
Menu ID : 103 (0x67)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 2 h 1 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : -1 s 382 ms
Stream size : 167 MiB (4%)
Language : Spanish
Audio #2
ID : 304 (0x130)
Menu ID : 103 (0x67)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 2 h 1 min
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : -1 s 278 ms
Stream size : 111 MiB (3%)
Language : v.o
Menu
ID : 300 (0x12C)
Menu ID : 103 (0x67)
Duration : 2 h 1 min
List : 301 (0x12D) (AVC) / 303 (0x12F) (MPEG Audio, Spanish) / 304 (0x130) (MPEG Audio, v.o) / 305 (0x131) (MPEG Audio) / 311 (0x137) (DVB Subtitle) / 314 (0x13A) ()
Language : / Spanish / v.o
Service name : Realmadrid TV HD
Service provider : Realmadrid
Service type : advanced codec HD digital television
Maximum bit rate : 216000000
Quote from: radorn on August 25, 2021, 06:36:47 PMHow do I do that, just chop a chunk off with a hex editor?
What is the equivalent of
head -c 20971520 /path/to/source.ts > /path/to/sample.tson Windows?
By the way, the issue is that you can't save the entire MKV you provided as MP4 due to broken DTS for the first few frames.
Does it have to be 20 megs, can't it be less?
Let's try with 10. If Avidemux on your system is capable to detect video in the sample and the duration includes at least 3 GOPs, it is enough.
Same MEGA folder. ~7MB, 10 complete GOPs.
Sounds OK?
Perfect, thank you very much.
So, going back to the original topic, is there any workaround I can try to correct the color?
You haven't provided a project script which would allow to judge what you actually do with the stream (the configured filter chain, the encoder and its settings), but you should be able to specify color properties manually when encoding to HEVC using x265. While x264 supports color properties, Avidemux doesn't provide means to pass this configuration to the encoder library.
When muxing into a MKV (which doesn't work really well in copy mode), you can specify color properties at the container level. A video player (not Avidemux for the purpose of display) might respect these settings.
The encodes I'm tryingo to produce are mainly intended for that that same USB-enabled tuner, for size reduction and removing ads and so on (GOPs are 1+ seconds long, so it's not good when they don't fully align with these). This device doesn't seem to respect any matroska off-band signaling, but rather it seems only interested in what the audio and video streams might have to say. I doesn't even obey MKV aspect ratio, so that doesn't seem like a promising route. It's a miracle it supports matroska at all.
The best video codec that this thing supports is h264, so that's what I'll be using, but while Avidemux's x264 encoder does have a tab called "Output2" which seems to have the relevant options for the task, these are all grayed out, both in basic or advanced configuration modes. I can't seem to find a way to enable those.
It seems to work with x265. Now the decoded video has the same colors as the TS. But that tuner won't play h265 video.
Quote from: radorn on August 25, 2021, 09:51:28 PMwhile Avidemux's x264 encoder does have a tab called "Output2" which seems to have the relevant options for the task, these are all grayed out, both in basic or advanced configuration modes. I can't seem to find a way to enable those.
This functionality is not implemented in the backend yet.
Regarding display, D3D9 we use for hw accelerated display on Windows AFAIK provides no control over colorspace.
I guess this is no longer related to Avidemux anymore, but, Do you know any way I can insert that kind of color information into the h264 stream after the encoding is done?
I know I can set them in the matroska container, but, as I said, that'll be ignored by the DVB tuner I intend these encodes for.
Quote from: radorn on August 26, 2021, 02:13:45 PMDo you know any way I can insert that kind of color information into the h264 stream after the encoding is done?
For formats with out of band extradata, this would require at least generating extradata for the given configuration with this information added – a hardly practicable way, which would require a lot of skilled coding. If this color information makes x264 actually generate a different compressed stream instead of being just a hint stored in the SPS, the task would become totally unfeasible.
Quote from: eumagga0x2a on August 25, 2021, 07:00:36 PMBy the way, the issue is that you can't save the entire MKV you provided as MP4 due to broken DTS for the first few frames.
Should be fixed by [demuxers/Matroska] Take early B-frames into account when enforcing fixed frame rate (https://github.com/mean00/avidemux2/commit/0ad7461123776a215d2b042ff5b9ea799f8724bf), thank you again for the sample.
I'll try to add support for color information to the backend of the x264 encoder plugin. Might take a couple of days.
Quote from: eumagga0x2a on August 26, 2021, 04:01:48 PMFor formats with out of band extradata, this would require at least generating extradata for the given configuration with this information added – a hardly practicable way, which would require a lot of skilled coding. If this color information makes x264 actually generate a different compressed stream instead of being just a hint stored in the SPS, the task would become totally unfeasible.
I understand. I was just figuring that, perhaps, it could be just some flag in the bitstream or something "simple" like that and, maybe, there was a tool for it already available which you might know about. If that's not the case, it's OK.
Quote from: eumagga0x2a on August 26, 2021, 10:03:44 PMthank you again for the sample.
You're welcome.
And now that you mention B-frames... I have been wondering for some time now:
Is it safe to cut a GOP leaving one of it's B-frames hanging at the end, be it before the end of the file or in front of a different frame than that which followed it originally? Or should I always take care to always leave a GOP "closed" by at least one of it's original back-referencing-only P-frames, so that all B-frames left in will have their intended forward referenced frames preserved in the editted stream?
Do the trailing B-frames of one GOP ever forward-reference the starting I-frame or K-frame of the next GOP or are all GOPs entirely independent and selfcontained?
I ask this because I've been cutting up videos in copy mode for some time now, and I've recently noticed some, to me, unexpected problems around cut points in certain files, and I'm wondering if, perhaps, my method was wrong meaning I might have left behind a bunch of mangled cutpoints in previously editted files.
B-frames are the only explanation I can think about right now.
Quote from: eumagga0x2a on August 26, 2021, 10:03:44 PMI'll try to add support for color information to the backend of the x264 encoder plugin. Might take a couple of days.
Thank you very much. Apreciated.
Done (https://github.com/mean00/avidemux2/commit/1ffe879026382befa46f213485d7f1f4c5f133a4), with two regressions immediately spotted and fixed by followup commits. May still be buggy though.
Quote from: radorn on August 26, 2021, 11:32:43 PMIs it safe to cut a GOP leaving one of it's B-frames hanging at the end, be it before the end of the file or in front of a different frame than that which followed it originally?
You can set the end of selection for the purpose of saving it when in copy mode to any frame, Avidemux will cut the stream short so no frame is left dangling. Setting the B marker to a B-frame will exclude that frame and all later frames in display order from being included into the output, which probably cuts away the P-frame this B-frame depends on and likely all B-frames before until the previous P-frame (or keyframe).
Quote from: radorn on August 26, 2021, 11:32:43 PMOr should I always take care to always leave a GOP "closed" by at least one of it's original back-referencing-only P-frames, so that all B-frames left in will have their intended forward referenced frames preserved in the editted stream?
If I am not mistaken, one doesn't need to take care of that, but placing the end of selection on a keyframe reduces the stretch at the end of the video missing in the output. All forward references in display order obviously reference only past frames in stream order.
Quote from: radorn on August 26, 2021, 11:32:43 PMDo the trailing B-frames of one GOP ever forward-reference the starting I-frame or K-frame of the next GOP or are all GOPs entirely independent and selfcontained?
In closed-GOP streams, GOPs are self-contained, but you probably won't find public digital broadcasts which still use closed GOPs as they are detrimental to quality in the presence of bandwidth constraints. Keyframes in usual open-GOP streams are merely seek points, they guarantee that you can start decoding the stream from this point and get no incomplete pictures. But all the usual dependencies continue across such seek points. Defining a GOP as a sequence of slices from one IDR slice to the next one, many such streams never see a GOP end, or they may go on for minutes, hours or days.
Such streams are fundamentally incompatible with cuts within a stream (i.e. with deletions or insertions), but many decoders handle strictly speaking invalid streams with such cuts quite graciously with libavcodec-based players and editors like Avidemux being really bad here. Avidemux performs some checks to ensure that the worst problems like video stopping for many seconds don't happen and warns the user otherwise.
Sorry for the delay.
Soon I'll be trying a new compile with the color-setting settings you added to the x264 encoder and tell you how that went. Thanks again.
I'm also doing some tests with avidemux and other programs to get a better grasp of how all these things work together, and, also, to see what are the precise limits of that settopbox I use. The manual seems to indicate high profile, level 4, and that's it. Nothing about other h264-related details or container settings. Not sure if that includes levels 4.1 and 4.2 either.
Anyway, VirtualDub2's built-in x264 encoder's commandline arguments list reveals this:
QuoteVideo Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.
That's the header for the section with all the settings for color primaries, transfer functions and so on. So it seems these things are implemented as flags in the h264 bitstream but they don't affect the encoded video after all. Not that this solves the problem of adding that information to, or modifying it in, an already encoded h264 stream, of course.
Thanks for the explanation on GOPs. I've seen "open GOP" and "closed GOP" written many times but never took the time to find out what it meant.
It'd be great if there were algorightms in place for stream-copy edition where only the necessary missing parts of GOPs were re-encoded so to have a proper lossless edit in copy mode no matter where you cut the stream. I'm just daydreaming of course, and I realize that the ammount of research and engineering this would require (and replicated for every coded under the sun) for something so niche would be insane and hardly justifiable.
Being practical, if the edition needs to be fancier, just re-encode.
Most channels I usually record are still SD MPEG2 DVB-1, and these lend themselves better to being just chopped up in copy mode, especially if they do fadeouts and fadeins when going in and coming ouf of commercials. And I don't have to worry about color primaries with these. But other times they just jump from the running movie to the network branding transition from one frame to the next, and I started noticing funny stuff with these cut points sometimes. I guessed that the problem could be related to the preceeding GOP ending with a B-frame that's now missing it's forward reference.
With those things in mind, and, more important, the rather big size of these edits, I started finding it necessary to re-encode.
------
Well, this is getting long. I'll update you with my results when I get around trying your fix. And thanks again.
I meant to test your update, but the last available compile turns out to be older. Unfortunately I wasted another 30MB to find that out. I need to be more careful.
Anyway. After quite a bit of experimentation with avidemux, Vdub, and others, I've come to the unfortunate conclusion that this stupid DVB tuner doesn't even honor VUI information. So all the work in enabling it won't benefit my use of this junk settopbox after all. I'm really sorry.
The only thing that would do the trick in this case of mine, would be to implement actual color conversion from bt709 to bt601. Of course, I understand this is way more involved, so don't worry.
Anyway, this device is so dumb that even h264 SAR (why don't the call it Pixel Aspect Ratio like everyone else?) isn't properly interpreted. For starters the player only really supports 2 projection modes: 4:3 and 16:9, and the actual resolution of the material doesn't seem to count for anything. Somehow the player decides whether a particular video file should be projected one of those two ways, and just stretches whatever resolution it finds and fills that rectangle with it. Limited, but workable. But what's really bonkers is how it just does whatever it wants with the VUI SAR info. A SAR of 1:1 always results in widescreen projection, and the actual resolution has no bearing on the result. Other SAR values somehow result in wide or normal projections but the rules that decide this definitely don't conform to real AR calculations, mpr do they seem to follow any apparent logic. But, in the end, at least I now have a system for it: 1:1 SAR results in 16:9 widescreen and 1:2 SAR spits 4:3. Nonsensical, but works every time.
Cheap made-in-prc junk.
So, in the end, for regular DVB-1 channels that broadcast SD MPEG2 video in bt601 color, avidemux works perfectly fine for me. But for recordings of DVB-2 channels with HD AVC/h264 video in bt709 color, I would need a way to actually convert the colorspace. I downscale them to SD anyway, as I'm still watching on a CRT.
Quote from: radorn on September 04, 2021, 07:35:35 AMI meant to test your update, but the last available compile turns out to be older.
Refresh of the nightlies requested, it will happen when it happens.
Quote from: radorn on September 04, 2021, 07:35:35 AMBut for recordings of DVB-2 channels with HD AVC/h264 video in bt709 color, I would need a way to actually convert the colorspace.
Honestly, I never perceived the difference (I use my computer monitor for all purposes). The one which is sorely missing, is a proper conversion bt2020 --> bt709, but I was never bothered by bt601/bt709 mismatch as long as color range was correct. Better support for colorspaces will hopefully come some day.
Quote from: radorn on September 04, 2021, 07:35:35 AMI downscale them to SD anyway, as I'm still watching on a CRT.
Over the time, the cost for wasted electricity caused by the CRT might have exceeded the price of a new LCD... Even decade old TV sets allow to plug in a flash drive and support a wide range of formats. However, the longevity of that CRT is amazing.
Quote from: eumagga0x2a on September 04, 2021, 04:21:17 PMHonestly, I never perceived the difference
Well, admittedly the difference isn't so big that you would say it just looks wrong if you don't have a reference to compare to. But once you do... you start noticing things look somewhat weird.
This started when I was comparing some encodes to their originals and I saw the different colors. I didn't undestand what was going on at first and I had all sorts of theories. It all became clear when I started messing around with VirtuaDub after a long time and noticed the "decode format" dialog with it's selector for 601 and 709. After playing with that it all became clear.