From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id A513E45A5E for ; Thu, 13 Apr 2023 10:14:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6B4E268BAA0; Thu, 13 Apr 2023 13:13:57 +0300 (EEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8E733689C6C for ; Thu, 13 Apr 2023 13:13:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1681380830; i=bernd.duerrer@gmx.de; bh=3YDKKbMSIa0ZqjmRju8ooLFFHHEHjq/zS9M5PI2a6gA=; h=X-UI-Sender-Class:From:To:Subject:Date:In-Reply-To:References; b=cSl1mWANgcmj9YTOVL5yel6bZbWuzb9fHRZYXmY+2gYTDBH6/oJf6ZIxsqPAeFCp/ MG+P+bdSELj2YghI7VEMBYTMuZATPftCsttwmxGUsSyNEc+DHi9Fn80xBG1V+iQHfG BlYLXC5Kkif9MqINC455xEfu3bgVtQGdIv4ysjJwNK2iTAFVpRfvgx+Hzz5stBs0pq 2C9nJhWaFaZtc12EAkox0lgAUYCGrabyJ0jEZ3z1eAXNZo/D8ptucG2UAlSKZtNj/5 +F8zn1lQMlCvvXQu4E6Wzarxy2Ej0kvl9JyvHxBUiZWjjnuOOUoVi1mlSYax5aD56s P9T7sUxV0QNRg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [178.249.232.1] ([178.249.232.1]) by web-mail.gmx.net (3c-app-gmx-bap58.server.lan [172.19.172.128]) (via HTTP); Thu, 13 Apr 2023 12:13:50 +0200 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?Bernd_D=C3=BCrrer?= To: ffmpeg-devel@ffmpeg.org Date: Thu, 13 Apr 2023 12:13:50 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:DS9DyGwercUAoGQbdPrUoIRGOOEuFmNc92ZfiOlMqnwAoUSblQez+dhNPkPKLjjKR5tll KtPrtbUopPslRGecrOFeKxANywu5P7zCBBI0KBpswQxuxXCFw3thH/OIBReemSB04mj10kD7qydl c+e2mRItToZFmcmotX8JHqwTcRZHCqH1VngLBa3mw0XpXnt6mz3eNTCi0vf5OApEMNPhyzal+68W HBdBYaNmLbfOLKmYR991BVZzAUhlrEUVwnt0UsMYgva35lpvHGu+G49hFdoUDC5aiEa6ML3MQfJK q4= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Jmh+mvBj9bE=;VVjLw1OuID9atpmT4UAOAuTyJvZ f01cLVSJnW/YzwNhsyaOzMCnRFH8L81XzAMvxsFf69GeVOEI3UozvmsaSnG0K/OCUnjX5+cqJ h4eudfnKpPlwwEX9t9rTajBbpMjW5fFNXH3Y9C95pP3yV6sn67Raa9k60ME/l2wlILT/JFpGq ReXRj3QRX7/TJHOAIsudPLE+2rBGvmfKBifkdZ1wvOLQdcbJ7P0FZYZGMMX66DxOX3vl86mjz RtSu67h+VgI/9hoKVKPNgKeYTd/R67vXfMJ0dkG8k96fRQvFHEGXzMIhgMaUHC8Jqu6mwUjha u5DiFYTubbBRbmIxUBZKVzMT8Iu7DEIS/1G9x8AQVH+EXsQj8q4lX1JBJL6ojio5GDDSGBpM0 UM8VYOsWim4GjLqc3rNjyKhwOiWh6Hk/n5qtBJPHcqMRiW/de2knPHSavAjsyBKEccukie5Wr 4xu2GzjiheIsLr/d6sk8Lmt85qL8V06xLwWMT3N1AIW3tCKLCUJI4boBwyei3r6+j3No+VK7Y ijdk7gBLmlm13vljFzoDXd+RWlyTimNSA4ZyIlYXxbOgmibvYYXgLLzfEI5lEK6gQfTJzzne7 zT0IqwDgRTIrVS/3w+8xKifyRjfYk0OyGgZ2bml1uZJvN8i8Hx9NYVqGSA3VCON/Vy0uG0+uI 0hp64t1btHKQaFEVrcPz7jqtZFPt2QCi5jCLLiG3ynoCc/7VIdweHLUwFrR3h7dLeHIk90w48 7sgpx6E2CGxz8XgaqXF65fcCD9vCTAZ1mDVSNrdACo/o5uO/wFdz0HaAcIBtHhOQ3gqbknkDC vTGkewPEDUgzq4fbV4d6Z/Rg== Subject: Re: [FFmpeg-devel] [PATCH] avformat/mov: remove hack breaking creation time parsing X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue Apr 11 2023, Marton Balint wrote: > Maybe you can check if the DLNA server reads that. Or if it only reads the > year information, then com.apple.quicktime.year might be even better. I have checked the DLNA Guidelines and Part 1-1, clause 10.1.3.12.3, Table 13, recommends to provide the dc:date metadata property for video items. I have MP4 files where the date metadata was set, but not to a complete date, but only the year part. This appears to be the reason why my DLNA server has used the creation_time metadata instead. After setting the date tag to a complete date YYYY-MM-DD HH:MM:SS, it is recognised by the DLNA server and provided to the DLNA clients, and there is no problem to set the date tag to dates before 1970 with ffmpeg. So my use case to set the creation_time tag to dates before 1970 is now obsolete. Nevertheless, I looked into ffmpeg why the command ffmpeg -i input.mp4 -map_metadata 0 -metadata creation_time="1965-01-01 12:00:00" -codec copy output.mp4 results in creation_time written as 2036-01-01T23:59:59.000000Z to the output file. The reason is at the end of function av_parse_time in libavutil/parseutils.c where mktime is called to convert the dt structure. As mktime cannot represent calendar times before 1970, it returns -1. However, as the result is not checked, the return value of -1 is used for all subsequent processing and results in the wrong date written to the file. In my humble opinion, at least a warning should be raised that the date value provided as parameter on the command line is out of range. Thanks for your support and kind regards, Bernd _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".