Re: [FFmpeg-user] 5.1 AAC without lowpass on the LFE channel
Is there a way to specify the LFE bitrate separately from the other full-range channels? Steven Ruppert via ffmpeg-user wrote on 9/15/22 16:24: > On 9/12/22 09:33, Steven Ruppert via ffmpeg-user wrote: >> I couldn't find any references whether that's inherent to the AAC 5.1 >> encoding, something that ffmpeg does, or inherent to the decoding >> process. (I did decode my same test files using something that uses >> Microsoft MediaFoundation and the LFE channel was still lowpassed). > > Turns out the AAC codec inherently limits the LFE bandwidth, so > there's no way around it. > > The actual ISO/IEC 13818-7:2006(en) Standard costs a bunch of money to > read as usual, but in the free glossary there is an entry: > > >low frequency enhancement ( LFE ) channel: limited bandwidth channel > for low frequency audio effects in a multichannel system > > https://www.iso.org/obp/ui/#iso:std:iso-iec:13818:-7:ed-4:v1:en > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 5.1 AAC without lowpass on the LFE channel
On 9/12/22 09:33, Steven Ruppert via ffmpeg-user wrote: I couldn't find any references whether that's inherent to the AAC 5.1 encoding, something that ffmpeg does, or inherent to the decoding process. (I did decode my same test files using something that uses Microsoft MediaFoundation and the LFE channel was still lowpassed). Turns out the AAC codec inherently limits the LFE bandwidth, so there's no way around it. The actual ISO/IEC 13818-7:2006(en) Standard costs a bunch of money to read as usual, but in the free glossary there is an entry: >low frequency enhancement ( LFE ) channel: limited bandwidth channel for low frequency audio effects in a multichannel system https://www.iso.org/obp/ui/#iso:std:iso-iec:13818:-7:ed-4:v1:en ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Size of 10-bit 4:2:2 video streams?
I‘d rather like to start by asking the much simpler question whether the processed files can be played back at all, and if so, are they visually identical and are all other parameters identical to the source file, or are they different in any way? If they are visually identical, are there any measurable differences? Erik ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] "Bitrate" function in udp out don't working
On Thu, 15 Sep 2022, Online video wrote: Hello all, I have problem with ffmpeg in Windows. "Bitrate" function in udp out don't work correctly. I can set any bitrate, it will be no more than 1.35 Mbps. For example: "udp://127.0.0.1:1234?pkt_size=1316=600" In Linux it work correctly, bitrate of stream is in accordance with set. Has anyone experienced this? As far as I remember on Windows the sleep API as used by ffmpeg provides less accurate timing, and no platform-specific timers are implemented for Windows which could provide higher accuracy. You can try setting/increasing burst_bits which should increase the bitrate but cause slighly bigger bursts. Regards, Marton ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Size of 10-bit 4:2:2 video streams?
On Thu, 15 Sept 2022 at 13:50, Bruchez Olivier via ffmpeg-user wrote: > I understand, but the file is quite large (146 GB), so it's a bit difficult > to share. :( Side question: can an incomplete AVI be played? If yes/'it depends', perhaps a portion of OP's file might be illuminating? Cheers, Rob ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Size of 10-bit 4:2:2 video streams?
On 9/15/2022 5:15 AM, Paul B Mahol wrote: Can not guess without access to the file in question. Of course one can guess without the file. Making guesses is part of scientific discovery- make a guess then see if it's correct; if it's not, understand why and make another. Either way, people can learn from it. Even an AVI file has some amount of packaging around the data, so when you remove that to a raw video file, the data is discarded. Should 1/3 of the file be formatting? Can't answer that myself, but it sounds high. Is there an audio stream in the original file? The original email says no but verify that anyway. Going from AVI to AVI? Since the console output from that wasn't included my -guess- is that the content was repackaged into the new container and something of the original causes the huge increase in size. Always include the complete output of ffmpeg commands when asking questions, also use the latest ffmpeg available. z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] "Bitrate" function in udp out don't working
Hello all, I have problem with ffmpeg in Windows. "Bitrate" function in udp out don't work correctly. I can set any bitrate, it will be no more than 1.35 Mbps. For example: "udp://127.0.0.1:1234?pkt_size=1316=600" In Linux it work correctly, bitrate of stream is in accordance with set. Has anyone experienced this? Best regards, Sergei ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Size of 10-bit 4:2:2 video streams?
On 15.09.22, 14:15, "one...@gmail.com" wrote: > > The file has a size of 146 GB = 146004770816 bytes. > > Can not guess without access to the file in question. I understand, but the file is quite large (146 GB), so it's a bit difficult to share. :( Olivier ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On 9/15/22, Michael Koch wrote: > Am 15.09.2022 um 13:43 schrieb Dan: >> On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch >> wrote: >> >>> Am 15.09.2022 um 11:53 schrieb Dan: > This seems to work with VLC player: > > ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 > -vcodec libx264 -t 5 -y out1.mp4 > ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 > -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? >>> >>> Please try this, for me it works with VLC player, the color is exactly >>> the same: >>> >>> ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 >>> -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y >>> out1.mp4 >>> ffmpeg -f lavfi -i color=0x19be0f:s=400x720 -colorspace bt709 >>> -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y >>> out2.mp4 >> >> Sure. >> >> The colour is both the same now (for both Chrome and MPC), except it's >> the darker, wrong colour (green=164 instead of 190). > > Try some other values instead of "bt709". MIssing -color_range when encoding? yuvj is full range. > > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Size of 10-bit 4:2:2 video streams?
On 9/15/22, Bruchez Olivier via ffmpeg-user wrote: > Hi all, > > I have a 10-bit 4:2:2 (yuv422p10le) AVI file containing only a video > stream: > > Input #0, avi, from 'test.avi': > Duration: 01:28:00.80, start: 0.00, bitrate: 221185 kb/s > Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 720x576, 25 > fps, 25 tbr, 25 tbn, 25 tbc > > The file has a size of 146 GB = 146004770816 bytes. > > Am I correct to infer that those 10-bit YUV values are grouped into 30-bit > packets and encoded into 32-bit/4-byte packets? > > With 20 bits per pixel (Y + either U or V), that would give a theoretical > file size of: > > 88 * 60 * 25 * 720 * 576 * (10 + 10) / 30 * 32 / 8 = 14598144 bytes > > Which seems to more or less match the original file size. > > Now here's my problem. When I extract the raw video stream: > > ffmpeg -i test.avi -c:v rawvideo -pix_fmt yuv422p10le -f rawvideo test.raw > > I get a RAW video file with a size of 96 GB = 96636395520 bytes. I’ve lost > one third of the video stream. > > Another strange thing: if I copy the video stream to another AVI file: > > ffmpeg -i test.avi -c copy test.copy.avi > > The resulting file has a size of 64 GB = 64425220302 bytes. This time I’ve > lost 56% of the video stream. > > What's happening here? It seems like I’m missing something obvious. > Can not guess without access to the file in question. > Thanks for any help, > Olivier > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 13:43 schrieb Dan: On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch wrote: Am 15.09.2022 um 11:53 schrieb Dan: This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? Please try this, for me it works with VLC player, the color is exactly the same: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x720 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Sure. The colour is both the same now (for both Chrome and MPC), except it's the darker, wrong colour (green=164 instead of 190). Try some other values instead of "bt709". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Size of 10-bit 4:2:2 video streams?
Hi all, I have a 10-bit 4:2:2 (yuv422p10le) AVI file containing only a video stream: Input #0, avi, from 'test.avi': Duration: 01:28:00.80, start: 0.00, bitrate: 221185 kb/s Stream #0:0: Video: v210 (v210 / 0x30313276), yuv422p10le, 720x576, 25 fps, 25 tbr, 25 tbn, 25 tbc The file has a size of 146 GB = 146004770816 bytes. Am I correct to infer that those 10-bit YUV values are grouped into 30-bit packets and encoded into 32-bit/4-byte packets? With 20 bits per pixel (Y + either U or V), that would give a theoretical file size of: 88 * 60 * 25 * 720 * 576 * (10 + 10) / 30 * 32 / 8 = 14598144 bytes Which seems to more or less match the original file size. Now here's my problem. When I extract the raw video stream: ffmpeg -i test.avi -c:v rawvideo -pix_fmt yuv422p10le -f rawvideo test.raw I get a RAW video file with a size of 96 GB = 96636395520 bytes. I’ve lost one third of the video stream. Another strange thing: if I copy the video stream to another AVI file: ffmpeg -i test.avi -c copy test.copy.avi The resulting file has a size of 64 GB = 64425220302 bytes. This time I’ve lost 56% of the video stream. What's happening here? It seems like I’m missing something obvious. Thanks for any help, Olivier ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch wrote: Am 15.09.2022 um 11:53 schrieb Dan: This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? Please try this, for me it works with VLC player, the color is exactly the same: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x720 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Sure. The colour is both the same now (for both Chrome and MPC), except it's the darker, wrong colour (green=164 instead of 190). Dan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 11:53 schrieb Dan: This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? Please try this, for me it works with VLC player, the color is exactly the same: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x720 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 11:53 schrieb Dan: This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? Not the same color, but the difference is small. Not visible without measuring. It becomes even smaller when you add -color_primaries bt709 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On Thu, 15 Sep 2022 10:40:10 +0100, Paul B Mahol wrote: Looks like your knowledge is very limited, incorrect. Of course it is! I said I was a beginner to ffmpeg and never pretended otherwise. My expertise is in other areas (3D, C# programming, music etc.) I never made any outright statements, always "maybe", or "Could there be". In that last post, I also provided empirical data in the form of *four* different media players. Perhaps I misunderstood showinfo's output. And? Next time be less so ignorant and do some research and do read documentation and do your homework before coming here asking for questions. Please be less rude. I've spent multiple if not over a dozen hours on this whole niche of a niche bug! I should NEVER have had to do this in the first place if the format was properly implemented and interpreted. I'm merely an end user. Frankly, I'm amazed at just how messy this situation is (and no, I'm not necessarily blaming ffmpeg now). From what you claim, it looks like Chrome et al could indeed be at fault. But there's something FUNDAMENTALLY wrong or miscommunicated with how h264 or ffmpeg, or Chrome et al's interpretation is implemented, at least on Windows, if things like this can surface. So what do I do now. File a bug report to Chrome, Edge and the others? Perhaps I could try filing a bug report with ffmpeg, or will it merely be ignored? Also, where can I read more information about this mysterious and slippery bug, so I can at least know a little more about its nature. Dan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 11:41 schrieb Paul B Mahol: On 9/15/22, Michael Koch wrote: Am 15.09.2022 um 11:26 schrieb Dan: You are right that datascope shows no difference. But the issue is also reproducible with VLC player. As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google Chrome, Microsoft Edge and Vegas Pro, and the problem occurs with each of those. Could there be a "takes two to tango" thing going on, where both the players and ffmpeg are at fault due to miscommunication? It's somewhat hard to conceive they'd all interpret the file incorrectly otherwise. Only one player I tried - Irfanview - interpreted it correctly. I can't get to test it with Firefox or Waterfox unfortunately. They think the file is corrupt (output mp4 produced using the "-f lavfi -i color=0x19be0f:s=400x720" technique). Maybe there's a way around that. Also, showinfo produced an incorrect colour too. See: https://i.imgur.com/LF43udT.png (I use: "ffplay.exe -vf showinfo 576.mp4" ). In summary, I've love a workaround at least, or at least some reassurance that Chrome et al. will come round to fix this, or that ffmpeg will communicate the file better to them. This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 mostly because of extra -colorspace flag supplied. Wouldn't it be a good idea to show in FFprobe a message "colorspace=unknown" if colorspace isn't set? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 Unfortunately, doesn't work for me in MPC or Chrome. Can you try a height of 720 instead of 578 to see if that fails for you? Dan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On 9/15/22, Michael Koch wrote: > Am 15.09.2022 um 11:26 schrieb Dan: >>> You are right that datascope shows no difference. But the issue is also >>> reproducible with VLC player. >> >> As well as VLC Player and FFplay, I've tried MediaPlayerClassic, >> Google Chrome, >> Microsoft Edge and Vegas Pro, and the problem occurs with each of >> those. Could >> there be a "takes two to tango" thing going on, where both the players >> and ffmpeg >> are at fault due to miscommunication? It's somewhat hard to conceive >> they'd all >> interpret the file incorrectly otherwise. Only one player I tried - >> Irfanview - interpreted >> it correctly. >> >> I can't get to test it with Firefox or Waterfox unfortunately. They >> think the file >> is corrupt (output mp4 produced using the "-f lavfi -i >> color=0x19be0f:s=400x720" technique). >> Maybe there's a way around that. >> >> Also, showinfo produced an incorrect colour too. See: >> https://i.imgur.com/LF43udT.png >> >> (I use: "ffplay.exe -vf showinfo 576.mp4" ). >> >> In summary, I've love a workaround at least, or at least some >> reassurance that >> Chrome et al. will come round to fix this, or that ffmpeg will >> communicate the file >> better to them. > > This seems to work with VLC player: > > ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 > -vcodec libx264 -t 5 -y out1.mp4 > ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 > -vcodec libx264 -t 5 -y out2.mp4 mostly because of extra -colorspace flag supplied. > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On 9/15/22, Dan wrote: >> You are right that datascope shows no difference. But the issue is also >> reproducible with VLC player. > > As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google > Chrome, > Microsoft Edge and Vegas Pro, and the problem occurs with each of those. > Could > there be a "takes two to tango" thing going on, where both the players and > ffmpeg > are at fault due to miscommunication? It's somewhat hard to conceive they'd > all > interpret the file incorrectly otherwise. Only one player I tried - > Irfanview - interpreted > it correctly. > > I can't get to test it with Firefox or Waterfox unfortunately. They think > the file > is corrupt (output mp4 produced using the "-f lavfi -i > color=0x19be0f:s=400x720" technique). > Maybe there's a way around that. > > Also, showinfo produced an incorrect colour too. See: > https://i.imgur.com/LF43udT.png > > (I use: "ffplay.exe -vf showinfo 576.mp4" ). Looks like your knowledge is very limited, incorrect and completely full of nonsense. showinfo filter shows video frame color metadata to output of console, nothing less - nothing more. showinfo cant produce incorrect video, if you ever bothered to read documentation you would know. Next time be less so ignorant and do some research and do read documentation and do your homework before coming here asking for questions. It clearly shows that everything is unknown in that showinfo filter output on messages on console thus everybody can pick whatever they want to display video. > > In summary, I've love a workaround at least, or at least some reassurance > that > Chrome et al. will come round to fix this, or that ffmpeg will communicate > the file Nobody is wrong. Everybody is correct. Your file is encoded so badly that it should be immediately removed from existence. > better to them. > > Dan > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > Whats about users that come here these days? They show no sign of caring for details or knowledge. They just want shortcuts and prompt solutions. And clearly shows no incentive to change that anytime soon. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 11:26 schrieb Dan: You are right that datascope shows no difference. But the issue is also reproducible with VLC player. As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google Chrome, Microsoft Edge and Vegas Pro, and the problem occurs with each of those. Could there be a "takes two to tango" thing going on, where both the players and ffmpeg are at fault due to miscommunication? It's somewhat hard to conceive they'd all interpret the file incorrectly otherwise. Only one player I tried - Irfanview - interpreted it correctly. I can't get to test it with Firefox or Waterfox unfortunately. They think the file is corrupt (output mp4 produced using the "-f lavfi -i color=0x19be0f:s=400x720" technique). Maybe there's a way around that. Also, showinfo produced an incorrect colour too. See: https://i.imgur.com/LF43udT.png (I use: "ffplay.exe -vf showinfo 576.mp4" ). In summary, I've love a workaround at least, or at least some reassurance that Chrome et al. will come round to fix this, or that ffmpeg will communicate the file better to them. This seems to work with VLC player: ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
You are right that datascope shows no difference. But the issue is also reproducible with VLC player. As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google Chrome, Microsoft Edge and Vegas Pro, and the problem occurs with each of those. Could there be a "takes two to tango" thing going on, where both the players and ffmpeg are at fault due to miscommunication? It's somewhat hard to conceive they'd all interpret the file incorrectly otherwise. Only one player I tried - Irfanview - interpreted it correctly. I can't get to test it with Firefox or Waterfox unfortunately. They think the file is corrupt (output mp4 produced using the "-f lavfi -i color=0x19be0f:s=400x720" technique). Maybe there's a way around that. Also, showinfo produced an incorrect colour too. See: https://i.imgur.com/LF43udT.png (I use: "ffplay.exe -vf showinfo 576.mp4" ). In summary, I've love a workaround at least, or at least some reassurance that Chrome et al. will come round to fix this, or that ffmpeg will communicate the file better to them. Dan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 11:01 schrieb Paul B Mahol: On 9/15/22, Michael Koch wrote: Am 15.09.2022 um 00:30 schrieb Paul B Mahol: On 9/15/22, Dan wrote: zscale=...,format=yuv420p O okay. I tried that before (except using two -vf commands), because I suspected you might've meant that. Just tried it again, still no luck. Let me know if I need to tweak anything: ffmpeg.exe -f lavfi -i color=0x19be0f:s=400x578 -crf 0 -vcodec libx264 -vf zscale=w=-1:h=-1,format=yuv420p -t 5 -y "578.mp4" I'm using Media Player Classic to test the colours, which breaks the pic using the 578 pixel height. Chrome actually works with both the 576 and 578 pixel height, but as soon as I change the height to 984, then both Media Player Classic AND Chrome show it broken. Datascope shows the strange and seemingly unrelated 78,4C,44 values for all three sizes, but it does that even without using zscale at all. Good, we move forward, that are real values encoded in bitstream. Anything RGB values you complain about have nothing directly related about ffmpeg. Also make sure that all software are reinterpreting your files correctly. The files need to signal correct encoded colorspace/primaries/range/etc so it can be correctly displayed on screen. Below is a Windows batch file for reproducing with FFplay. I did use the latest version from Gyan. The color difference is clearly visible. Looks like you had hard time understanding text you quoted above. ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -vf zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -vf zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 start ffplay -left 0 -top 0 out1.mp4 start ffplay -left 400 -top 0 out2.mp4 When inspecting the files with FFprobe or ExifTool, I see no differences except height and small differences in bitrate and filesize. ffplay is broken/buggy and should not be used here, it will display differently stuff all the time, and uses SDL library by default for video output. Using datascope filter it clearly shows pixels are exactly same. You are right that datascope shows no difference. But the issue is also reproducible with VLC player. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
On 9/15/22, Michael Koch wrote: > Am 15.09.2022 um 00:30 schrieb Paul B Mahol: >> On 9/15/22, Dan wrote: zscale=...,format=yuv420p >>> O okay. I tried that before (except using two -vf commands), >>> because >>> I >>> suspected you might've meant that. >>> >>> Just tried it again, still no luck. Let me know if I need to tweak >>> anything: >>> >>> ffmpeg.exe -f lavfi -i color=0x19be0f:s=400x578 -crf 0 -vcodec libx264 >>> -vf >>> zscale=w=-1:h=-1,format=yuv420p -t 5 -y "578.mp4" >>> >>> I'm using Media Player Classic to test the colours, which breaks the pic >>> using the 578 pixel >>> height. Chrome actually works with both the 576 and 578 pixel height, but >>> as >>> soon as I >>> change the height to 984, then both Media Player Classic AND Chrome show >>> it >>> broken. >>> >>> Datascope shows the strange and seemingly unrelated 78,4C,44 values for >>> all >>> three sizes, >>> but it does that even without using zscale at all. >> Good, we move forward, that are real values encoded in bitstream. >> >> Anything RGB values you complain about have nothing directly related >> about ffmpeg. >> >> Also make sure that all software are reinterpreting your files correctly. >> The files need to signal correct encoded colorspace/primaries/range/etc >> so >> it can be correctly displayed on screen. > > Below is a Windows batch file for reproducing with FFplay. I did use the > latest version from Gyan. The color difference is clearly visible. Looks like you had hard time understanding text you quoted above. > > ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -vf > zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries > bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 > ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -vf > zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries > bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 > start ffplay -left 0 -top 0 out1.mp4 > start ffplay -left 400 -top 0 out2.mp4 > > When inspecting the files with FFprobe or ExifTool, I see no differences > except height and small differences in bitrate and filesize. ffplay is broken/buggy and should not be used here, it will display differently stuff all the time, and uses SDL library by default for video output. Using datascope filter it clearly shows pixels are exactly same. > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ffmpeg MP4/x264 output colours change when input source is different resolution (bug?)
Am 15.09.2022 um 00:30 schrieb Paul B Mahol: On 9/15/22, Dan wrote: zscale=...,format=yuv420p O okay. I tried that before (except using two -vf commands), because I suspected you might've meant that. Just tried it again, still no luck. Let me know if I need to tweak anything: ffmpeg.exe -f lavfi -i color=0x19be0f:s=400x578 -crf 0 -vcodec libx264 -vf zscale=w=-1:h=-1,format=yuv420p -t 5 -y "578.mp4" I'm using Media Player Classic to test the colours, which breaks the pic using the 578 pixel height. Chrome actually works with both the 576 and 578 pixel height, but as soon as I change the height to 984, then both Media Player Classic AND Chrome show it broken. Datascope shows the strange and seemingly unrelated 78,4C,44 values for all three sizes, but it does that even without using zscale at all. Good, we move forward, that are real values encoded in bitstream. Anything RGB values you complain about have nothing directly related about ffmpeg. Also make sure that all software are reinterpreting your files correctly. The files need to signal correct encoded colorspace/primaries/range/etc so it can be correctly displayed on screen. Below is a Windows batch file for reproducing with FFplay. I did use the latest version from Gyan. The color difference is clearly visible. ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -vf zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries bt709 -crf 0 -vcodec libx264 -t 5 -y out1.mp4 ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -vf zscale,setrange=full,format=yuv420p -colorspace bt709 -color_primaries bt709 -crf 0 -vcodec libx264 -t 5 -y out2.mp4 start ffplay -left 0 -top 0 out1.mp4 start ffplay -left 400 -top 0 out2.mp4 When inspecting the files with FFprobe or ExifTool, I see no differences except height and small differences in bitrate and filesize. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
